A subscription business loses two kinds of customers: the one who decides to leave, and the one who never decided anything — their card expired, their balance was short, or their issuer threw a generic decline at 2am and nobody told them. That second group is involuntary churn, the recoverable kind, because nothing has to be argued, only fixed.
Most companies answer it with a five-email dunning sequence and then cancel. But the failure is administrative, and email is the slowest channel a business owns. A short call, or an SMS linking to your hosted card-update page, does what a fifth email does not: it interrupts.
Quick answer
Involuntary churn comes from payment failures, not a decision to leave, so it responds to admin rather than persuasion. Triage the decline code first: hard declines need a new card, soft declines a smarter retry. Then use SMS and a short voice call to drive the customer to your own hosted update page. The agent must never take, read back or store card numbers.
Involuntary churn is a different problem from voluntary churn
Voluntary churn is an intent problem: someone weighed the product against the price and decided against you — the territory of reading cancellation intent before the save conversation starts. Involuntary churn is not, so it needs the opposite treatment: a save conversation is unhurried and permission-seeking, a failed-payment conversation fast, factual and over in a minute. Split the two at the source, cancellation event versus terminal payment failure, and report them separately; blended, it hides and nobody funds the work to reduce it.
Step one: triage the decline code, not the customer
Every decline arrives with a reason, and the reason decides whether a retry can work at all. Three rows from Stripe’s decline-code reference:
expired_card— “The card has expired.” Next step: “The customer needs to use another card.”insufficient_funds— “The card has insufficient funds to complete the purchase.” Next step: “The customer needs to use an alternative payment method.”do_not_honor— “The card was declined for an unknown reason.” Next step: “The customer needs to contact their card issuer for more information.”
Three codes, three different messages, and only one is solvable by retrying the same card. Stripe’s payment-retry documentation names nine terminal codes — “Stripe can’t automatically retry a payment if the card issuer returns any of these hard decline codes” — among them incorrect_number, lost_card and authentication_required. Retries stay scheduled, but “the payment only executes if you obtain a new payment method”: the next step is a conversation on a faster channel than email.
Retry cadence: Visa sets a ceiling, your data sets the schedule
Retrying is neither free nor unlimited. Adyen’s documentation on mapping raw responses to Visa system integrity fee categories sets out how Visa divides failed transactions into four categories. Category 1 covers declines where “a retry will never succeed”: “Do not retry the transaction. Visa charges an excessive retry fee if you retry the transaction.” Categories 2 and 4 share an allowance — “You can retry the transaction up to 15 times in a 30-day period. Visa charges excessive retry fees if you exceed this limit” — while category 3, for wrong card details, allows 15 too but adds data quality fees. The most frequent refusal reason, “05: Do not honor”, falls into the generic category 4.
So the card network sets the budget and the fee; inside it, the scheduling is yours. Keep the two straight, because a processor default is not a network rule: Stripe’s Smart Retries figure is a setting you can change — “The recommended default setting is 8 tries within 2 weeks” — and with custom rules, “You can configure up to three retries, each with a specific number of days after the previous attempt.”
Retries and outreach are separate schedules that reference each other. An SMS fired before the automatic retry trains customers to ignore you; sending nothing until attempt eight wastes a fortnight. Trigger contact on the decline class, not the attempt count — the pacing problem in letting follow-up pacing be decided by response rather than a fixed drip.
Channel choice: what belongs where
| Email-only dunning | SMS | Live AI voice agent | |
|---|---|---|---|
| Latency to being seen | Hours to never; competes with a full inbox and billing filters | Minutes; lands on the lock screen | Immediate if answered, nothing if not; needs voicemail and SMS fallback |
| Where to spend it | Every failure; it is the cheap baseline | Soft declines, once a retry has failed | Hard declines, where only a new card will do |
| Consent posture | Weakest constraint; keep transactional and marketing streams separate | Keep it operational; an offer inside it changes its legal character | Strictest; synthetic-voice calls sit inside the TCPA’s artificial-voice regime in the US |
| PCI exposure | None, if it links out and never invites card details by reply | None, if the link goes to your hosted page and no digits come back | The real risk: a call that hears card numbers pulls the agent environment, telephony path and recordings into scope |
The hard rule: the agent never touches a card number
This is the one non-negotiable. An agent — human or AI — must never take, read back, confirm or store a card number, expiry date or security code. Its job is to get the customer to the merchant’s own hosted update page.
The PCI Security Standards Council’s information supplement Protecting Telephone-Based Payment Card Data (v3.0, November 2018) is guidance rather than a standard — every page carries the line that it “does not replace or supersede requirements in any PCI SSC Standard” — but it describes the pattern clearly. On storage: “Sensitive authentication data (SAD) must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment.” It sets out an unattended journey in which “The agent initiates the digital application and sends the customer a link to a secure internet payment system”, the customer then paying independently. And on scope: “Entities should avoid solutions that leave agent environments in scope unless there is an unavoidable business requirement to do so.”
For a recovery call there is no unavoidable business requirement: you have the customer, the subscription and the hosted page, so the call ends with a link, not digits. Build the refusal branch first and test it: if the customer starts reading a card number aloud, the agent interrupts, says it cannot accept card details, and sends the link. None of this is a compliance assessment of any platform, ours included.
Consent and time-of-day: do not assume a service call is exempt
The rules that matter here are written about solicitation and marketing. That does not make an administrative call unregulated, and it is not an exemption: the stricter reading is the safer default.
Australia. The Do Not Call Register’s industry standards page says the Telecommunications (Telemarketing and Research Calls) Industry Standard 2017 “applies to all voice calls made to Australian numbers that: offer, advertise or promote goods, services, land, interests in land, business opportunities or investment opportunities”, advertise or promote suppliers or prospective suppliers of such things, solicit donations, or conduct opinion polling or standard questionnaire-based research. On its face a declined-card call does none of those — but that is a reading you must defend, not an exemption, and an upsell puts you in dual-purpose territory.
Where it applies, the times are specific: telemarketing calls are permitted 9:00am–8:00pm on weekdays and 9:00am–5:00pm on Saturdays, with “No calls allowed” on Sundays or national public holidays, and telemarketers and researchers “are only able to call during the times set out below, unless the consumer has consented to being called at that time.” Treat those hours as the default for service calls too. The ACMA’s guidance on avoiding sending spam covers marketing messages: “If you plan to send marketing messages or emails, you must first have consent from the person who will receive them.” Keep dunning SMS operational and it does not bite; add a discount and it does.
United States. An AI voice changes the analysis. In its Declaratory Ruling released 8 February 2024 (FCC 24-17, CG Docket No. 23-362) the Commission stated: “we confirm that the TCPA’s restrictions on the use of ‘artificial or prerecorded voice’ encompass current AI technologies that generate human voices.” Such calls therefore “require the prior express consent of the called party to initiate such calls absent an emergency purpose or exemption”, and “If these robocalls introduce an advertisement or contain telemarketing, the Commission’s rules require that the caller obtain the prior express written consent of the called party.” On timing, 47 CFR §64.1200(c)(1) bars initiating “any telephone solicitation to… Any residential telephone subscriber before the hour of 8 a.m. or after 9 p.m. (local time at the called party’s location)” — again a solicitation rule rather than a service-call rule, and again a floor worth adopting.
Consent capture and record-keeping belong in the billing flow, not retrofitted at dunning time — see the wording and the records behind consent for AI calls. None of this is legal advice.
What to measure
Public recovery-rate benchmarks vary enormously and usually come from vendors with an interest in the number, without a stated sample or date. We will not quote one. Measure your own, on four axes:
- Recovery rate by decline reason. A blended percentage tells you nothing:
insufficient_fundsandlost_cardare different businesses. - Days to recover. Median and 90th percentile, first decline to successful charge.
- Involuntary churn as a share of total churn. If it is a large slice, dunning is a growth project, not a billing chore.
- Contacts per recovery, by channel. Your defence against spraying SMS at every soft decline.
Run each channel as a holdout for a full billing cycle: recovery is seasonal and a two-week read will mislead you.
Frequently asked questions
What is the difference between a soft decline and a hard decline?
A soft decline is temporary — insufficient funds, a velocity limit, an issuer system failure — so a later attempt may succeed. A hard decline means the card cannot be used at all: Stripe’s retry documentation names nine it will not retry, including lost_card and incorrect_number.
How many times can I retry a declined card?
Visa sets the ceiling, not your processor. Adyen’s documentation on Visa system integrity fee categories says that for categories 2 and 4 “You can retry the transaction up to 15 times in a 30-day period”, with excessive retry fees beyond that, and that category 1 declines — where “a retry will never succeed” — should not be retried at all.
Can an AI agent take my customer’s new card details over the phone?
It should not, and a well-built one will refuse. The PCI Security Standards Council’s Protecting Telephone-Based Payment Card Data supplement (v3.0, November 2018) is guidance rather than a standard, but it is clear on scope: “Entities should avoid solutions that leave agent environments in scope unless there is an unavoidable business requirement to do so.” Send a link to a hosted page instead.
Is a failed-payment call to an existing customer telemarketing in Australia?
Not on its face. The Telecommunications (Telemarketing and Research Calls) Industry Standard 2017 covers calls that offer, advertise or promote goods, services, land, business or investment opportunities, promote their suppliers, solicit donations, or conduct opinion polling or standard questionnaire-based research. But that is your assessment to defend rather than an exemption, an upsell changes the call’s character, and the safe default is to keep to the standard’s calling hours anyway.
What should the call actually say?
Four beats in under a minute: identify yourself and the company, say the payment did not go through, explain the reason class in plain language, and send the link while still on the line. No pitch, no discount, no card numbers.
Where this fits with Zian AI
Zian AI builds autonomous sales and support agents that run live phone, SMS, email and WhatsApp outreach in 30+ languages, with CRM integrations into HubSpot, Salesforce, HighLevel and Zapier. SmartReach AI™ decides message, channel and timing by country, industry and profile — the decision a failed-payment programme makes repeatedly: which declines deserve a call, which a text, and which to retry quietly. Zian AI is in partnership-application beta: Apply For Partnership to see a recovery flow with the card-number refusal branch built in.