The signal in Stripe

The charge fails with a fraud-flavored decline: codes like fraudulent or a do_not_honor that follows a fraud alert. The customer's bank decided the transaction looked suspicious and blocked it before it reached the account balance.

Why it happens

Issuer fraud models are blunt instruments. A subscription that bills from a new merchant descriptor, an amount that changed after an upgrade, or simple bad luck with a risk score can all trip the wire. The customer usually receives a "did you make this charge?" text from their bank, and the renewal hangs on whether they answer it.

What happens if you do nothing

Retrying into a fraud block is the one move that makes things worse: repeated attempts confirm the suspicion, can escalate to a hard block on the merchant, and may hurt your standing with that issuer. This play exists precisely because the default behavior, retry on schedule, is wrong here.

The play, step by step

Chaser, the Stripe-native failed-payment recovery tool, suppresses all automatic retries the moment the decline is classified as fraud-flavored. The customer gets one careful message explaining that their bank blocked the charge and asking them to confirm the payment with their bank or approve the merchant. Only after the customer signals the path is clear does a single retry run. High-value cases route straight to the attention queue, because a personal note from a founder resolves a fraud block faster than any template.

The email that works

Side with the customer against the inconvenience. "Your bank blocked this charge as a precaution. A quick confirmation with them clears it." Never use the word fraud in the subject line; the customer's bank already scared them once.