Does `security_violation` mean my customer is doing something wrong?

Not necessarily. It usually reflects the issuing bank's own security systems reacting to something about the card or transaction, which can happen to a perfectly legitimate cardholder.

Should I retry the charge automatically?

No. An automatic retry on a bank-security block rarely succeeds and can reinforce whatever pattern triggered the block in the first place.

Can the customer fix this themselves?

Often yes, by contacting their bank directly, since the block originates from the bank's internal systems and the merchant has no way to clear it from the outside.

Is it safe to send the customer a normal "update your card" email?

Yes, this code doesn't carry the same account-fraud risk as a stolen or restricted card, so a straightforward request to verify or update the payment method is reasonable.

Why does Foxhound still classify this as fraud rather than a routine soft decline?

Because the code reflects a bank-side security block rather than a simple temporary failure, and Foxhound treats that as reason enough to pause automated retries and emails in favor of a more deliberate handling path.

Decline code

Security Violation

Stripe declined this payment because the issuing bank detected something it treats as a security problem with the transaction, the card, or the pattern surrounding it. Stripe's public label for the underlying reason is generic, but the practical meaning is a bank-side security block, not a balance or limit issue. Stripe's official definition for this code is: "the card was declined for an unknown reason." Banks don't share the specifics behind most of their internal decline reasons, and `security_violation` is one of the codes where the label itself gives more information than the official definition does. In practice, this code generally means the issuing bank believes it detected compromised card data, a fraudulent pattern, or some other security concern serious enough to block the charge outright, distinct from an everyday insufficient-funds or card-expired decline.

Back to decline codes

security_violationNever retried

Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

On a recurring billing product, `security_violation` can surface for reasons entirely outside your control: the card number appeared in a data breach the bank is now responding to, the bank's own fraud model flagged the transaction pattern, or the card was recently reissued and the old number is being blocked more broadly than usual. It is not typically a sign that the customer did anything wrong, and it is not usually a sign that your business did anything wrong either. It reflects the bank's internal security posture on that specific card.

How to fix it

Generally no. Because this reflects a security-driven block at the issuing bank rather than a temporary condition like insufficient funds, an immediate retry with the same card is unlikely to succeed and can look like exactly the kind of repeated-attempt pattern that security systems are tuned to catch. Avoid rapid automated retries on the same card. Since the underlying cause usually sits with the bank's security systems rather than the customer's account standing, a normal customer-facing email asking them to update or verify their payment method is appropriate here, this is not a case requiring the same fraud-account screening you'd apply to a stolen or restricted card. If the customer confirms the card should be fine, they may need to contact their bank directly to clear whatever triggered the block, since the merchant has no visibility into or control over the bank's internal security decision.

How Foxhound recovers it

Fraud and security declines are never retried, silently or otherwise. Foxhound sends a gentle, clearly worded email sequence across 30 days that names the situation plainly and points the customer to their card issuer, rather than repeating the same charge against a flag the issuer already raised.

Questions

Not necessarily. It usually reflects the issuing bank's own security systems reacting to something about the card or transaction, which can happen to a perfectly legitimate cardholder.
No. An automatic retry on a bank-security block rarely succeeds and can reinforce whatever pattern triggered the block in the first place.
Often yes, by contacting their bank directly, since the block originates from the bank's internal systems and the merchant has no way to clear it from the outside.
Yes, this code doesn't carry the same account-fraud risk as a stolen or restricted card, so a straightforward request to verify or update the payment method is reasonable.
Because the code reflects a bank-side security block rather than a simple temporary failure, and Foxhound treats that as reason enough to pause automated retries and emails in favor of a more deliberate handling path.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit