For most payment teams, the card-present vs card-not-present transactions distinction gets filed under processing operations. It determines routing, compliance checklists, and interchange rate categories. But this framing is becoming a liability.
The CP vs CNP divide now touches fraud exposure, cost structure, cardholder experience, and the quality and consistency of transaction data. As e-commerce volumes rise, and subscription payments become a standard part of household spending, more and more of a bank's card portfolio is migrating from card-present to card-not-present rails. Although both have its specific place, without a coherent strategy, banks end up with a fragmented data layer that undermines every product built on top of it.
This article breaks down what CP and CNP transactions actually are, how they differ in risk and cost, and what banks need to know while building consistent product experiences.
Why this decision matters
Card-present and card-not-present transactions have always coexisted, but the balance between them is shifting rapidly. Global e-commerce continues to grow at roughly 10% annually, and the virtual card market - overwhelmingly CNP by nature - is expanding at a compound annual growth rate of over 18%, with transaction values projected to surpass $6 trillion in 2026 alone. Digital wallets now account for 53% of global e-commerce spend, and by 2024, most banks had adopted virtual cards in some form.
This matters for banks because each transaction type - whether card-present or card-not-present - comes with its own data profile, and neither is inherently clean or reliable. A cardholder tapping their card at a coffee shop may generate a terminal-sourced merchant record, but that record is only as accurate as however the merchant configured their POS. The same cardholder paying for a streaming subscription or booking a flight generates a transaction that may arrive masked or routed through a payment gateway - but with the right enrichment layer, the actual merchant identity can be resolved just as clearly.
The distinction doesn't determine which channel is better. It determines what raw data you get from each. Now let's differentiate them properly.
Card-present transactions
A card-present (CP) transaction happens when both the physical card and the cardholder are at the point of sale - chip inserted, card tapped, or stripe swiped at a terminal. The terminal captures and encrypts the card data, the acquirer routes it through the card network to the issuing bank, and an approval or decline comes back in milliseconds.
Benefits for banks: Lower fraud risk (~0.06% of transaction value), lower interchange fees, and cleaner liability - EMV chip technology has neutralised a large share of counterfeit fraud in physical environments, and issuers generally absorb losses only when authentication conditions are met.
Limitations: CP requires physical infrastructure and is by definition limited to in-person interactions. It doesn't serve the growing share of commerce happening online, across borders, or on subscription.
The data catch: Terminal data sounds reliable until you consider who configured the terminal. Merchants set up their own POS devices, which means merchant names, addresses, and MCC codes are only as accurate as that setup. MCCs in particular are frequently misaligned, since merchants have an incentive to select codes that attract lower interchange rates. The same brand across multiple locations may appear under different names, different codes, or different address formats — a persistent source of noise for any bank trying to build consistent merchant identity.
Card-not-present transactions
A card-not-present (CNP) transaction happens without the physical card at the point of sale - e-commerce checkouts, in-app purchases, phone orders, and recurring subscription billing all fall here. CNP is the dominant model for digital commerce and is growing rapidly.
Benefits for banks: CNP enables online and global commerce at scale, supports subscription and recurring billing without requiring customer action at each cycle, and carries no hardware dependency.
The fraud and cost reality: The CNP fraud rate sits at ~0.93% of transaction value - roughly fifteen times higher than CP. On $5 million in annual card volume, that's nearly $43,000 in additional fraud exposure from online channels alone. Higher risk means higher processing costs, mandatory authentication layers (3DS, AVS, CVV), and larger chargeback management budgets.
The data catch: CNP transactions are routed through payment gateways - Stripe, Adyen, PayPal, Square, and many others - each with their own descriptor formats and aggregation patterns. A merchant's name may be masked behind a gateway string or bundled under a payment facilitator identity. The result? Merchant identity in CNP is often inconsistent across transactions with the same business, even when nothing fraudulent has occurred.
What a CP and CNP transaction actually look like
To understand why this matters in practice, consider the same hypothetical merchant appearing across both transaction types.
A cardholder visits a coffee chain in person and pays by tapping their card. The transaction record shows: COSTA COFFEE #4821, MCC 5814 (Eating Places, Restaurants), GBP 4.50. The merchant name comes from the terminal. It is recognisable, correctly categorised (assuming the MCC was set accurately), and tied to a specific location.
The same cardholder buys a bag of coffee beans from the same brand's e-commerce store. The transaction record shows: STRIPE*COSTACOFFEE, MCC 5999 (Miscellaneous Retail), GBP 18.00. The gateway name appears first. The MCC is a catch-all retail code. The merchant name is a string that may or may not be recognised by the bank's categorisation engine - and almost certainly won't be recognised by the cardholder scrolling through their statement.
The most common comparison focuses on the obvious dimensions: physical versus remote, lower versus higher fraud risk, lower versus higher cost. These are accurate and important, but they miss the dimension that most directly affects what banks can build.
Transaction origin and data structure is where CP and CNP diverge most consequentially. What banks increasingly need is a framework that handles both data structures reliably - not just a fraud and compliance posture for each, but a consistent data product that treats CP and CNP as two inputs into a single, coherent transaction layer.
Where this connects to transaction data enrichment
Card-present data is not fully reliable: terminal misconfigurations, strategic MCC selection, and inconsistent merchant naming across locations mean that even in-store transactions arrive with noise that needs to be cleaned. Card-not-present data is often actively misleading: gateway masking, descriptor variability, and aggregated merchant identities mean that the raw transaction string frequently doesn't reflect the merchant the cardholder actually engaged with.
Want to know more? Read about going beyond MCC with accurate categorisation.
When a bank's systems process both types of data without enrichment, the result is a fragmented transaction feed where the same merchant may appear under five different names across CP and CNP transactions, making it impossible to build a unified spending view. Categorisation becomes unreliable. Subscription detection fails because recurring CNP charges from billing platforms don't carry consistent merchant identifiers across billing cycles. Â
Regulatory pressure is now formalising this. Mastercard's AN4569 mandate, in effect since October 2023, requires European issuers to provide enriched merchant data - including the merchant's public-facing name, location, contact details, and logo - to cardholders on request via digital banking interfaces. Visa is following with its own enhanced merchant data mandate, requiring issuers across Europe to display enriched merchant information by January 2027. Both initiatives explicitly recognise that raw transaction data, across both CP and CNP, is not sufficient for cardholders to reliably identify their purchases.
This is the environment banks are now operating in: regulatory requirements for data quality, cardholder expectations for transparency, and a transaction mix increasingly weighted toward the channel (CNP) where data quality is hardest to achieve.
How Tapix helps
Tapix addresses the CP/CNP data problem at its root: by standardising transaction data across both channels into a single, consistent merchant identity layer, regardless of how the underlying transaction was processed or what data came attached to it.
For card-present transactions, this means resolving the terminal configuration noise - mapping inconsistent merchant names across locations, correcting misapplied MCC codes, and building a stable merchant identity that holds across a cardholder's transaction history even when the same brand appears differently across terminals.
For card-not-present transactions, this means cutting through gateway masking and descriptor variability - identifying the actual merchant behind a Stripe or Adyen description, resolving aggregated marketplace transactions to their underlying vendors, and detecting recurring billing patterns even when the descriptor changes between cycles.
This matters for banks at every layer of the product stack. A consistent transaction feed is the foundation for reliable PFM tools. Clean merchant identity improves fraud model signal quality. Cross-channel analytics become meaningful when CP and CNP data share the same merchant taxonomy. And the cardholder experience improves when statements are legible - reducing the disputes and support calls that inconsistent transaction data reliably generates.
