You're about to ship a free trial, and three decisions sit in front of you: whether to ask for a card, how many days to give, and what happens on the last day. Before you pick any of them, open your analytics and write down the single action that tells you a new user has understood the product, plus the number of days a typical new user takes to reach it. Every choice below depends on that one number.
This is a SaaS free trial design problem, not just a billing setting. Your signup flow, time to first value and end-of-trial message have to describe the same promise. The rest of this post works through those decisions in order, with the Stripe mechanics attached.
Should a SaaS Free Trial Require a Credit Card?
Requiring a card gives a higher trial-to-paid rate in ChartMogul's 2026 benchmarks, but it also shrinks signups, so decide by how quickly your product shows its value rather than by the benchmark alone.
The numbers come from ChartMogul's SaaS Conversion Report, published on 4 February 2026, which analyzed 200 B2B software products. The median free-to-paid conversion rate across all products was 8%. Among free trial products, 20% required a card upfront and the other 80% did not.
| Trial model | "Good" free-to-paid rate | "Great" free-to-paid rate |
|---|---|---|
| Card required at signup | 25%-35% | 50%-60% |
| No card required | 4%-6% | 10%-15% |
Read those rates carefully. They are the share of trial starters who pay, and a card requirement changes who starts. A card-required trial has fewer starters who are more committed, so the better comparison for your own product is paying customers per thousand visitors, not the rate alone. That is my inference from how the two models work, and the report doesn't test it.
A practical rule follows, and it is a recommendation, not a finding. If you are still learning who your ideal customer is, run the trial without a card so you collect volume and signal. Once you know which users convert, test adding the card. Stripe adds one caution for no-card trials: its documentation warns that starting a trial without a payment method can let spammers create many fake customers and subscriptions, and suggests requiring an account and a captcha first.
How Long Should a Free Trial Last?
A trial should last long enough for a typical new user to reach your activation event at least once, and I could not find a primary source that ranks 14 days above 30, so measure your own time-to-value.
Popular advice says 14 days beats 30 because shorter deadlines create urgency. The figures usually quoted for that come from vendor blogs, and they are left out here because they can't be traced to a study anyone can open. What I can verify is the platform constraint. Stripe allows a trial period of up to 730 days, so the limit is your product, not your billing tool.
The Callidus case study shows one real choice: a 14-day free trial with a four-stage lifecycle of a 3-day reminder email, a 1-day reminder email, expiry with a 3-day grace window, then suspension. The case study doesn't claim 14 days is optimal. It is simply what that product shipped with.
Here is a way to pick your own number. Take the days from signup to activation for the users who later paid. If most of them activate within a week, a trial of about two weeks leaves room for a second session. If the activation event depends on an integration, an approval or a data import that takes weeks, a short trial will fail whatever you do about urgency. Complex products with those dependencies need longer trials, and simple ones don't.
What Should Happen Inside the Trial and at Its End?
Drive every new user to one activation event, email by behavior instead of by calendar, and let Stripe's `customer.subscription.trial_will_end` event trigger your last message, which by default arrives three days before the trial ends.
What do you send during the trial?
These are recommendations to test, not measured results. On day one, send one instruction instead of a welcome tour: "Do this one thing now," pointing at the activation event. A few days in, segment by behavior. A user who finished setup but hasn't invited a teammate needs a different message from a user who never came back. Toward the end of the trial, switch from "here's what you can do" to "here's what you've already done," with a summary of the data created and the integrations connected. Tools that fire emails from product events, rather than from a schedule, make this practical.
There is one step before that first email. If visitors need help understanding the product before signup, a short explainer video can set expectations. Flowjam's guide to SaaS explainer videos covers the script, visual style, placement and budget. Once someone starts the trial, point them to the first useful action rather than another pitch. Measure activation, not video views.
What does Stripe do when the trial ends?
Stripe sends `customer.subscription.trial_will_end` according to the Trial ending events setting in the Dashboard, which defaults to 3 days before the trial ends, and immediately if the trial is shorter than the configured interval. Stripe can also send hosted reminder emails 7 days before a trial ends, per its trial compliance guide. If you send your own email, handle the event server-side, check whether the customer has a payment method, and link to a page where they can add one. The glossary entry on Stripe webhooks covers the event lifecycle.
Under the legacy `trial_end` path, a new billing period begins when the trial ends, and Stripe generates an invoice and attempts to charge it about an hour later. Tell customers the real first charge date, because a message that says "the 15th" while Stripe bills on the 12th is an easy way to earn a dispute.
How do you run a trial without a card in Stripe?
Create the subscription with a trial period and no payment method, then decide what happens when the trial ends without one. The `trial_settings.end_behavior.missing_payment_method` setting accepts `cancel`, `pause` or `create_invoice`. In Checkout, set `payment_method_collection` to `if_required`:
```bash
curl https://api.stripe.com/v1/checkout/sessions
-u "<<YOUR_SECRET_KEY>>:"
-d mode=subscription
-d "line_items[0][price]=price_abc"
-d "line_items[0][quantity]=1"
-d "subscription_data[trial_period_days]=14"
-d "subscription_data[trial_settings][end_behavior][missing_payment_method]=cancel"
-d payment_method_collection=if_required
```
For a card-required trial, collect the card at signup and let Stripe charge when the trial ends.
One change to know about: Stripe's documentation now labels `trial_end` and `trial_period_days` as a legacy path and recommends the new Trial Offer API for new integrations. That API requires API version `2026-09-30.endive` or later and flexible billing mode, and it does not support Checkout, Payment Links or Elements with Checkout Sessions, so Checkout-based flows still use the legacy parameters. Check the page for the current state before you build. For the wider billing setup, see the Supabase and Stripe integration guide, and for what happens when a first payment fails, read the post on dunning and failed payment recovery.
What does a project with a live trial lifecycle look like?
The Callidus case study lists 20 Stripe webhook events handled end to end, including `customer.subscription.trial_will_end`, and a coordinator Cloud Function that runs daily at 09:00 UTC and starts one task per trialing tenant. During the grace period, pages stay viewable while changes are blocked. The BookBed case study reports a wired and tested subscription with a trial lifecycle at €9 per month for up to twenty units, not yet switched on for paid traffic. Both examples show the trial as a state machine with explicit stages instead of a single expiry date.
What must customers see before the first charge?
Show the price, the charge date and how to cancel before the card field, not in a modal afterward. Stripe states that you must comply with card network requirements for trials and describes reminder emails, a cancellation link and trial text on the statement descriptor as the tools. I'd add the price to the signup page itself, because surprise at the first charge is the situation that produces disputes. That is my recommendation, not a Stripe rule.
Should You Extend Trials for Users Who Haven't Converted?
Extend only for users who were clearly active and hit a specific blocker, because extending for everyone else adds days without adding a reason to pay.
Consider a hypothetical support queue: someone logs in on day 12, hasn't converted, and receives a seven-day extension, then another, then another. Eventually the trial has run six weeks for a person who opened the product three times. That example is an illustration of the pattern, not data.
A rule of thumb to test: grant an extension only when the user has completed a set number of core actions (for example three, chosen from your own activation data), has no payment method on file yet, and named a blocker such as a broken integration or an unanswered question. Everyone else gets the standard expiry and, later, a re-engagement email. Track the extension rate. If you grant many, your trial is the wrong length or your activation moment arrives too late.
How Do You Measure SaaS Free Trial Conversion?
For each signup cohort, calculate trial-to-paid conversion as customers who start paying divided by users who started the trial. Keep card-required and no-card cohorts separate, since they attract different starters. Also track paying customers per thousand pricing-page visitors so a smaller signup pool does not make a conversion rate look better than the business result.
Watch three supporting numbers. Activation rate within your chosen window tells you whether users reach first value. Early drop-off tests whether the promise on your landing page matches the product. Extension rate tests whether the trial length fits. A B2B SaaS product should have these instrumented from the first deploy, and the SaaS MVP stack guide covers the architecture that makes that easier. For the choice between a trial and a free tier, see free trial versus freemium billing.
What is your activation event, and how many days does a new user take to reach it? Pull that number today and set your trial length from it instead of from a benchmark.