Card-present (CP) and card-not-present (CNP) payments run on the same card networks, but they behave like two different products once you look at pricing, fraud liability, and compliance scope. In general, CP transactions cost less and have lower fraud risk because the payment includes stronger, in-person verification signals, while CNP transactions carry higher interchange and a higher probability of disputes.
If you are building or reviewing a payments setup, the practical takeaway is simple: treat CP and CNP as separate risk lanes. Your processor setup, fraud tooling, PCI paperwork, and even how you read your statement will differ based on which lane dominates your volume.
In this guide, I will break down the real differences between CP and CNP processing, how they impact your effective rate, and what to do if you sell in both channels.
Card-present transactions happen when the cardholder and a physical payment device are at the point of sale, and the payment is captured using an in-person method like EMV chip dip, contactless tap, or swipe. Card-not-present transactions happen when the merchant cannot capture the card's chip in person, such as e-commerce checkout, phone orders, or recurring billing.
The networks and banks treat these differently because the data available at authorization is different. In CP, the terminal can provide EMV and contactless security data and confirm the card is physically present. In CNP, the merchant typically relies on data like AVS, CVV, device signals, and sometimes 3D Secure to prove the buyer is legitimate.
CNP transactions usually cost more because they are riskier for issuers and acquirers, and that risk is priced into interchange categories and program fees. In plain terms, online fraud and friendly fraud are more common than counterfeit card fraud at a chip-enabled checkout lane.
This does not mean you are stuck with expensive pricing forever. It means you need to understand what drives your effective rate and pick a pricing model and processor that can handle your risk profile without padding margins.
If you sell mostly online, do not compare your effective rate to a retail store down the street. Compare it to online merchants with similar ticket size, refund behavior, and fraud exposure.
A simple diagnostic is:
Your processing costs are a stack. Some parts change a lot between CP and CNP, while others stay roughly the same.
Here is the stack most merchants see:
1. Interchange (paid to the cardholder's bank)
2. Network assessments and dues (paid to Visa, Mastercard, etc.)
3. Acquirer and processor markup (what your provider earns)
4. Gateway and software fees (often tied to e-commerce)
5. Risk and chargeback-related fees (often higher for CNP)
The main CP vs CNP swing usually shows up in interchange categories and in the add-on stack that online businesses need to operate.
| Cost component | Card-present (CP) | Card-not-present (CNP) | What to watch |
|---|---|---|---|
| Interchange category | Often lower when processed as EMV chip or contactless | Often higher because the transaction is higher risk | Your statement might label these as retail vs e-commerce categories |
| Gateway fee | Sometimes included or not needed | Common (monthly gateway, per-transaction gateway fee) | Ask if the gateway markup is separate from processing |
| Fraud tooling | Basic filters may be enough | Often required (device fingerprinting, velocity rules, 3DS) | Fraud tools can save chargebacks but also increase decline rates |
| Chargeback ratio pressure | Often lower if EMV is working correctly | Often higher due to fraud and subscription disputes | A high ratio can trigger network monitoring programs |
| Terminal and hardware | You buy or rent terminals | Not applicable (mostly) | Watch long terminal leases |
| PCI scope and validation | Can be smaller with P2PE or well-segmented POS | Often larger if your site touches payment page code | Hosted checkout can reduce scope |
A transaction is usually treated as CP when it is captured through an in-person acceptance method and includes the right security indicators, such as EMV chip data or contactless data, along with terminal capabilities. Practically, this means:
If you run a CP business, your biggest operational goal is to keep chip and tap working and to minimize fallback to swipe.
For CP sales, EMV changes who eats counterfeit fraud when the right technology is not used. If a chip card is present but the merchant processes it through a weaker method like swipe, some fraud losses can shift to the merchant instead of the issuer.
In practice:
This is one reason terminal selection and POS configuration matters. In CP, your hardware and how it is configured can be the difference between a manageable chargeback rate and an expensive problem.
For CNP sales, the merchant typically carries more fraud liability because the issuer cannot confirm the card was physically present. If you accept an online transaction that later becomes a fraud dispute, the default outcome often favors the cardholder unless you can show strong evidence.
The best way to improve liability position in CNP is to reduce fraud in the first place and use authentication methods that shift or share liability when available.
Common CNP liability tools include:
If you run subscriptions, you should also understand the card network stored credential rules and how they impact disputes. We covered that in our stored credential framework guide: https://merchantalternatives.com/stored-credential-framework-mit-cit-subscription-billing-guide/
All of these are CNP, but they behave differently:
If your provider treats all CNP volume the same, you may end up with pricing that is too expensive for your best traffic and too permissive for your riskiest traffic. A better setup uses different fraud rules and sometimes different MID routing based on channel.
You can be a retail merchant and still get priced like CNP when the transaction is processed in a way that looks like it has no reliable in-person verification. Common examples:
If you see a lot of "keyed" or "manual" transactions, treat it as a cost leak. It often correlates with higher interchange, higher fraud, and higher chargeback pressure.
The short answer: PCI scope follows how card data touches your systems, not whether the buyer is physically present.
But CP and CNP merchants tend to land in different PCI validation categories because the technology stack is different.
Typical patterns:
If you have an e-commerce site, pay attention to client-side script controls introduced in PCI DSS v4.0 (especially around payment page scripts). We wrote a deep dive on the ecommerce script requirements here: https://merchantalternatives.com/pci-dss-4-0-1-ecommerce-script-requirements/
If you are unsure which SAQ is right, this PCI SAQ explainer is a good starting point: https://www.checkout.com/blog/pci-saq
Mixed channel merchants usually need a setup that keeps channels clean.
At a minimum, you should have:
Depending on your volume and risk profile, you may also want separate merchant accounts (separate MIDs) so that chargeback pressure in one channel does not poison the other.
If you have any kind of "marketplace" or multi-seller model, the separation question becomes even more important. Our marketplace payments compliance guide covers why: https://merchantalternatives.com/marketplace-payment-processing-payfac-kyc-kyb-compliance-2026/
The short answer: you want transparency on what is fixed, what varies, and what triggers risk controls.
Ask these questions before you sign:
1. What pricing model am I on (interchange-plus, flat, tiered), and is it the same for CP and CNP?
2. Are gateway fees and fraud tools bundled, or separate line items?
3. What happens if my chargeback ratio rises for one channel?
4. Do you support 3DS2 and network tokenization, and what does it cost?
5. Can I have separate MIDs for online vs in-store if needed?
If your provider cannot answer these clearly, you will probably find surprises later in your statement.
Lowering CNP costs is mostly about reducing unnecessary risk premiums and avoiding preventable chargebacks.
Tactics that usually help:
If you want the quick version on network tokenization and account updater, start here: https://merchantalternatives.com/account-updater-vs-network-tokenization-guide/
Card-on-file is almost always CNP, even if the first purchase happened in person. Once you store credentials and bill later, you are in CNP rules around stored credentials, disputes, and fraud.
Yes. Tap to pay transactions are card-present, and in most cases they are treated similarly to EMV chip transactions for risk and acceptance, assuming they are processed properly through a certified terminal.
Keyed transactions remove the strongest security signals of in-person acceptance. They are more likely to be treated like CNP, which can mean higher interchange and higher fraud liability.
Not directly. 3D Secure mainly impacts fraud outcomes and can help with liability shift in some cases, which reduces losses and can indirectly improve your effective cost if you are paying for chargebacks and refunds.
Not always, but it can help if one channel has very different risk or refund behavior. Separate MIDs can keep chargeback pressure from spilling across channels and can make reporting cleaner.
You can accept cards in-store and online under one provider, but you should not assume the economics are the same. CP and CNP differ in how fees stack up, how fraud disputes play out, and how much work PCI compliance takes depending on your integration.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look: