A Card Not Present transaction is an online or telephone payment where the physical card and chip reader are absent. A common example is a customer entering card details on a checkout page. Defenders should apply strong authentication, fraud checks, address and velocity controls, and monitor for repeated failed authorisations.
What a Card Not Present transaction looks like in practice
A card not present transaction happens when the customer pays without physically presenting the card to a reader. In practice, that usually means an ecommerce checkout, a phone order, or a saved-card purchase where the merchant only receives card details and related verification data, not the chip or magnetic stripe.
The simplest example is a shopper entering card number, expiry date, and security code on a checkout page. The same payment pattern appears in call centres, app-based ordering, recurring billing, and mail order environments. The key feature is that the merchant cannot rely on physical card presence, so the transaction depends more heavily on digital verification and fraud controls.
Because the card is not physically inspected, the merchant must treat the transaction as higher-friction from a risk perspective. Online and telephone payments often rely on address checks, card verification value checks, device and behavioural signals, and transaction monitoring to decide whether to approve, step up, or decline a payment.
Why this payment type needs stronger controls
Card Not Present payments are attractive to fraudsters because stolen card details can be used remotely, often before the cardholder notices. The merchant is usually asked to make an approval decision with incomplete evidence, so the control problem is not just payment acceptance, it is distinguishing a legitimate customer from a card tester or an account-takeover attempt.
That is why issuers and merchants often layer authentication and fraud screening around the payment step. Strong customer authentication, step-up checks, velocity limits, address validation, and repeated-failure monitoring help reduce abuse, while also creating more signal for investigating suspicious order patterns.
For merchants, the practical trade-off is familiar: the more friction you add, the more fraud you may block, but the more legitimate customers you may also inconvenience. The right balance depends on basket value, repeat-customer behaviour, dispute rates, and how much fraud loss the business can absorb versus how much checkout friction it can tolerate.
Where defenders should focus first
The first operational question is whether the checkout flow can distinguish ordinary customer behaviour from abuse at scale. That means looking for repeated failed authorisations, multiple cards used against the same account or device, unusual address mismatches, and short bursts of attempts that suggest testing rather than shopping. In practice, the best signals are usually a mix of payment data, device signals, and transaction history rather than a single check.
It also helps to separate risk controls by use case. A low-value digital subscription may need a different control threshold from a high-value one-off order or a first-time purchase shipped to a new address. If the same approval logic is used for every basket, merchants often end up either overblocking good customers or approving too much obvious abuse.
For a broader treatment of payment fraud patterns, Payment Fraud Guide covers card-not-present fraud, card testing, BIN attacks, chargebacks, and the controls that typically reduce loss in ecommerce and telephone channels.
Risk and Threat Considerations
Card Not Present transactions concentrate fraud risk because the merchant lacks the physical card and the in-person cues that help verify legitimacy. That makes stolen credentials, automated testing, and repeated authorisation attempts especially useful to attackers, and it also increases the chance that a weak checkout process becomes the easiest abuse path.
Failure mechanism: Fraud succeeds when the payment flow accepts remote card data without enough step-up verification, velocity control, or anomaly detection to distinguish legitimate purchases from stolen-card use or testing.
Impact: The usual outcomes are unauthorised purchases, chargebacks, operational overhead, and degraded approval performance if the merchant responds by tightening controls too bluntly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | CNP checkout depends on authenticating the payer or payment session correctly. |
| Recommendation — Harden payment authentication and challenge risky checkout attempts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | CNP flows rely on card and verification data that must be protected and managed securely. |
| AU-6 — Audit Review, Analysis, and Reporting | Transaction monitoring and repeated-failure review are central to detecting CNP abuse. | |
| Recommendation — Protect and manage payment authenticators and related secret data carefully. Review payment logs for repeated failures and suspicious authorization patterns. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Fraud controls depend on limiting abusive access paths to checkout and payment functions. |
| Recommendation — Restrict high-risk payment actions and review access to sensitive checkout functions. | ||
Practitioner Guidance
What to verify: Check whether your payment flow can flag repeated declines, shared fingerprints across many cards, mismatched address patterns, and unusually fast retry behaviour. Those signals matter more than a single authorisation result when you are trying to identify card testing or first-party misuse.
Decision rule: If the transaction pattern looks machine-driven or repeat-abuse driven, step up verification or block the attempt before approving more volume from the same source. If the pattern is isolated and the customer profile is familiar, avoid adding unnecessary friction that will only increase abandonment.
Practitioner takeaway: Card Not Present handling is really a fraud-scoring problem at checkout, so the best controls are the ones that reduce remote abuse without turning every honest customer into a manual review case.