The short answer
Card-not-present (CNP) fraud is the use of stolen card details to pay where the physical card is not presented: online, by phone, by mail order or in an app. The merchant usually bears the loss through a chargeback, unless the payment was authenticated with 3-D Secure, which normally shifts fraud liability to the card issuer.
On this page
- What is card-not-present (CNP) fraud?
- What is a card-not-present transaction?
- How does card-not-present fraud happen?
- Who pays for CNP fraud?
- How do 3-D Secure and Strong Customer Authentication reduce CNP fraud?
- Does PCI DSS prevent CNP fraud?
- What is the difference between a chargeback and a breach?
- How can Sovereign Secure help?
Card-not-present (CNP) fraud is the use of stolen card details to pay without the physical card: on a website, over the phone, by mail order or inside an app. With no chip or PIN, the merchant relies on the details entered, plus any authentication the card issuer adds. UK Finance reports these losses as remote purchase fraud.
What is card-not-present (CNP) fraud?
It is any payment made with stolen card details where the card is not physically presented. Fraudsters need the card number, expiry date and usually the security code, sometimes with the cardholder’s name and billing address. Chip and PIN makes stolen card data hard to use in shops, so the details are worth most where no card is needed.
What is a card-not-present transaction?
A card-not-present transaction is any card payment where the card is not read by the merchant’s terminal at the time of payment, so the details are typed, spoken, written down or charged from storage instead. Card schemes and acquirers treat these payments as their own category, with their own fraud rules and chargeback risk. Common examples:
| Example | How the card details reach the merchant | Usual extra checks |
|---|---|---|
| Online checkout | The customer types them into a payment page, often one hosted by the payment provider | 3-D Secure, card security code, address verification |
| Phone order | The customer reads them to an agent, or keys them into an IVR with DTMF masking | Card security code and address verification; 3-D Secure does not apply |
| Mail order | The customer writes them on an order form | Address verification, and secure handling and destruction of the form |
| Stored-card subscription or one-click payment | Details or a token saved from an earlier purchase are charged again | The first payment is authenticated; later merchant-initiated payments fall outside SCA |
| In-app or digital wallet payment inside an app | A card saved in the app, or a tokenised card in a wallet such as Apple Pay or Google Pay | Fingerprint, face or passcode on the customer’s device |
The same wallet tapped on a shop terminal is a card-present transaction, because the terminal reads it directly. Card-present payments carry cryptographic proof from the chip or wallet that the genuine card or device was there; card-not-present payments rely on the details entered and whatever authentication the issuer adds.
How does card-not-present fraud happen?
| Pattern | How it works | Controls that help |
|---|---|---|
| Digital skimming | A malicious script on a checkout page, injected through a compromised third-party script or a flaw such as cross-site scripting, copies card details as the customer types | PCI DSS 6.4.3 and 11.6.1, or a provider-hosted payment page |
| Data breach | Card data is stolen from databases, logs, emails or call recordings | Not storing card data, tokenisation, never keeping the security code |
| Phishing | Cardholders type their details into a fake shop, delivery or bank page | 3-D Secure, so card details alone are not enough to pay; issuer fraud monitoring |
| Card testing | Bots run many small payments to find which stolen numbers, dates and codes work | Rate limits, bot detection and provider velocity rules |
| Account takeover | A criminal logs in to a customer account and uses its stored card | Strong customer login, alerts when delivery addresses or cards change |
| First-party (“friendly”) fraud | The genuine cardholder disputes a purchase they made; no stolen details, but it reaches you as the same kind of chargeback | Delivery evidence, clear billing descriptors, published refund terms |
Who pays for CNP fraud?
Usually the merchant. The cardholder reports the payment, the issuer refunds them and raises a chargeback through the card scheme, and the acquirer debits the merchant for the sale plus a chargeback fee.
The main exception is 3-D Secure: when a payment is authenticated, liability for fraud-related chargebacks generally shifts from the merchant to the issuer, subject to each card scheme’s rules.
How do 3-D Secure and Strong Customer Authentication reduce CNP fraud?
Strong Customer Authentication (SCA) requires two independent factors, from something the customer knows, has or is, for most online payments the customer initiates. In the UK the duty sits with payment service providers under regulation 100 of the Payment Services Regulations 2017, and the FCA’s enforcement date for e-commerce was 14 March 2022. For card payments, EMV 3-D Secure is how issuers apply SCA: the checkout passes the payment to the issuer, which approves it silently or challenges the cardholder, often in their banking app.
Some payments fall outside SCA or qualify for exemptions, such as mail and telephone orders, merchant-initiated payments like subscription renewals, and low-value or low-risk payments. Our PCI 3DS guide explains how 3-D Secure works and the separate PCI standard for companies running 3DS components. Sovereign Secure is a PCI SSC-listed 3DS Assessor for those companies, through our PCI 3DS assessments; merchants that simply use 3-D Secure do not need one.
Does PCI DSS prevent CNP fraud?
PCI DSS cannot stop a fraudster using card details stolen elsewhere at your checkout, but it stops your business being the source of those details. The PCI DSS v4.0.1 controls that matter most for online and phone merchants:
- 6.4.3 and 11.6.1: authorise and inventory every script on the payment page and detect unauthorised changes to it, both mandatory since 31 March 2025. SAQ A merchants instead confirm their site is not susceptible to script attacks, as our guide to payment page script rules explains.
- 6.4.2: an automated solution, such as a web application firewall, protecting public-facing web applications, also mandatory since 31 March 2025.
- 3.3.1.2: never keep the card security code after authorisation, including in call recordings and notes, a common gap when taking card payments over the phone.
- Tokenisation and outsourcing: tokenisation and provider-hosted payment pages keep card numbers out of your systems.
- 11.4: penetration testing where it applies, including web application testing of your checkout.
What is the difference between a chargeback and a breach?
| Aspect | Chargeback from CNP fraud | Card data breach |
|---|---|---|
| What happened | A fraudster used card details at your checkout | Card details were stolen from your systems |
| Typical cost | Sale value, goods and a chargeback fee | Forensic investigation, costs passed on by your acquirer, remediation |
| Who else is involved | Issuer, card scheme and acquirer | Acquirer, a PCI Forensic Investigator if required, and the ICO within 72 hours where people’s rights and freedoms are likely to be at risk |
| What prevents it | Fraud screening and 3-D Secure | PCI DSS controls and testing |
How can Sovereign Secure help?
Sovereign Secure is a PCI SSC-approved Qualified Security Assessor (QSA) company, also a Qualified PIN Assessor, Card Production Security Assessor, P2PE Assessor and 3DS Assessor, and a GEAR member for 2026 to 2028. We do not sell fraud screening or run 3-D Secure; your payment provider does. We help online and phone merchants make sure their checkout is not where card data leaks, through PCI DSS assessments, SAQ support and testing. For a quick view of your own position, take our free PCI compliance check.
See our overview for retail and e-commerce businesses, or ask for a PCI DSS quote.
Your next step
- PCI compliance checkAnswer 22 questions for a readiness score, your likely SAQ and a fix list.Start the free check
- PCI DSS document indexThe policies, procedures and records each PCI DSS requirement needs, as a free spreadsheet.Get the document index
- Get a PCI quoteTell us how you take card payments and we will confirm your validation route and scope.Get a PCI quote
Last reviewed October 2026 by the Sovereign Secure assessment team.




