People sign up, the trial runs its course, and on conversion day the cards decline, sometimes most of them. Is that normal? Every founder who runs trials posts some version of it eventually.
A few declines are normal. When most of them decline, that's a diagnosis, and it gets fixed somewhere else entirely. We run a card-up-front trial ourselves, so what follows comes with scar tissue: why SaaS trials decline at payment, and the stack that keeps real customers from bouncing off your billing.
The two decline moments
Trials fail at two different doors, and blurring them muddies every fix.
If you take the card up front, the first door is signup, when your flow verifies the payment method. Fraud filters might refuse the zero-dollar or small authorization, or your rules reject the card because it's prepaid or virtual. A bank may demand authentication that the flow fumbles, and an address check can trip on a mismatch. We think of these as qualification events, working as designed in a sense: they filter out payment methods that could never pay, though now and then a legitimate buyer with a cautious bank gets refused too.
Conversion day is the second door, when the real first charge fires. By then a week or a month has passed since anyone looked at that card. Some cards have expired or been reissued in that time, and others have hit their limits or simply run dry. Bank-side refusals come on top, the infamous do-not-honor among them, plus authentication requirements nobody cleared in advance. So conversion day ends up as the leakiest joint in the whole funnel, and many teams never go through it code by code the way they would any other funnel step.
Read the codes before you fix anything
The most useful habit here is also the dullest one: pull the actual decline codes instead of staring at the aggregate rate. Experienced founders give that advice every time this pain comes up, as in this thread:
Is this normal? They sign up for the trial, and their cards decline at the end, most of the trials end up declining.
Split what you pull into soft and hard. A soft decline is temporary, usually insufficient funds or a tripped limit and sometimes an issuer hiccup. The same card can go through tomorrow, and harvesting exactly that is what retry schedules exist for.
A hard decline means the card is closed, stolen or invalid. Retrying it accomplishes nothing except annoying the issuer. Keep the two apart in your reporting from day one, or your recovery stack will always look like it's failing at hard declines it was never built to save. From there, most codes point at their own fix:
| Decline code | Where the fix lives |
|---|---|
| Authentication required | Proper 3DS handling, a solvable engineering task |
| Insufficient funds | Retries (it's a soft decline), especially a few days apart |
| Expired or invalid card | Updater coverage and reminder emails |
| Do-not-honor and generic refusals | Bank-side and mostly unrecoverable directly, though asking for a different payment method sometimes saves one |
| A wall of immediate hard declines on cards that never worked | Somewhere else entirely (next section) |
You're getting AI traffic. But do you know where it comes from?
RankControl credits every visit to the assistant that sent it: ChatGPT, Perplexity, Claude, Gemini, Copilot, or Grok. Full source attribution, next to your Google traffic.
When declines are really an intent problem
That last row isn't a billing problem at all. When nearly every conversion declines, the cards usually were never a genuine payment path. Some belong to trial-hoppers cycling through prepaid and virtual cards. Others belong to signups who always meant to ride the trial and let the card bounce, and both groups produce technically perfect declines that no retry schedule will ever recover.
You'll see it in the data. Prepaid BINs dominate the failures, and they come back as immediate hard declines rather than soft ones. The failure rate is far beyond anything billing infrastructure could explain, and the declining accounts had stopped touching the product by day two.
So the fixes live upstream of billing. A small authorization or nominal charge at signup confirms the card is real before anyone consumes trial resources. Blocking prepaid BINs, where your processor allows it, takes away the trial-hopper's favorite tool. The deepest fix is acquisition quality, because where your first users come from shapes who reaches the payment form at all. Traffic from genuine buyer research declines the way customers do, and traffic from incentives declines like tourists.
Card up front, or card at the end?
Which decline problem would you rather have? That's the trial-design choice upstream of all this, and I'd make it on purpose.
Taking the card up front moves the pain to signup. Your signups drop but their intent rises, and the never-real cards fall out before they eat onboarding attention and support time. Going cardless puts the pain at conversion instead. Signups go as high as they'll go and day one has zero friction, but every ounce of payment risk lands on the single worst moment, the day you ask trial users to become customers.
Either design works if you pick the door where you want to meet your declines and build that door properly. The trouble comes from mixing mechanics: running cardless and then acting surprised by conversion declines, or taking the card up front without the small authorization that makes the filter actually filter.
The reduction stack, in deployment order
For the declines that really are infrastructure, the defenses stack. The table runs roughly in order of return on effort:
| Order | Defense |
|---|---|
| 1 | Pre-charge reminder, two to three days before conversion |
| 2 | Smart retries across several days |
| 3 | Card updater coverage |
| 4 | Graceful 3DS |
| 5 | Wallets and backup methods |
| 6 | Dunning with a grace period |
Why does a plain reminder email earn the top spot? One send does two jobs. When you state the date and amount plainly, it turns surprise declines into updated cards and cuts disputes, and since card networks increasingly expect notice before a trial turns paid, the same email covers compliance.
The next two need nothing from the customer. Funds and limits are temporary problems, so a spaced retry schedule recovers a meaningful slice of soft declines by itself. The network updater your processor offers quietly refreshes reissued and expired cards, the most mechanical failure class there is.
On 3DS, handle challenges inside the flow at signup and re-trigger them cleanly at conversion where required, so a cautious bank becomes a step instead of a dead end. Apple Pay and Google Pay cut entry errors and carry their own freshness. An easy way to add a backup method gives your dunning somewhere to go.
Dunning comes last. Keep access open for a short window while the card gets fixed, and send clear emails with a one-click path to the update-card page. Write them assuming good faith, since most involuntary churn is customers who'd happily pay if fixing the card were frictionless.
What we run ourselves
RankControl runs a seven-day card-up-front trial, and a pre-charge notice goes out when the trial activates, so the charge date never comes as a surprise. If a payment fails, a grace window holds before anything about access changes.
Taking the card first means our declines front-load to signup, where the authorization filters out never-real cards cheaply, and conversion-day failures shrink to the mechanical classes the stack above recovers. None of it is exotic. Running it taught us that each layer earns its keep on a different failure class, which is why partial deployments keep leaking.
We paid for that setup in signups, and we knew we would. Some legitimate buyers bounce off any card form, and we accepted that trade for cleaner cohorts and declines we can actually diagnose.
We'll show you exactly where your brand stands in AI search.
No commitment. $0 due today, cancel anytime. See how ChatGPT, Perplexity, Claude, Gemini, Grok, Google AI Mode, and Google AI Overviews talk about your brand today.
Processor realities
What you can deploy comes down to how many knobs your processor gives you. A full-control processor exposes decline codes, retry scheduling and BIN rules directly, along with updater services, and the diagnostic approach above assumes that access. Merchant-of-record platforms go the other way: they take tax and compliance off your plate but expose fewer levers, and founders on them routinely find that the dunning customization they wanted isn't there.
Neither choice is wrong, as long as you make it knowing that payment-failure reduction is largely a control-surface game. If involuntary churn ever becomes your binding problem, reopen the processor decision with that weight on the scale.
A twenty-minute diagnostic before you buy anything
Before you add any recovery tooling, spend twenty minutes on processor-export archaeology to find out which problem you actually have:
- Pull the last ninety days of failed payments from your processor and split them into signup and conversion-day failures.
- Group the conversion failures by decline code and sort by count.
- Flag the share that came from prepaid or virtual BINs.
- Work out one ratio: of the soft declines, how many eventually succeeded on any retry?
Say insufficient-funds and expired-card codes dominate and the retry-success ratio is low. Then the reduction stack above will pay for itself within a quarter. If immediate hard declines on prepaid cards dominate instead, no billing tool on earth fixes acquisition, and your budget belongs upstream in traffic quality.
The number that deserves its own dashboard
Measure the result the way you'd measure any other funnel leak. Track involuntary churn apart from cancellations, and grade the stack on recovered-payment rate instead of vibes.
How much of your churn is really a payment failure dressed up as a cancellation? Most teams genuinely don't know. Blended churn hides a recoverable, mechanical leak inside a number they've accepted as fate, and pulling the two apart takes one afternoon of dashboard work that pays back every month after.
Declines will never reach zero, and some trials were always tourists. Still, the recovered revenue sits in the gap between accepting that and measuring it, which is why the decline-code mix deserves a weekly glance next to your funnel numbers.
Know exactly what AI says about your competitors.
RankControl's Recon Agent monitors competitor citations across ChatGPT, Perplexity, Claude, Gemini, Grok, Google AI Mode, and Google AI Overviews. See where they show up and you don't.
