Stripe made "trial offers" generally available on September 30, 2026, letting founders attach a reusable trial price to a single subscription item instead of the whole subscription. That sounds like a small API change, but it opens up trial designs — paid trials on an add-on, a trial on one plan tier but not another, different trial-end fallbacks — that used to need custom code. Here's what actually changed, and what it's worth testing on your own trial.
What did Stripe actually change?
Stripe moved trial offers from preview to general availability in flexible billing mode, so any subscription item can carry its own trial instead of the whole subscription sharing one trial window. Per Stripe's changelog and configuration docs, a trial offer is a reusable object: you set a trial price, a trial length measured in billing intervals, and the price the item switches to once the trial ends. You can apply an offer when a subscription is created, attach one to an existing item, or swap an item's current offer for another.
A few details matter for how you'd actually use this:
- It's per item, not per subscription. A single subscription can mix trial items and regular items. You could trial a premium add-on while billing the base plan normally from day one.
- Offers are immutable once created. You can't edit an offer's price or length after the fact. Archiving one only stops it from being attached to new items — subscriptions already running on it keep their terms.
- It only works on flexible billing mode, and it can't be combined with the legacy subscription-level
trial_endparameter on the same subscription, per the Trial Offers FAQ. If you're still on classic billing mode, you'd need to migrate before any of this applies. - The post-trial price has to differ from any price already on the subscription, so you can't use a trial offer to just extend an existing price unchanged.
This is a Stripe Billing feature, not a Stripe Checkout one — the docs describe Checkout support as more limited and still evolving, so check your own Checkout integration before assuming the UI handles it the same way the API does.
Why does a billing API change matter to churn?
Because the biggest lever most early-stage SaaS products have over churn isn't the cancel page — it's whether the person who signs up for a trial ever becomes a customer worth retaining in the first place. Trial design decisions made once, early, keep compounding through every renewal after.
Item-level trial offers make two specific experiments cheaper to run:
- A low-price trial instead of a free one, on just the item you're least sure about (an AI feature, a premium tier, a usage add-on), without re-platforming your whole subscription.
- Different trial-end fallbacks for different items. Stripe lets you configure whether, at trial end, it invoices the customer, cancels the item, or pauses the subscription if there's no payment method on file. You can now make that choice per item rather than for the whole account.
That second point connects directly to involuntary churn. A trial that converts to an invoice against a card that was only entered to "see the product" behaves a lot like a failed payment: the charge fails, and without a recovery sequence the account just goes quiet instead of cleanly cancelling or clearly staying. How Lokuna recovers a failed Stripe payment follows the same logic — chase it with email and SMS before writing it off as churn.
Should your trial require a card upfront?
There's no universal right answer, but the trade-off is well documented and worth knowing before you pick a default. Card-required ("opt-out") trials convert a far higher share of trial users to paid than card-optional ("opt-in") trials — but they also get far fewer people to start a trial in the first place. First Page Sage's benchmark data, cited by Userpilot, puts opt-in trial-to-paid conversion around 18%, versus roughly 49% for opt-out trials that require a card. The same trade-off shows up earlier in the funnel: card-optional trials pull in meaningfully more signups from the same traffic, because asking for payment details before someone has used the product is real friction.
In other words: requiring a card doesn't make people more likely to want your product. It filters out everyone who wasn't going to buy anyway, so the people left over convert at a much higher rate — off a smaller base.
A quick way to decide which fits your stage:
| If you... | Consider... |
|---|---|
| Have low trial volume and need every signal to count | Card-required trial, so trial-to-paid reflects real intent |
| Are still validating whether the product resonates at all | Card-optional trial, to get more usage data before you narrow the funnel |
| Want to test a premium feature without touching your main plan's trial | A per-item trial offer on just that feature, base plan billed normally |
| Worry trial-end invoices are driving quiet non-payments | Set that item's trial-end behavior to cancel or pause, not auto-invoice, until you have a recovery flow in place |
What should you actually test this quarter?
Pick one lever, not all of them at once — trial design changes are easy to misread if you change several things in the same release.
- If you're still on classic billing mode, that's the real prerequisite here. Trial offers require flexible mode, so check which mode your account runs before planning around this feature.
- Try a paid trial on one item, not your whole product. A $1-$5 trial price on a single add-on is a smaller ask than a full plan price, and it still screens out non-buyers the way a card-required trial does.
- Decide trial-end behavior deliberately, per item. Auto-invoicing is fine for items with a card already validated at signup. For anything that started truly free, cancelling or pausing on no-payment-method avoids a trial quietly becoming a failed charge nobody is watching.
- Give each offer time before touching it again. Because offers are immutable and archiving doesn't affect trials already running, you can safely run two versions side by side without disrupting anyone already mid-trial.
Key takeaways
- Stripe's trial offers are now generally available and work per subscription item, not just per subscription, but only in flexible billing mode.
- Offers are immutable once created; archiving stops new use without changing trials already in progress.
- Card-required trials convert roughly 2-3x better to paid than card-optional trials, but pull in far fewer signups from the same traffic — there's no free lunch, only a choice of which number you optimize.
- Trial-end behavior (invoice, cancel, or pause) is now configurable per item, which matters directly for involuntary churn: an auto-invoiced trial that fails is the same problem as a failed payment.
- Test one change at a time, starting with a single item, before touching your main plan's trial.
If a trial-end invoice does fail, that's exactly the kind of failed payment Lokuna is built to chase down with email and SMS before it quietly becomes churn.
