Stripe payment blocked with "do_not_try_again"? Why retrying won't help

Your Stripe charge didn't fail at the bank — it never got there. The outcome reads type: "blocked", reason: "highest_risk_level", network_status: "not_sent_to_network", and crucially advice_code: "do_not_try_again". Stripe Radar stopped it. And the payment layer is telling you, in a field, not to retry — so retrying is the one thing not to do.

Reading the outcome

When Stripe blocks a payment, the outcome object tells you what happened and what to do. The fields that matter:

• type: "blocked" — Stripe (not the issuer) stopped the charge. The card was never charged.
• reason: "highest_risk_level" — Radar's default block fired. ("rule" means one of your custom rules did.)
• network_status: "not_sent_to_network" — it never reached the card network, which is why there's no bank decline code.
• advice_code: "do_not_try_again" — the explicit signal: retrying will not succeed.

What to do instead of retrying

1. Read outcome.reason. highest_risk_level = Radar default; rule = your custom rule. That tells you whether to adjust a rule or accept the risk assessment.
2. If it's a legitimate customer, add them to the Radar allow list in the Dashboard. That overrides the block for future attempts — retrying without it just repeats the block.
3. Surface it to a human. A blocked high-risk payment is a decision, not a transient error. Don't loop on it.

For agents handling payments

An autonomous agent will treat a failed payment as retryable unless told otherwise — and here, retrying is both futile and a sign the agent isn't reading the outcome. diagnose_infra_error returns the procurement family with the fix, so the agent stops, reads the outcome, and escalates instead of burning attempts:

diagnose_infra_error({error: "outcome type blocked do_not_try_again highest_risk_level"})
// → { family: "procurement",
//      fix: "do not retry — Radar block; add to allow list if legitimate, else surface to a human" }