Stripe Decline Code · Glossary
call_issuer fires when the customer's bank wants to speak with the cardholder directly before authorizing the transaction — it is a verification-pending soft decline, not a final rejection.
What It Means
What It Means
call_issuer fires when the customer's bank wants to speak with the cardholder directly before authorizing the transaction — it is a verification-pending soft decline, not a final rejection. The bank has flagged something that requires cardholder confirmation before it will approve the charge — the card is valid, the account may be funded, but the issuer is holding the authorization pending a direct conversation with their customer. Think of it as the bank putting the payment on hold with a question mark rather than a hard stop.
Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →
Why It Happens
Why It Happens
What NOT to Do
What NOT to Do
✕ Don't retry before the customer calls their bank
Unlike generic_decline where a timed retry sometimes resolves the issue, call_issuer requires explicit cardholder verification before the bank will approve anything. Retrying without that confirmation produces the same decline every time — the hold is not time-resolved, it is action-resolved. Every retry before bank contact is a wasted attempt.
✕ Don't confuse it with do_not_honor and apply an identical workflow
Both codes require bank contact, but call_issuer is meaningfully softer — the bank is asking for verification, not refusing the transaction. Your email copy must reflect this nuance: do_not_honor language should be more neutral and cautious; call_issuer language can be warmer and more directly action-oriented — "your bank just needs to confirm this payment with you."
✕ Don't delay customer outreach
call_issuer is one of the few codes where the recovery window is tight and speed matters most. The bank's verification hold may have a time limit — if the cardholder doesn't confirm within the hold window, the bank may escalate the flag from a soft verification hold to a harder restriction. Your Day 0 email within 60 minutes is not optional here, it's essential.
Retry Timing
Retry Timing
call_issuer follows a bank-contact-first gate — all retries are conditional on customer confirmation of bank contact.
Recovery Benchmark
Recovery Benchmark
| Metric | Result |
|---|---|
| Overall recovery rate | 35–55% |
| Recovery when customer calls bank within 4 hrs | 55–65% |
| Recovery when customer calls bank after 24 hrs | 30–35% |
| Recovery via alternate payment method | +12–15% additional lift |
| Recovery with blind retries only | ~8–12% |
| Customer action rate on bank-call email | ~35–45% |
A 50%+ overall recovery rate on call_issuer is achievable when your Day 0 email fires within 60 minutes and includes a clear, warm bank-call script with the exact words to say. Teams with a 24-hour+ email delay typically see recovery rates halve compared to sub-hour outreach — making your email automation speed the single most important variable for this code.
At Scale
At Scale
Automated
Manual Escalation
FAQs
FAQs
What does the Stripe call_issuer decline code mean?
call_issuer means the customer's bank wants to speak with the cardholder before authorizing the transaction. It is a soft, verification-pending decline — not a final rejection. The bank has flagged something requiring cardholder confirmation, and the transaction can still go through once the customer calls their bank and confirms the charge is authorized.
What are the most common causes of a call_issuer error in Stripe?
Common causes include the bank's risk engine flagging an unusual transaction pattern, a soft fraud prevention hold requiring verbal cardholder confirmation, an account under routine identity or KYC verification, a large or first-time recurring charge that the bank wants confirmed, and a recently reactivated card requiring cardholder contact to authorize new charges.
What should my customer do when Stripe returns call_issuer?
Ask them to call the number on the back of their card immediately and say: 'I want to confirm a recurring payment to [your company name] for [amount] — please authorize this charge.' Providing this exact script in your email significantly increases action rates. Once the customer confirms with their bank, trigger a retry within 60 seconds — the authorization window is widest immediately after the call.
How quickly should I contact the customer after a call_issuer decline?
Within 30–60 minutes. call_issuer has the highest time-sensitivity of any bank-contact-required decline code. Customers who receive the bank-call prompt within 60 minutes and contact their bank within 4 hours of the decline recover at 55–65%. Customers contacted after 24 hours drop to 30–35% recovery. Email automation speed is the single most important variable for this code.
What is the recovery rate for Stripe call_issuer failures?
Overall recovery rates are 35–55%. When customers call their bank within 4 hours of the decline, recovery reaches 55–65%. After 24 hours, recovery drops to 30–35%. Adding an alternate payment method offer from Day 3 provides an additional 12–15% recovery lift for customers who don't complete the bank call.
What to do next
You are here
call_issuer
Decline code reference
Check recoverability
Stripe Failure Lookup
See what's recoverable — and what isn't →
Then
Sign up for Recurflux
Automate recovery for every decline code →
Before you retry
Before you retry
Most call_issuer failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.
Stop leaving revenue on the table
Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.