Stripe decline code 4700: what it means and how to fix it

If you're seeing decline code 4700 show up on Stripe — or in raw acquirer logs surfaced through Stripe's API — you're looking at an issuer-level refusal dressed up as a soft-decline. It's not a card-invalid error and it's not a Stripe Radar action. It's your customer's bank saying "not this charge, not today." The interesting question for operators is: what do you do next.

1. What 4700 actually is

Code 4700 surfaces in Stripe primarily on certain BINs routed through specific US acquiring banks. It's a variant of the old ISO-8583 "do not honor" family — the issuer has declined but hasn't told the acquirer exactly why. Stripe translates it into a generic_decline for most dashboards, but the raw code is visible in the charge's outcome.network_reason field and webhooks.

2. Why it shows up

Four repeat patterns we see: (a) cardholder's issuer risk model flagged the merchant descriptor against the cardholder's typical spending, (b) velocity limit hit on the cardholder's card for the merchant category code, (c) subscription rebill triggered because the issuer de-prioritizes repeat MCC-5912 charges after a threshold, (d) cross-border charge where the issuer quietly blocks non-domestic processing.

3. Reading the BIN signal

Pull the first 6 digits of the card (Stripe exposes the BIN in the card.bin field in PaymentMethod). If you see the same BIN producing 4700 over and over, that's an issuer policy — not a customer behavior. Chase, Capital One, and credit-union-aggregator BINs generate the bulk of 4700 traffic on high-risk merchant categories.

4. When a simple retry works (and when it doesn't)

A blind retry within 15 minutes almost never works on 4700. A retry with one of three changes works ~35% of the time: different descriptor, different MID, or stepping the transaction up to 3D Secure. Your dunning logic should fire one of those three — not just hammer the same rail.

5. Descriptor switching as a recovery lever

When we see a 4700 from a BIN that approved the same card on a different descriptor in the past 30 days, we route the retry through a brand with a descriptor closer to what the issuer has seen work. That's orchestration logic, not something you get out of a vanilla Stripe install. See descriptor strategy.

6. 3DS step-up as the second lever

Issuers approve 3DS-authenticated charges at materially higher rates after a 4700. Your checkout needs a conditional 3DS trigger rather than always-on 3DS — always-on 3DS adds friction on domestic cards that don't need it.

7. MID switching as the third lever

If you run multiple merchant IDs (different acquirers), routing the retry through a different acquirer changes the issuer's entire view of the transaction. This is where multi-brand operators with real orchestration win. Single-MID operators on Stripe-only can't do this.

8. 4700 vs other Stripe decline codes

4700 is different from generic_decline (catch-all), insufficient_funds (literally NSF), card_velocity_exceeded (issuer velocity cap), and do_not_honor (explicit issuer refusal). In practice they share recovery paths, but 4700 is more retry-responsive than plain do_not_honor.

9. What to tell customer support

When a customer emails saying "my card was declined," the 4700 path isn't "your card is invalid." The correct CS script: "Your bank returned a soft decline on this charge. Please retry or use a different card, or contact your bank to pre-authorize the charge." Telling customers their card is broken when the issuer returned 4700 gets you refund requests.

10. Logging 4700 for trend analysis

Pipe Stripe's charge.failed events into your warehouse with BIN, amount, MCC, descriptor, and 3DS status. After 30 days of data, you can identify which BIN×descriptor combinations produce 4700 reliably and pre-route those to alternative rails. Manual retry logic is leaving 15-25% of recoverable revenue on the floor.

11. Why this gets worse at multi-brand scale

When you're running 8+ brands on separate Stripe accounts, each account has independent BIN data. You can't see that BIN 414720 declined on brand A yesterday and might decline on brand B today. A consolidated orchestration layer with cross-brand BIN intelligence is the multi-brand answer. See Stripe comparison and multi-brand playbook.

12. When 4700 predicts a bigger problem

A spike in 4700 from a narrow BIN range is sometimes the leading indicator of issuer-level fraud block on your descriptor — they've seen enough fraud tagged to your merchant name that they're now pre-declining. That's a signal to rotate descriptors and audit your fraud tooling before the acquirer notices.

Recovery checklist

• Log the raw network_reason code, BIN, amount, descriptor, and 3DS status per decline.
• Build BIN×descriptor×MCC recovery tables from 30+ days of data.
• Route retries with descriptor swap, 3DS step-up, or MID switch — not blind same-rail retries.
• Update CS macros so 4700 is not framed as "your card is broken."
• If 4700 is concentrated on a single BIN range, escalate to the acquirer before the issuer expands the block.

What operators running 5+ brands should do

Single-MID recovery is capped at the levers Stripe exposes. Multi-MID orchestration gives you descriptor pools, BIN-aware routing, and cross-brand decline intelligence. The business case is usually a 2-4% lift in approval rate across the portfolio, which at 8-figure volume is the entire difference between profit and growth. Run our pricing calculator or submit an application for an honest fit check.