Where trial payments actually fail
A free trial with a card on file has two moments of risk. The first is signup, when the card number is typed in and the issuer has never seen your business. The second is the end of the trial, when the first full charge runs weeks later against a card that may have expired, been replaced, hit its limit or been frozen after a suspicious purchase somewhere else. Most teams only instrument the second moment, because that is where the failed invoice shows up in the billing dashboard. By then the buyer has already used the product, mentally filed the trial as free, and may not read the email that tells them something went wrong.
Two kinds of failure behave very differently, and mixing them up leads to the wrong fix. A soft decline is temporary: the issuer said no this time, perhaps because of a daily limit or a flag on an odd hour of the day, and a later attempt can succeed. A hard decline is final until the customer supplies a different card: a lost or stolen card, a closed account, a number that no longer exists. Retry schedules rescue soft declines. Only a conversation with the customer rescues a hard one. The card decline rate and the failed payment rate glossary pages define how to measure each, so the numbers you track mean the same thing from month to month.
Pre-authorization attacks a third kind of problem that sits before both: the card that was never good enough for the plan price in the first place. A card with a low limit, a prepaid card with a small balance or a card that the issuer declines for subscription-style charges will pass a simple card-validity check and fail the real charge. Finding that out on day one, while the buyer is still on your signup page and able to type another card, costs nothing. Finding it out on day fourteen costs a trial that looked healthy in every report until the moment it was supposed to convert.
What a pre-authorization is
When you create a card payment you can ask the processor to authorize it without capturing it. Stripe documents this as separating authorization from capture: the amount is reserved on the customer's card, the funds are not moved, and you capture later. The payment shows as uncaptured, and the capture request turns the reservation into a charge. Hotels use the same mechanism, reserving the room cost at booking and settling at checkout.
The reservation does not last. If the authorization expires before you capture, the funds are released and the payment moves to canceled. Stripe lists the validity windows for card payments that are not in person, and they depend on the card brand and on whether the issuer treats the payment as started by the customer or by the merchant.
| Card brand | Merchant-initiated window | Customer-initiated window |
|---|---|---|
| Visa | 5 days (4 days and 18 hours exactly) | 7 days |
| Mastercard | 7 days | 7 days |
| American Express | 7 days | 7 days |
| Discover | 7 days | 7 days |
Stripe adds a caution that matters for trials: the card network and Stripe decide whether a payment counts as customer-initiated or merchant-initiated from signals of cardholder participation, not only from API flags. A payment flagged as off-session can still be treated as customer-initiated if the security code was present. Plan around the shorter window and treat the longer one as a bonus.
What a hold tells you at signup, and what it does not
Holding the real plan price, rather than a token amount, tests the exact thing you will need later: that this card, today, can cover this amount. Stripe notes that card networks may restrict authorizations of one dollar that you do not intend to capture, which is a second reason to hold the true price instead of a probe. A successful hold tells you the card number is valid, the card is active, the issuer has approved a purchase of the full amount and the funds exist right now.
It does not tell you the card will still work in two weeks, and it is not a promise from the issuer about a later charge. A hold is a snapshot. Between the hold and the final charge the customer can spend the available funds, lose the card or cancel it, and the issuer can change its own risk decisions. Treat the hold as the best early signal you can get, not as proof of payment.
Fitting a hold into a trial length
The windows above are shorter than most trials. A hold placed at signup on a 14-day trial will expire halfway through. There are only a few ways to deal with that, and the table shows how far each trial length overshoots the 7-day customer-initiated window, and how many fresh merchant-initiated holds of 5 days would be needed to cover the rest.
| Trial length | One hold covers it | Days past the 7-day window | Extra 5-day holds needed |
|---|---|---|---|
| 3 days | Yes | 0 | 0 |
| 7 days | Yes | 0 | 0 |
| 14 days | No | 7 | 2 |
| 30 days | No | 23 | 5 |
- Capture shortly before the hold lapses and carry the money as a credit against the first invoice. This works when the trial is short enough for one hold, and it keeps the buyer from paying twice only if the credit is applied in the right order.
- Replace the hold with a new one before it expires. This is the approach for longer trials, and it needs a saved card and a job that wakes up on time, because a missed renewal means the original hold simply lapses.
- Skip the hold and rely on a card check at signup. This is simpler, and you give up the day-one test of the plan price.
Stripe also documents that you can capture less than the held amount, in which case the remainder is released, and that most payments allow a single capture only. If you capture a partial amount you cannot go back for the difference, so decide the capture amount before you capture. TrialValid's card holds page describes how one implementation handles the capture, the credit and the renewal of a lapsing hold.
The declines a hold cannot prevent
Stripe lists the hard decline codes it will not retry: an incorrect number, a lost card, a pickup card, a stolen card, revoked authorizations, an authentication requirement, the highest risk level and a transaction the card is not allowed to make. Scheduled retries continue for these, but the payment only runs once a new payment method is present. India-issued cards, a disconnected Connect account and a customer with no payment method also stop retries. If you track only one number, track how many failed trial charges fall into this group, because that is the share no retry schedule can touch.
Declines also come from your own side. Stripe's declines guide separates issuer declines from payments its fraud tooling blocks and from invalid API calls, and it points out that you should analyze unique declines rather than counting failed retries, which inflate the rate. A decline that arrives because your integration sent the wrong parameters will never be fixed by a smarter retry timetable.
Retries for the soft declines
Smart Retries uses signals such as the number of devices that presented a card recently and the best local time to pay for certain debit cards to choose retry moments. The setting Stripe recommends is 8 tries within 2 weeks. You pick a retry count and a window: one, two or three weeks, one month or two months. A custom schedule allows up to three retries, each a set number of days after the last one. When recovery fails you choose what happens to the subscription: cancel it, mark it unpaid, leave it past due or pause it when eligible.
Stripe states an average recovery rate of 55% for businesses using Stripe Billing, on its billing product page read 18 Oct 2026. Treat that as a published average from the processor, not a prediction for your business; your own recovery rate depends on your mix of soft and hard declines.
Emails that recover payments before a retry does
Retries work without the customer. Emails work with them, and they are the only tool for a hard decline. Stripe's customer email settings cover the notices that matter for a trial: a failed payment email after each failed attempt, a trial ending reminder 7 days before the trial ends, a renewal reminder before the period ends, an email a month before a card on file expires and a confirmation request for payments that need extra authentication. Each carries a link to a page on which the customer can change the payment method, hosted by Stripe or by you.
Write the failed payment email as a task, not an alarm. Say which plan, which amount, what the customer needs to do and how long the fix takes. A customer who can update a card in one click will do it. A customer who must log in, find billing settings and guess which card to update will not.
What the money looks like: a computed example
The failed payment recovery calculator at its defaults assumes $2,500 of renewals a month fail on the first try, a 40% recovery rate today and a comparison rate of 55%. It returns $18,000 lost a year at today's rate and $4,500 saved a year at the comparison rate. Replace the defaults with your own failed payment rate and recovery rate before drawing any conclusion, because the result scales directly with both.
| Step | Who acts | Soft decline | Hard decline |
|---|---|---|---|
| Hold at signup | Processor, issuer | Surfaced early, buyer can retype a card | Surfaced early, buyer can retype a card |
| Capture before the hold lapses | Your job | Usually succeeds | Fails and is reported |
| Smart Retries | Processor | Often recovers | Does not run until a new card exists |
| Failed payment email | Customer | Helps when the cause is a limit or expiry | The only route to recovery |
| Expiring card email | Customer | Prevents the decline | Prevents the decline |
A rollout order that does not need an engineer a week
- Measure first: split last quarter's failed charges into soft and hard declines, and note how many were first-ever charges after a trial.
- Turn on the customer emails Stripe already offers, especially the trial ending reminder and the expiring card notice. They cost nothing to enable.
- Set the retry policy to the recommended default and read the result after a full cycle before changing it.
- Add the day-one hold for new trials, holding the real plan price, once you know how many trials fail at the first real charge.
- Review the numbers monthly and change one setting at a time, so a movement in the recovery rate has an explanation.
Does a hold charge the customer?
No. A hold reserves the amount on the card. Some issuers show the pending authorization in the banking app, which can confuse customers, so say on the signup page that nothing is charged today.
How long can I hold a card for a trial?
For card payments that are not in person, Stripe lists 5 to 7 days depending on brand and who started the payment. Longer trials need a renewed hold or a different approach.
What if the hold fails at signup?
The trial should not start. The buyer sees an error on the page and can try another card, which is far cheaper than a failed charge two weeks later.
Do retries work on every failure?
No. Stripe does not retry hard declines until a new payment method exists, and it does not retry when no payment method is available.
Should I hold the full plan price or one dollar?
Hold the real price. Card networks may restrict one dollar authorizations that are never captured, and a token amount does not test the amount you need later.
Sources
- Stripe: Place a hold on a payment method, read 19 Oct 2026
- Stripe: Automate payment retries (Smart Retries), read 19 Oct 2026
- Stripe: Revenue recovery, read 19 Oct 2026
- Stripe: Automate customer emails, read 19 Oct 2026
- Stripe: Declines, read 19 Oct 2026
- Stripe Billing, read 19 Oct 2026