What does Stripe decline code 4100 mean

Code 4100 is another one of those opaque numeric declines that Stripe surfaces without much explanation. It lives in the outcome.network_reason field on a declined charge, often bundled with a Stripe-level generic_decline. Operators see it most on US-issued cards routed through specific BIN ranges and it has a meaningfully different retry profile than 4700 or 4600.

1. What 4100 actually is

A response code in the ISO-8583 "do not honor" family, 4100 indicates the issuer received the authorization request and decided to decline without revealing the reason to the acquirer. Stripe relays the raw code in API responses; the dashboard usually just shows "generic_decline."

2. Why 4100 is different from 4700

4700 tends to come from large bank issuers (Chase, Capital One) with risk models that react to merchant descriptor + MCC + amount. 4100 is more common on credit-union and smaller-issuer BINs and tends to fire on velocity limits or daily spending caps. That changes the retry strategy: 4100 often clears with a small amount delta (try $99.95 instead of $100.00) or a 15-30 minute delay, whereas 4700 needs a descriptor/MID/3DS change.

3. The retry strategy that works

On first 4100 decline: wait 20 minutes, retry the exact same amount. Success rate ~35%. On second decline: modify the amount by $0.05-$0.50 (Stripe's payment_intent.capture_method=manual with a recreated PaymentIntent) and retry. Success rate ~55% total. On third decline: stop and ask the customer to switch cards. Further retries compound issuer suspicion.

4. Subscription rebill and 4100

For subscription merchants, 4100 on a rebill is often the result of the issuer putting a velocity cap on the card that month. The retry should be delayed 24-72 hours, not 20 minutes. Stripe Smart Retries handles this decently; custom dunning stacks need to match the cadence.

5. BIN concentration analysis

Pull 30 days of 4100 declines grouped by BIN. If one BIN range (first 6 digits) shows a disproportionate 4100 rate — say 15%+ vs the portfolio average of 3% — that is an issuer-level event. Either the issuer has de-prioritized your descriptor/MCC, or the issuer ran a fraud cleanup campaign that caught your MID, or the issuer changed policy.

6. When 4100 is a Stripe Radar false

Occasionally Stripe Radar triggers a pre-decline that surfaces as 4100 in the network_reason. Check Radar's risk score on the charge — if it is over 65, Radar intercepted before the issuer even saw it. Stripe will sometimes mis-tag the reason. In those cases, Radar tuning fixes it, not the issuer.

7. Cross-border 4100

A US card charged on a non-US acquirer sometimes returns 4100 because the issuer policy is to reject non-domestic charges on a specific BIN range. If your Stripe account is processing through a non-US acquirer (Stripe Ireland, Stripe UK) and you have US customers, 4100 rates can spike. Fix: route US volume through a US-acquired rail.

8. What to log

Every 4100: timestamp, BIN, amount, descriptor, subscription vs one-time, 3DS status, Radar risk score, customer email hash. After 30 days of data the retry strategy writes itself.

9. 4100 as a leading indicator

A 4100 rate climbing week-over-week is often leading indicator for a Stripe Radar retuning or an issuer block. Watch the ratio; alert when it crosses 5% of authorization attempts.

10. 3DS impact on 4100

Unlike 4700, 4100 does not reliably improve with 3DS step-up. The issuer is not declining on fraud suspicion; it is declining on policy. 3DS-authenticated 4100 retries succeed about 5% more often than unauthenticated — not a game-changer.

11. Customer-facing messaging

"Your card issuer declined this charge. Please try again in a few minutes, use a different card, or contact your bank." Do not say "your card is invalid" — the card may be perfectly valid and tomorrow's charge may succeed. Telling the customer the card is broken triggers unnecessary card replacements and lost customers.

12. Multi-brand pattern

When you run 8 brands, the same BIN can 4100 on one brand and approve on another because the descriptors differ. An orchestration layer that routes based on recent BIN history per descriptor recovers 8-15% more authorization on 4100-prone BIN ranges. See orchestration vs Stripe.

Recovery checklist

• Log raw network_reason, BIN, amount, Radar score per decline.
• 20-minute delay on first retry; small amount delta on second retry.
• Subscription retries: 24-72 hour delay, not 15 minutes.
• BIN concentration > 10% = issuer-level event, not customer problem.
• Cross-border 4100 clusters = route US volume through US acquirer.

13. Case study — subscription nutra operator

A $400k/month nutra operator saw 4100 rates spike from 3% to 9% of authorization attempts over 6 weeks. Initial instinct was to tune Radar more aggressively. Actual root cause: one top-10 BIN range (Capital One quicksilver) added velocity limits on subscription MCC 5499. The 9% was concentrated on that BIN; ex-that-BIN the 4100 rate was still 3%. Fix was adding a BIN-specific retry rule that waited 5 days instead of 20 minutes and offered the customer an ACH alternative after second decline. Recovery rate on that BIN cohort went from 18% to 64%.

14. The dashboard tile that matters

Build a simple dashboard tile: "4100 rate, last 7 days, by BIN." Display the top 10 BINs with 4100 concentration above portfolio average. When a new BIN climbs the leaderboard, investigate before it becomes a portfolio-wide pattern. Most operators do not monitor this granularly and discover issuer policy shifts through symptom rather than signal.

15. Working with the CS macro library

Customer service scripts for 4100 should differ by retry-attempt count. First decline: "please try again in 15 minutes." Second decline: "try a different card or contact your bank." Third decline: "your card issuer has temporarily declined this charge; we can offer ACH or we can hold your order 48 hours while you resolve with the bank." Escalating language matches escalating customer friction and reduces refund requests.

What separates recovery from lost revenue

Blind retries compound decline rates. Differentiated retries recover 15-35% of lost revenue depending on vertical. See 4700 playbook for the sibling code, pricing for orchestration that implements differentiated retries by default, or apply for a decline-rate audit on your current volume.