Skip to content

Decline code 34: Suspected Fraud

Sean WeasBy Sean Weas · Co-Founder, Product & EngineeringReviewed by Travis SteffenUpdated 3 min read
Summarize with AI

Quick answer

Decline code 34 — “Suspected Fraud” — is a hard decline returned by the cardholder’s issuing bank under the ISO 8583 standard: the issuer believes the transaction may be fraudulent and is refusing it for the card’s protection. A blind retry won’t clear it. Stripe surfaces the same issuer decision as the fraudulent decline_code, and Authorize.net returns it through its fraud-filter reason codes. Recovery needs customer verification, not re-attempts.

What code 34 means

Hard declineDo not retry

Do not retry a 34 — the issuer has flagged the transaction as suspected fraud, and re-running the same charge confirms the pattern and can get the card frozen. Recover it with customer outreach so the cardholder can verify the charge or supply a different card; never blind-retry.

Cross-processor equivalents

The same issuer decision surfaces under a different code on every processor. Here is how code 34 maps across the stacks Revatto recovers on.

ISO 8583
Code34
CalledSuspected Fraud
Stripe
Codefraudulent
CalledFraudulent
Braintree
Code2014
CalledFraud Suspected
Authorize.net
Code66
CalledFailed gateway securityresponseReasonCode 66; AFDS filters 250–254
NMI
Code252
CalledStolen card
Chargebee
Codefraudulent
CalledFraudulent
Recurly
Codefraudulent
CalledFraudulent
IxoPay
Code2010
CalledSuspected fraudadapterCode 34 also maps here
Shopify
CodeFRAUD
CalledFraud
Whop
Codefraud_decline
CalledSecurity declinenormalized — no processor-specific code (free-text categorized)
Fanbasis
Codefraud_decline
CalledSecurity declinenormalized — matched by substring rule, no processor-specific code

Why it happens

  • The issuer’s fraud-detection model scored the transaction as high-risk (unusual amount, velocity, geography, or merchant category).
  • A genuine fraud alert on the card — the cardholder reported, or the bank detected, suspicious activity and locked further charges.
  • Card-not-present or recurring-billing patterns the issuer treats as elevated risk for that account.
  • Mismatched verification data (AVS/CVV) or a billing detail that diverged from the issuer’s record, tipping the risk score.
  • A new or recently reissued card the issuer is monitoring more aggressively until the cardholder establishes a usage pattern.

How to recover it

  1. 1Don’t re-run the same charge — repeated attempts after a 34 reinforce the issuer’s fraud signal and can get the card frozen entirely.
  2. 2Reach the customer on a channel they actually answer — email and SMS — explain the bank flagged the charge for security, and ask them to confirm it with their issuer or unlock the card.
  3. 3Offer an easy path to supply a different card or payment method, since the flagged card may stay blocked until the cardholder resolves it with their bank.
  4. 4
    When it persists, a real person — not another automated email — works the verification and card update directly. That AI-plus-human handoff is exactly what Revatto does for you: AI-timed retries where the processor API supports it, plus email, SMS, and human outreach, fully done-for-you. You only pay if it works — 20% of the first recovered payment, $0 setup, $0 monthly, cancel anytime.See how Revatto recovers 34declines →

See what Revatto would recover for you

Failed payments recovered automatically — no engineering, no manual chasing. We do the work; you keep the revenue.

See Your Recovery Potential

Frequently asked questions