Recovery Rate

15–30%

Hard Decline

Stripe Decline Code · Glossary

security_violation

Non-recoverable·15–30%·Updated May 2026

What It Means

What security_violation actually means.

security_violation is a hard decline fired when the issuing bank's internal security rules or fraud detection systems flag the transaction as a security risk and block it at the authorization layer — the bank detected signals that suggest the card, the transaction, or the cardholder's account may be compromised. Unlike fraudulent (Stripe Radar-driven) or stolen_card (network-flagged theft), security_violation is exclusively an issuer-side security decision — the bank's own risk engine made this call, and only the bank can resolve it.

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

1Bank risk engine triggered on transaction signals — The issuing bank's fraud model identified suspicious behavioral signals on this specific transaction — unusual merchant, atypical amount, mismatched geolocation, or device fingerprint anomalies that crossed their internal security threshold
2Card compromise indicators detected — The bank has detected patterns suggesting the card data may have been compromised — not necessarily confirmed stolen (which would return stolen_card), but enough suspicion to block the transaction as a precaution
3Incorrect card details entered — A known sub-cause: wrong CVV, expiry, or billing details entered at checkout can trigger security_violation at some issuers instead of incorrect_cvc — the bank interprets mismatched data as a security breach attempt rather than a simple entry error
4Card security controls activated by cardholder — Customer has set up bank-level security controls (spending caps, merchant category locks, location-based restrictions) that are firing against your transaction specifically
5Account-level security hold — The customer's bank has placed their account under a security review — all outgoing transactions are blocked pending identity verification or fraud investigation on the bank's side

What NOT to Do

Common mistakes that make it worse.

✕ Don't retry without customer bank contact first

security_violation must be treated as a hard decline unless the customer explicitly confirms their bank has cleared the security flag. Retrying without that confirmation hits the same bank security wall every time — burning retry attempts, degrading your merchant signal, and potentially worsening the bank's risk scoring on your merchant ID.

✕ Don't assume it's just a wrong CVC and ask for a simple card detail correction

While incorrect card details can surface as security_violation at some issuers, treating every occurrence as a data entry error misses the majority of cases. Sending a generic "please re-enter your CVC" email when the real issue is a bank security hold frustrates customers and delays the actual fix — which requires bank contact, not a form re-entry.

✕ Don't display "security violation" to the customer

The specific phrase "security violation" on your checkout or dunning email is alarming and technically meaningless to most customers — it suggests your platform has a security problem, not their bank. Always surface this as a generic payment decline and direct the customer to call their bank for details.

Retry Timing

Optimal retry schedule.

security_violation requires a bank-contact-first gate before any retry is attempted — identical in structure to do_not_honor but treated with slightly more severity.

Recovery Benchmark

What good looks like.

Metric	Result
Overall recovery rate	15–30%
Recovery when customer contacts bank	45–55% of those who take action
Recovery via alternate payment method	+12–18% additional lift
Recovery with blind retries (no bank contact)	~5–8%
Customer action rate on bank-contact email	~30–40% (lower than card update emails)
Recovery within 7 days	~20–25%

A 25–30% overall recovery rate on security_violation is the realistic ceiling, and it's driven almost entirely by how effectively your email sequence motivates customers to call their bank. The biggest conversion lever is email specificity — telling the customer exactly what to say to their bank (charge amount, date, merchant name) doubles action rates versus vague "contact your bank" messaging.

At Scale

How to handle it at scale.

Automated

✓Webhook trigger: invoice.payment_failed → check failure_code === 'security_violation' → route to bank-contact-required workflow — completely isolated from soft decline retry tracks
✓Zero immediate retries: Add security_violation to your conditional no-retry list — retry only after an explicit customer confirmation trigger (form submission, support ticket, email reply flag)
✓Email Day 0 — bank call script: The highest-performing email for this code includes a literal script for what the customer should say: "Please tell your bank: I'm trying to authorize a payment of [amount] to [your company name] made on [date]. Can you clear the security hold on my card?" — this dramatically increases bank-contact conversion
✓Retry gate mechanism: Build a simple webhook or form — "I've contacted my bank — please retry my payment" — that triggers a conditional retry only when the customer confirms bank clearance; this prevents wasted retries and gives customers agency in the recovery process
✓Alternate method offer — Day 5: If no resolution after bank contact prompt, present PayPal, UPI, bank transfer as primary alternatives — security_violation customers who didn't resolve via bank contact convert well on alternate methods because the desire to continue using your product is clear from their engagement
✓Generic error copy: Ensure your checkout and email templates map security_violation → neutral messaging like "Your bank declined this payment — please contact your bank for assistance" — never expose the raw code or phrase to customers

Manual Escalation

→High-ACV accounts: Personal outreach Day 2 if no customer action — a direct founder or CSM message with the bank-call script included performs 25–30% better than automated email for accounts over your MRR threshold
→New customer, first charge fails with security_violation: Cross-reference with other signals before outreach — if IP, email domain, or device signals look clean, treat as a genuine bank security flag and send the bank-contact email; if multiple risk signals cluster, route to manual fraud review first
→Repeat security_violation — same customer, multiple cycles: Direct conversation about permanent payment method switch — a card that returns security_violation across two or more billing cycles has a persistent bank-side security relationship with your merchant ID that is unlikely to resolve through retries or bank calls alone
→Cluster of security_violation failures from same BIN or country: Manual investigation — some regional issuers have systematic security rules that block entire merchant categories; if you see this pattern, it signals a need to add a local payment method or contact Stripe to adjust your merchant descriptor for affected regions

FAQs

Frequently asked questions.

What does the Stripe security_violation decline code mean?

security_violation means the customer's issuing bank blocked the transaction because its internal security rules or fraud detection system flagged it as a potential risk. It is an issuer-side hard decline — the bank detected suspicious signals on the transaction and refused it as a security precaution. Only the customer's bank can resolve the underlying flag.

What are the most common causes of a security_violation error in Stripe?

Common causes include the bank's risk engine detecting unusual transaction signals, card compromise indicators triggering a precautionary block, incorrect card details being interpreted as a security breach attempt, customer-activated card security controls, and account-level security holds placed by the bank pending identity verification or fraud investigation.

Should I retry a payment after a Stripe security_violation decline?

Not without customer bank contact first. Treat security_violation as a hard decline and gate all retries behind a customer confirmation that their bank has cleared the security flag. Limit retries to a maximum of 2 attempts total. Blind retries without bank clearance produce only 5–8% recovery and risk worsening your merchant risk signal.

What should I tell my customer when Stripe shows security_violation?

Ask them to call their bank and specifically say: 'I'm trying to authorize a payment of [amount] to [company name] made on [date] — please clear the security hold on my card.' Providing this exact script in your email doubles customer action rates versus vague contact-your-bank messaging. Never display the term security_violation to the customer — always use neutral decline language.

What is the recovery rate for Stripe security_violation failures?

Overall recovery rates for security_violation are 15–30%. Among customers who contact their bank, 45–55% recover successfully. Adding an alternate payment method offer on Day 5 adds 12–18% additional recovery lift. Blind retries without bank contact recover only 5–8%.

What to do next

You are here

security_violation

Decline code reference

↓→

Check recoverability

Stripe Failure Lookup

See what's recoverable — and what isn't →

↓→

Then

Automate recovery for every decline code →

Before you retry

Most security_violation failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.

See what security_violation costs me →

Stop leaving revenue on the table

security_violation can't be retried — but it can be caught earlier.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.

See what's leaking →All 30 decline codes →