Payment Fraud Guide: Card-Not-Present, 3DS and Chargebacks

Card-not-present payment fraud is paid for by the merchant twice: once in chargebacks and fees, and again in good orders declined or abandoned at an authentication challenge. Online merchants decide, transaction by transaction, how much evidence to collect, when to ask the issuer to authenticate the cardholder through EMV 3-D Secure, and when to accept the risk. This guide covers the mechanics behind those decisions: authorisation checks, 3-D Secure flows and liability, PSD2 strong customer authentication and its exemptions, card testing, chargebacks and friendly fraud, and the PCI DSS v4.0.1 requirements that matter for payment pages. It is written for payments, fraud and security teams at merchants, marketplaces and platforms. Programme design, rules engines and review operations are covered in a separate fraud prevention guide.

Key takeaways

• Authentication moves liability, not just risk. Under card scheme rules a successfully authenticated 3-D Secure transaction generally shifts fraud-related chargeback liability to the issuer; an unauthenticated one usually leaves it with the merchant.
• Use 3-D Secure selectively outside mandates. Send rich data so most transactions pass frictionless, and reserve challenges for risk, regulation or liability needs.
• In the EEA, SCA is law, with defined exemptions. Commission Delegated Regulation (EU) 2018/389 sets the rules, and the joint EBA and ECB report found SCA-verified payments "generally less susceptible to fraud".
• Card testing is a bot problem with payment consequences. Small authorisations, rising declines and approvals that never settle are the signals; velocity limits and bot defence are the fix.
• Not every chargeback is fraud, and not every fraud chargeback is a stranger. Friendly fraud, refund abuse and merchant errors need different evidence and different fixes.

How card-not-present fraud enters the payment flow

A card-not-present (CNP) payment passes checkout, optional 3-D Secure, issuer authorisation, settlement and, weeks later, a possible dispute. Each fraud type shows up at a different point.

Most stolen card data originates in breaches of systems that hold it. The AI Agent Retail Card Theft Campaign, where 600,000 cards were stolen using cloud keys, vault dumps and stolen admin access, shows why card data held by any merchant feeds other merchants' fraud.

Authorisation-time checks

None of these checks is decisive alone; their value is in combination with device, account and order signals.

Treat repeated CVV or AVS mismatches on the same card number as card testing, not customer typos, once they exceed two or three attempts.

EMV 3-D Secure: how it works

EMVCo describes EMV 3-D Secure (3DS) as a way for issuers and merchants to "prevent card-not-present (CNP) fraud". The merchant's 3DS Server sends an authentication request (AReq), carrying "details about the transaction, payment method and device information", through the card scheme's Directory Server to the issuer's Access Control Server (ACS). The ACS scores the risk and returns a result (ARes).

• Frictionless flow: the issuer authenticates on the data alone and the cardholder sees nothing. EMVCo's own words: consumers "simply click 'Buy'".
• Challenge flow: for higher-risk transactions, cardholders "must authenticate themselves using a challenge", for example a one-time passcode, biometrics in a banking app, or knowledge-based questions. Challenge messages (CReq and CRes) run between the cardholder's browser or app and the ACS, and the final result reaches the merchant in a results message (RReq).
• Channels: browser-based, app-based through a 3DS SDK, and 3DS Requestor Initiated (3RI) for authentication without the cardholder present, such as subsequent instalments.
• Versions: EMVCo has published specifications up to 2.3.1.1, with v2.4 in draft in 2026; for PSD2 SCA it says "v2.2 (or higher) should be considered". The original 3DS 1 protocol, with its full-page redirects and static passwords, is no longer the basis for current programmes.

The Electronic Commerce Indicator (ECI) passed into authorisation records the outcome: for Visa 05 means fully authenticated, 06 attempted and 07 non-3DS; for Mastercard the equivalents are 02, 01 and 00. Confirm the values your schemes use against your 3DS server or gateway documentation. Keep ECI and the authentication value with the order, because they are the evidence you need if a fraud dispute arrives.

Liability shift

Card scheme rules generally move liability for fraud-related disputes from merchant to issuer when a transaction was successfully authenticated with 3DS, and sometimes when authentication was attempted. The conditions differ by scheme, region, transaction type and programme and change over time, so confirm them with your acquirer. A liability shift covers fraud disputes only: it does not protect against "item not received", quality or processing disputes, and it does not stop friendly fraud claims framed as non-receipt.

PSD2 strong customer authentication and exemptions

In the EEA, payment service providers must apply strong customer authentication (SCA) to customer-initiated electronic payments. Regulation 2018/389, in force since 14 September 2019, requires "two or more elements which are categorised as knowledge, possession and inherence" (Article 4) and, for remote payments, dynamic linking of the authentication code to the amount and payee (Article 5). For card e-commerce, 3DS 2 is the usual mechanism. The 2025 joint EBA and ECB report found that "card payment fraud was 17 times higher when the payment recipient was outside the EEA", where SCA is not legally required and often not used.

The issuer always has the final word: it may challenge a transaction even when an exemption is requested, and a soft decline asking for SCA must be retried with 3DS rather than resubmitted. The TRA reference rates and their effect on approval rates are explained in the Fraud Prevention Guide for Digital Businesses. Mail and telephone orders are generally treated as outside SCA, and transactions where the issuer or acquirer is outside the EEA (one-leg-out) are handled on a best-efforts basis; confirm both with your acquirer.

Card testing and BIN attacks

PCI SSC and the National Cyber-Forensics and Training Alliance describe account testing as "a cybercriminal testing payment account numbers in order to validate cardholder information to perpetrate fraud". Attackers run bots and "CC checker" tools against checkouts, donation pages and card-update forms, often with charges of $1 to $5. Where a site does not check the security code, the bulletin notes the expiry date can be found in "effectively 60 attempts" across parallel sites. In a BIN attack, attackers generate candidate numbers from a known issuer prefix and use your site as the validator.

Indicators from the bulletin: card numbers from unissued BIN ranges; "an increase in the percent of declines for a merchant or BIN range"; the same card number tried with different expiry dates, codes or postcodes; sequential numbers; approved authorisations that never settle; sudden spikes at new or dormant merchant accounts.

• Rate limit by every key: card number, card fingerprint, account, device, IP, email and session, with lower limits on zero-value and card-update endpoints.
• Defend the endpoint, not just checkout: attackers target card-on-file updates, free trials and donation pages. See the Bot Management Guide.
• Add friction under attack: CAPTCHA or proof-of-work, mandatory 3DS, randomised delays and temporary blocks by BIN.
• Protect merchant credentials: the bulletin warns that attackers also use compromised merchant IDs to submit authorisations directly.
• Watch the scheme view: Visa's Acquirer Monitoring Program (VAMP), in effect since 1 April 2025, consolidates five fraud and dispute programmes and includes "enumeration criteria", so card testing on your account becomes your acquirer's problem and then yours.

Chargebacks, disputes and friendly fraud

A chargeback is the reversal of a card payment through the scheme's dispute process. Each scheme defines its own categories, time limits, evidence rules and fees; the outline below is generic.

1. Dispute raised: the cardholder contacts the issuer, which raises a dispute under a scheme category (broadly fraud, authorisation, processing errors, or consumer disputes such as not received or not as described).
2. Merchant notified: the acquirer debits the merchant and passes on the dispute with a response deadline.
3. Accept or represent: the merchant accepts the loss or submits evidence (representment) that the transaction was valid.
4. Issuer review: the issuer accepts the evidence or continues the dispute; unresolved cases may go to the scheme for arbitration, with fees for the losing side.

Evidence that wins: 3DS authentication result and ECI; AVS and CVV results; delivery confirmation to the billing or verified address; device, IP and login history linking the order to earlier undisputed orders by the same customer; usage logs for digital goods; customer communications and the refund policy shown at checkout. Collect it at order time, because reconstructing it a month later rarely works.

Friendly fraud and first-party misuse: many "not recognised" disputes come from unclear billing descriptors, family members using a saved card or forgotten subscriptions. Clear descriptors, receipts, easy cancellation and fast refunds prevent many of these. Deliberate first-party misuse needs a customer-level response: limit or remove stored cards and require stronger evidence for future orders.

Monitoring programmes: schemes monitor merchants and acquirers whose fraud or dispute ratios exceed thresholds, for example Visa's VAMP and Mastercard's Excessive Chargeback Program. Thresholds, fees and calculation rules change, so get the current figures from your acquirer and track the same ratio internally.

PCI DSS v4.0.1 where it matters for fraud

• Payment page scripts, Requirements 6.4.3 and 11.6.1: PCI SSC says these ensure payment page scripts are "properly authorized, checked for integrity", and cover management of scripts and "security-impacting HTTP headers". In practice that means an inventory of every script with a justification, and a change- and tamper-detection mechanism on the page as delivered to the browser. These requirements target e-skimming, the main source of fresh CNP card data.
• Embedded payment forms and SAQ A: merchants using a third-party hosted page or iframe can be eligible for SAQ A, but must confirm "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)", using techniques such as those in 6.4.3 and 11.6.1.
• No card verification code storage, 3.3.1.2: fraud teams sometimes ask to keep the CVV for retries or disputes. It is prohibited after authorisation.
• Tokenisation: store gateway or network tokens instead of card numbers. Network tokens are bound to a merchant and can survive card reissue, reducing both breach impact and declines on stored cards.

Decision guidance

• 3DS on everything or selectively: outside SCA mandates, applying 3DS to every order buys liability shift at the cost of abandonment on challenged transactions. Most merchants do better by sending rich data, using 3DS for risky or high-value orders and in markets with high frictionless rates, and keeping low-risk repeat customers frictionless.
• EEA merchants: design for SCA by default and request exemptions through your acquirer only where your fraud rate supports them, because an issuer can still challenge.
• Digital goods and subscriptions: highest friendly fraud exposure and instant fulfilment, so authenticate the first payment, mark later ones as merchant-initiated, and keep usage logs.
• Small merchants: use the payment provider's risk scoring, 3DS rules and hosted fields, set velocity limits, and get alerts on decline spikes. A dedicated fraud platform rarely pays before you have dispute data.
• Large merchants and marketplaces: run your own 3DS Server or orchestration across acquirers, build models on chargeback labels, automate representment, and manage seller-side fraud separately.

How to implement

1. Baseline: measure authorisation rate, fraud dispute rate by count and value, non-fraud dispute rate, 3DS frictionless and challenge rates, and abandonment for at least one full dispute cycle, by market and payment method.
2. Fix data and evidence: store 3DS results, ECI, AVS and CVV outcomes, device and account identifiers with every order.
3. Close card testing first: velocity limits and bot defence on checkout, card-update and donation endpoints, with alerts on decline spikes.
4. Tune 3DS in shadow mode: log what new 3DS and exemption rules would have done, then compare fraud and abandonment against current outcomes before switching.
5. Pilot: enable new rules on one market or a percentage split, with daily review of challenge rates, declines and complaints.
6. Roll out and roll back: version every rule and 3DS policy, keep the previous version deployable, and set rollback triggers such as approval rate or checkout conversion falling by an agreed margin.
7. Close the loop: feed dispute outcomes back as labels and review representment wins and losses monthly.

Detection and measurement

Log every payment attempt, not just successful orders, so card testing and soft declines are visible. Track together:

• Fraud dispute rate: fraud disputes divided by settled CNP transactions, by count and value, matched to the way your acquirer calculates monitoring ratios.
• Authorisation rate: approved over attempted, excluding detected card testing.
• 3DS frictionless rate and challenge success: share authenticated without challenge, and share of challenges completed.
• Card testing indicators: declines per minute, cards per device and authorisations that do not settle.
• Representment win rate: disputes reversed in your favour, by category.
• False decline rate: declined or abandoned orders later shown to be legitimate.

Where identity fits

Two identity problems sit inside payment fraud. Customer accounts with stored cards are targets for account takeover, so protect login, payment method changes and address changes with MFA or passkeys and step-up; see the Identity Fraud Prevention Guide. Payment gateway API keys and merchant credentials are non-human identities: a leaked secret key lets attackers run authorisations, refunds or card testing through your merchant account. Keep them in a secrets manager, restrict them by permission and IP where the gateway allows, and rotate them; see the API Key Management Guide.

Framework mapping

Common failure patterns

• Treating approval as proof: shipping on any issuer approval, without device, account or address signals.
• Unprotected zero-value endpoints: rate limits on checkout but none on card-update or free-trial flows, which card testers find within hours.
• Challenging everyone: blanket 3DS challenges on low-risk repeat customers, losing more in abandonment than in fraud.
• Assuming liability shift covers all disputes: friendly fraud reclassified as "not received" lands back with the merchant.
• Evidence not captured: no stored ECI, device or delivery data, so representment is lost by default.
• Weak payment page and key hygiene: unmanaged third-party scripts on checkout and gateway secret keys in code repositories, turning a merchant into a source of stolen cards or a card testing platform.

Practitioner checklist

• Map every payment endpoint, including card-update, trial and donation flows, and rate limit each.
• Store 3DS results, ECI, AVS and CVV outcomes and device data with every order.
• Use EMV 3DS v2.2 or later and send full device and transaction data to raise frictionless rates.
• Define when to request exemptions, flag merchant-initiated transactions correctly, and retry soft declines with 3DS.
• Alert on decline spikes, unsettled approvals and many cards per device.
• Inventory and monitor payment page scripts and headers under PCI DSS 6.4.3 and 11.6.1.
• Never store card verification codes; use tokens for stored cards.
• Track fraud and non-fraud dispute ratios the way your acquirer calculates them.
• Protect gateway API keys and customer payment method changes as high-risk identities.

Standards and references

• EMVCo: EMV 3-D Secure
• EUR-Lex: Commission Delegated Regulation (EU) 2018/389, RTS on strong customer authentication
• EBA: Single Rulebook Q&A 2018_4031, payee-initiated transactions and SCA
• PCI SSC and NCFTA: Account Testing Bulletin
• PCI SSC: Payment Page Security and Preventing E-Skimming
• PCI SSC: FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants
• ECB and EBA: Joint report on payment fraud
• Visa: Introducing the Visa Acquirer Monitoring Program

Related NHI Mgmt Group resources: Fraud Prevention Guide for Digital Businesses · Bot Management Guide · Device Intelligence and Fingerprinting Guide · Identity Fraud Prevention Guide · API Key Management Guide