Card-not-present payment is a transaction where the cardholder does not physically present the card to the merchant. The merchant relies on entered card data and additional checks such as CVV, billing address, device signals, or authentication steps. Fraud controls should watch for stolen credentials, bot abuse, and unusual transaction patterns.
How card-not-present payments move from checkout to authorisation
The core difference is that the merchant cannot inspect the card physically, so trust shifts to data quality, fraud signals, and issuer approval. The customer enters card number, expiry, and related verification data into a checkout form or app, then the merchant sends an authorisation request through the payment processor and card network to the issuer.
Because the card is absent, the merchant has to build confidence from the surrounding context. That usually means comparing billing and shipping details, checking device reputation, looking for velocity patterns, and deciding whether to step up authentication before the transaction is allowed to proceed.
What checks are doing the real work in card-not-present transactions?
AVS, CVV, device fingerprinting, and transaction-history rules do different jobs. CVV helps prove the buyer has the card details in hand, billing-address checks can catch mismatches, and device and behavioural signals help distinguish a normal customer from scripted card testing or a stolen-card attempt.
None of those checks is perfect on its own. Good card-not-present control depends on combining them, then tuning them to the merchant’s fraud profile, false-decline tolerance, and customer experience. A low-risk digital goods seller may use a different threshold from a travel merchant or subscription business.
Authentication can also move the transaction into a stronger assurance path, such as step-up verification for higher-risk orders. In practice, the merchant is not proving the card is physically present; it is proving the transaction looks consistent enough to trust.
Why card-not-present payments create different fraud and operational risks
Without chip-and-pin or swipe presence, the transaction is easier to automate, replay, and test at scale. That makes stolen credentials, bot-driven card testing, account takeover, refund abuse, and friendly-fraud disputes more likely than in card-present environments.
Controls therefore need to look for pattern-based abuse, not only single suspicious payments. The practical risk is that a merchant can accept many small fraudulent authorisations before the loss becomes obvious, especially if the attacker is using valid card data and rotating across many identities, devices, or payment attempts.
Failure mechanism: Attackers exploit the fact that the merchant must trust remote-entered card data and contextual signals, so they can probe weak checks, automate trial transactions, or blend fraudulent orders into normal traffic.
Impact: Merchants face chargebacks, lost inventory or services, higher processing fees, false declines, and a degraded approval rate if controls become too aggressive.
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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-6 — Access Control Management | CNP fraud relies on weak checkout and account access control. |
| Recommendation — Restrict checkout, refund, and admin access to reduce abuse paths. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Remote payment flows depend on strong customer and session authentication. |
| Recommendation — Harden authentication and step-up checks around payment submission. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Fraud detection depends on logging payment attempts and anomaly signals. |
| IA-2 — Identification and Authentication (Organizational Users) | Merchant-side admin and support access can affect payment fraud controls. | |
| SI-4 — System Monitoring | Monitoring is central to spotting card testing and abnormal transaction patterns. | |
| Recommendation — Log payment attempts, retries, and fraud signals for detection and review. Authenticate staff who can change fraud rules or approve exceptions. Monitor transaction patterns for automated abuse and credential misuse. | ||
Practitioner Guidance
What to verify: Treat card-not-present controls as a layered decision, not a single gate. Verify that your fraud stack correlates CVV, address checks, device reputation, velocity limits, and issuer authentication signals before you trust a high-value approval.
What practitioners underestimate: The hard part is usually tuning, not activation. If the rules are too loose, card testing and stolen credentials slip through; if they are too strict, legitimate customers get blocked and manual review volume rises.
Decision rule: Escalate transactions with repeated attempts, mismatched signals, or unusual purchase timing before they become a chargeback problem. For higher-risk flows, use step-up authentication and review the approval path for patterns that suggest scripted abuse rather than one-off customer error.
Practitioner takeaway: Card-not-present security works best when you assume the card data may be real but the buyer may not be, and you tune controls to catch abuse patterns without breaking legitimate checkout.
Related resources from NHI Mgmt Group
- Guide: Payment Fraud Guide
- Why does tokenization reduce risk for merchants, processors, and issuers in card-not-present payment flows?
- How should payment networks and issuers reduce card-present fraud without pushing more losses into card-not-present channels?
- How does Payment Card Industry Data Security Standard work?
- Why do email-based vendor payment scams still work in mature organisations?