Stripe Decline Code Explainer
Look up any Stripe decline code in plain English. See whether the charge is recoverable, when to retry, what to email the customer, and what ChurnNote does automatically.
Card
Funds
Auth
Bank
Fraud
Technical
expired_card
Expired cardHighly recoverable- What it means
- The card on file passed its expiration date. The charge will never succeed until a new card is on file. This is one of the most common involuntary churn causes and one of the easiest to recover.
- Should you retry?
- Do not retry. Wait for the customer to update the card.
Email to send
Subject: The card on your {product} account expired
Hi {name},
The card on your {product} account expired, so we couldn't process your last payment.
Update it here in 30 seconds and we'll re-run the charge:
{update_link}
Your account stays active in the meantime.
{founder}What ChurnNote does
Detects the expired_card decline, pauses Stripe retries (since they will never succeed), and emails the customer with a card-update link from your inbox. Tracks whether the card was updated.
Why decline-code-aware dunning recovers more revenue
Stripe gives you a decline_code on every failed charge. Most dunning tools ignore it, sending the same "your payment failed" email regardless of whether the card expired, the bank flagged fraud, or the customer just needs to confirm a 3D Secure prompt. That generic approach leaves recovery rates on the table.
Matching the message to the code lifts recovery rates from the 15-25% baseline (Stripe smart retries alone) to 50-70% in our experience. The customer feels the email is about them, not about your billing system, and they act faster.
Frequently Asked Questions
Where do I find the decline_code on a Stripe charge?
On any failed charge in the Stripe dashboard, click into the charge and the decline_code appears in the 'Decline' section. Programmatically, you'll find it on the Charge object as `outcome.reason` and on the PaymentIntent's last_payment_error.decline_code field.
Should I always retry a failed charge?
No. Retrying expired_card, incorrect_cvc, lost_card, stolen_card, or fraudulent declines will never succeed and can trigger network-level penalties. Stripe's smart retries handle this for you, but if you're building your own dunning, treat retry behavior as code-specific.
What is decline_code vs failure_code?
Stripe exposes both. `decline_code` is what the issuing bank returned (e.g. expired_card, insufficient_funds). `failure_code` is Stripe's own categorization, which is sometimes more abstract. Decline_code is the field you want for dunning logic.
What is authentication_required?
It's Stripe's signal that Strong Customer Authentication (SCA) is required, typically for European cards. The charge is paused until the customer confirms it in their banking app via 3D Secure. You can't fix this by retrying; you must send them a confirmation link.
How does ChurnNote use decline codes?
ChurnNote reads the decline_code on every failed charge webhook, decides whether to retry, picks a code-specific email template, and tracks recovery rates per code. Codes like expired_card and authentication_required get different emails than insufficient_funds.
How ChurnNote helps
Generic dunning treats every decline the same. Decline-aware dunning recovers two to three times more.
ChurnNote connects to Stripe or Lemon Squeezy and automatically captures cancellation reasons, recovers failed payments, and queues win-back emails. So you stop losing revenue silently.
Start recovering churnNext step
Full dunning swipe file
Plain-text email templates for the most common decline scenarios, ready to copy or run automatically with ChurnNote.