Guide

Where free trials leak revenue

The five joints where a card-backed free trial loses revenue, which ones the sources let you size, and how to measure each in your own data.

By Meralume Labs. Published . 7 min read

A trial can lose revenue at the card step, at the end of a trial with no card, at the first charge and in the way the first invoice is built. The sources let us size the first three, and each one has a setting or a measure you can act on.

The path a trial takes to a first payment

Think of a trial as a pipe with joints. Revenue does not drain out of the middle of a good trial. It drains at the joints, where one system hands the buyer to another: the page hands them to a form, the form to a card network, the trial to an invoice, the invoice to a bank. Each joint has its own failure and its own repair, and each is easier to fix than the broad question of why trials do not convert.

JointHow revenue leaks thereWhat the sources give
Sign-up formFriction before the trial startsSign-ups and payers per 1,000 visitors, by trial type
Trial without a cardThe trial ends and no payment method is on fileThree documented end behaviors
First chargeThe card is declinedHard declines are not retried; a recommended retry schedule
First invoiceThe amount or date is not what the buyer expectedBilling anchor behavior after a trial
ReportingTrial revenue does not appear in MRRStripe analytics exclude it while a trial runs

Joint one: the sign-up form

The ChartMogul conversion report converts its survey answers into a per-visitor view, and the view shows a leak that is also a gain. Each row below starts with 1,000 website visitors. The revenue column is ours: the paying customers in the row times a price of $49 a month, an illustrative price.

Trial typeSign-upsPaying customersPaying share of sign-upsMonthly revenue at $49
No card before the trial453.68.0%$176.40
Card before the trial3510.530.0%$514.50

The card step costs 10 sign-ups per 1,000 visitors in this data. It adds 6.9 payers. The leak is real, and so is the larger gain next to it, which is why it is worth counting both before you decide to remove a form field. These are average figures from 200 products in a survey. Your own numbers can sit anywhere, so use your analytics to fill the same two columns.

Joint two: trials that end with no card on file

If your trial starts without a card, which 80% of the free trial products in the report do, a trial ends one of three ways in Stripe. You choose which when you set up the subscription, and the choice is a revenue decision as much as a technical one.

End behaviorWhat happensWhen it suits
Create an invoiceAn invoice is created at trial end. If it cannot be paid, the subscription moves to past due.You want the standard dunning path to chase the buyer.
CancelThe subscription cancels immediately when the trial ends with no payment method.You prefer a clean stop and a fresh sign-up later.
PauseThe subscription pauses and creates no invoices. It can stay paused indefinitely and resume when a card is added.You want a one-click way back for someone who liked the product.

Pausing keeps the door open for the buyer who meant to pay and did not get around to it. Stripe documents a hosted page where the customer can activate a paused subscription by adding a payment method, and the reminder email links to it. Stripe also warns that a free trial with no card lets spammers create fake customers, and recommends an account and a captcha before the trial starts.

Joint three: the first charge fails

A trial that ends well still has to be paid by a card that works. Stripe retries a failed subscription payment automatically, and its recommended Smart Retries default is 8 tries within 2 weeks. It does not retry a hard decline, which covers lost, stolen and pickup cards, an incorrect number, a revoked authorization and a payment that needs authentication. For those, the retries are scheduled but only run once the customer supplies a new payment method. That is why the email asking them to update the card matters as much as the retry.

Stripe publishes an average recovery rate of 55% of failed payments for businesses on Stripe Billing. Treat that as the vendor's own average across its base. As an illustration, take a month of trials like the calculator's default cohort, $2,940 of first-month revenue. If 8% of that value fails on the first try, a what-if input, and you recover 40% of it today, the failed payment recovery calculator shows $235.20 failing each month and $141.12 lost, which is $1,693.44 a year if every cohort looks the same. Recovering at Stripe's average instead would save $423.36 a year.

Joint four: the first invoice does not match the expectation

When a trial offer ends, Stripe lets you choose what happens to the billing cycle. By default it resets the billing anchor to the moment the trial ends, so the buyer gets a full billing period from that date and a full-amount invoice with no proration. With the setting left unchanged, the original anchor stays and the time between the trial end and the next anchor date is prorated. Both are valid. A buyer who expected one and received the other is the one who writes in about the charge.

Decide which you intend, say it on the page and in the reminder, and check one real test subscription end to end before launch. A mismatch between the promised and the actual first invoice is the leak that costs trust as well as revenue.

Joint five: the report that hides the trial

This leak does not lose money, but it hides it. Stripe's billing analytics do not count revenue from items in a trial toward MRR while the trial runs, for both free trial periods and trial offers. A growing trial base therefore looks like a flat MRR line for the length of the trial. If you read that line without knowing, you may blame a conversion problem for what is only a delay. Track trials started and trials paid on their own, as in the trial conversion rate calculator, alongside the MRR calculator.

A leak ledger for your own trials

Keep one row per leak and fill it from your own data. Stripe sends events for most of these, so the ledger can run from your webhook log.

LeakWhat to countWhere it comes from
Sign-up frictionVisitors, sign-ups and payers per 1,000 visitorsYour analytics and your subscription list
No card at trial endTrials that ended cancelled or paused, by causeSubscription deleted and paused events
Hard declinesFirst charges that failed with a hard decline codeThe payment failed event and its decline code
Retry outcomesFirst charges recovered after each attemptThe attempt count on the payment failed event
First invoice surprisesSupport contacts about the first chargeYour inbox, tagged

After a month you will know which row is largest. Fix that one first. The order the sources suggest for most products is card step, first charge and end behavior, and the guide to ranking levers by evidence explains why.

Questions about trial leaks

What is the single biggest leak?

It depends on your product. The only sizing in these sources is the card step, where the report shows fewer sign-ups and more payers per 1,000 visitors on average. Fill your own ledger to find yours.

Does Stripe retry every failed payment?

No. A hard decline is not retried until a new payment method is on file, so the customer email with a link to update the card does real work.

Should a trial without a card pause or cancel at the end?

Pausing keeps a one-click path back for someone who liked the product. Cancelling gives a clean stop. Neither has a published conversion figure in these sources, so pick one and measure.

Why does my MRR look flat when trials are growing?

Stripe does not count revenue from items in a trial toward MRR while the trial runs, so growth shows up when trials convert.

Is the 55% recovery rate something I should expect?

It is Stripe's published average for businesses on Stripe Billing. Use it as a reference for the calculator, not as a forecast.

Sources