Why card-present vs card-not-present needs a modern rethink

• Card-present vs card-not-present still matters for pricing, fraud, liability and routing, but it tells us less about the real risk behind a transaction as payment journeys become more complex.

• Two transactions can both be classed as CNP while carrying very different signals of trust, from device identity and tokenization to biometric authentication and customer context.

• A more useful way to assess modern payments is to look at factors like customer presence, credential presentation, device trust and authority together, rather than relying on CP/CNP alone.

• Payment orchestration can help PSPs, ISVs and merchants use more of that context when deciding how a transaction should be handled, giving them more control as payment journeys spread across apps, devices and software.

Don't have time to read more now? Sign up to our newsletter to get the latest insights directly in your inbox. 

A customer walks into a store, picks up the item they came for, opens the retailer's own app and pays with their fingerprint without ever joining the queue. There’s no card to insert or tap, and no payment terminal involved: the customer is right there in the store - paying through infrastructure the merchant built specifically for this moment.

By the old rules, that's a card-not-present transaction. The customer would tell you a different story. 

And as more journeys start to look like this, the old way of thinking about payments starts to look increasingly out of step with how people actually pay today. 

That’s what we’re exploring in this article: looking at how payment methods are changing, where card-present vs card-not-present starts to fall short and what this means for managing risk.

A card-present (CP) transaction is one where the card's data is captured electronically at the point of sale, usually by inserting, tapping or swiping the card. Card-not-present (CNP) covers transactions where the card details aren’t read directly by a terminal - from online checkouts and phone orders to manually entered card details and saved credentials being charged later.

For decades, that classification helped determine how a transaction was priced, how much fraud risk a processor took on, and who pays when something goes wrong. We've covered how the two compare in more detail in Card-present vs. card-not-present transactions: What's the real difference?

For years, CP/CNP worked because the underlying journeys genuinely behaved differently, but modern payments don’t fit into those same neat categories anymore.

Today's payments move through apps, wallets, wearables, cars, self-service kiosks, and all manner of software capable of making payments for a customer - so whether a card is physically there doesn’t tell you nearly as much about the risk as it once did. 

The problem is that the industry still relies on that distinction to make some very real decisions about how a transaction is treated. CP/CNP is still built into pricing, liability rules and fraud checks across the industry, and it’s not going anywhere just yet. 

That isn't an argument against card-present, which is still one of the most secure and cost-effective ways to take a payment for a lot of businesses. The issue is that a label built to describe how a card was read has ended up being used to judge something else entirely: how confident you are that the right person is making the payment.

Follow a purchase through a few common payment experiences and the line between card-present and card-not-present starts to get harder to follow: 

• Click-and-collect: The order is placed remotely, but the customer turns up in person to collect it, sometimes finishing the payment there and then. The journey has crossed channels, but the payment still needs to fit into one category.

• In-store app purchases: The customer is inside the merchant’s own environment, using its own infrastructure, but the transaction is still classed as CNP because no card was captured at a terminal.

• Self-service kiosks: The customer is using merchant-owned hardware, but pays by scanning a QR code through an app or stored credential rather than presenting a card. Unattended terminals bring their own security rules, because nobody's watching.

• Connected cars: A driver authenticates through their car at a charging station, with the final amount only known once charging is complete. The payment is approved against an estimated amount and adjusted afterwards, with the car handling the credential - no checkout moment at all.

• Wearables: A wearable can authenticate the customer while a stored or tokenized credential handles the payment in the background, creating even more distance between the customer and the physical card.

By this point, asking whether the card was present misses most of what actually happened during the payment.

The same issue comes up with payments that are classed as card-present. SoftPOS lets merchants accept contactless payments using a regular phone or tablet, without a dedicated payment terminal. The customer taps their card against the device, and the transaction is classed as card-present.

So a shop assistant accepting a tap on a phone counts as card-present, while a customer standing in the same store and paying through the retailer’s own app is classed as CNP.

Both of those can be reasonable calls once you look at how the payment was actually taken, but it also shows how little the label tells you on its own about what happened at the point of sale. 

It gets even harder to draw the line once the shopping experience itself starts moving between physical and digital.

A customer might be standing in a store, using smart glasses to see stock and sizing information overlaid on the products in front of them, before paying with a tokenized credential on their phone and approving it with a fingerprint. They’re in the merchant’s store, using a known device, with biometric authentication and purchase history behind the transaction - and it’s still card-not-present.

From the customer’s point of view, they’re still shopping in person, but the payment system may see something very different. It can work the other way too: a customer might be shopping through a virtual environment, interacting with a digital version of a merchant while the payment is still being handled by a device or credential in the physical world.

We’ve explored what this could mean for payments before in our article on Payments in the Upside Down, where we looked at what happens when buying journeys no longer sit neatly in either the physical or digital world.

For card-present/card-not-present payments, that creates an awkward question: if the customer is physically present, the interaction is digital and the credential never reaches a traditional terminal, what exactly are we calling “present”?

Take two transactions that are both classed as CNP. 

In one, a customer types their card number into an unfamiliar checkout page, with no previous history and no way to link the payment to a known device. In the other, a customer is standing at a self-service kiosk on the merchant's premises, scanning a QR code to pay from a tokenized credential on their own phone, approved with a biometric.

On paper, both can be CNP. In practice, they give the payment system very different reasons to trust them. One gives the merchant very little to work with; the other comes with merchant-owned hardware, a known device, a tokenized credential, biometric authentication and a customer who is physically there. 

They might both be classed as CNP, but one carries far stronger signs that the payment is genuine. The CNP label doesn’t capture that difference.

CP/CNP still tells us something about how the transaction happened, but far less about how trustworthy it is. That depends on a much wider set of signals than card presence alone.

If physical card presence is no longer enough to judge risk, what else should we be looking at? The answer is a combination of signals that each tell the merchant something different about the payment and the person, device or software behind it:

• Biometrics: helps confirm that the person approving the payment is the legitimate user.

• Device identity: shows whether the payment is coming from a device already linked to the customer or account.

• Tokenization: replaces the card number with a token, protecting the credential while giving the payment system a consistent way to recognize it. It doesn’t confirm who’s paying or link the same customer across in-store and online - that requires a separate reference.

• Network tokens: issued by card schemes rather than individual providers, so they can remain valid when a card is reissued and follow the customer across channels and providers. They help simplify credential lifecycle management and support stronger payment decisions, but they don’t identify who is actually making the payment.

• Context: location, transaction history and whether the purchase fits an established pattern can show whether the payment looks expected.

• Delegated authority: becomes important when a car, wearable or AI agent is making a payment on someone’s behalf, helping establish that it’s authorized by the customer.

No single signal is enough on its own, but put them together and the merchant has a much stronger basis for assessing whether a payment is genuine than a CP/CNP classification.

A payment also doesn’t need every signal to be strong: a weaker signal in one area can be backed up by stronger signals elsewhere, giving the merchant a more complete view of the risk. The trouble is that the economics behind the payment haven’t necessarily caught up with all that extra information.

Interchange, fraud assumptions, liability rules and routing decisions still use CP/CNP as a way to classify payments. So a CNP transaction with strong biometric authentication and a tokenized credential can end up with similar cost and risk treatment as someone manually typing a card number into an unfamiliar checkout.

The industry has built ways to account for this, with 3D Secure changing who carries the liability based on how the payer is authenticated and SCA exemptions reducing the checks required when a transaction is considered low risk. But these sit on top of CP/CNP, leaving the underlying classification in place when it comes to pricing and handling the payment.

Pricing isn't the only thing at stake either - the same context that affects how a transaction is priced can also affect whether it gets approved. When issuers have limited information, legitimate payments can look riskier than they are.

Richer signals give them more to work with: network tokens are already associated with higher approval rates than raw card numbers, and authentication data passed with the transaction gives the issuer a reason to say yes rather than a reason to hesitate. For PSPs, ISVs and merchants, better-informed decisions at authorization mean fewer legitimate payments being declined - and less revenue lost as a result.

The mismatch becomes harder to ignore as payment journeys become harder to fit into either category. CP/CNP still provides useful context about how a payment was made, but less than it used to. The answer is to add more detail around the classification, rather than move away from CP/CNP altogether.

A more detailed approach could start by looking at the different parts of a payment separately, rather than trying to capture the whole transaction with one CP/CNP label.

The idea is to look at all these factors together, rather than using CP/CNP as the only measure of risk. That gives a clearer picture of the payment and a better basis for deciding how it should be priced and who should carry the risk if something goes wrong.

Better payment signals only help when the infrastructure behind the payment can actually use them. That’s where payment orchestration comes in.

Aevi’s payment orchestration platform connects payment devices, payment providers and value-added services through a single orchestration layer, helping PSPs, ISVs and merchants make better use of information that would otherwise sit across different parts of the payment ecosystem.

Where that matters most depends on the business. PSPs get a way to distinguish between transactions when the signals behind them are different, rather than pricing and routing them the same way because they share a label. ISVs can build payment journeys that don't fit neatly into the old categories without the classification working against them, and merchants see fewer legitimate customers declined and a clearer view of where risk actually sits across their channels.

The value isn’t in collecting more data - it’s in making the information already there more useful.

Payment journeys are getting harder to classify as more devices and software become part of how people buy. The payment infrastructure underneath them needs to keep up, giving businesses the flexibility to support new ways to pay while still keeping control over how each transaction is handled.

If your payment setup needs to support more complex buying journeys, get in touch with Aevi to see how payment orchestration can help.