Card-Present Payment Architecture: The Omnichannel Reconciliation Problem

In e-commerce, every transaction authorises online. There is no other mode — if the connection to the PSP drops, the checkout simply fails. Card-present is different in a way that most CNP-native operators underestimate until they run a physical location themselves: a terminal can approve a payment with no live connection to anyone at all.

That one capability — offline authorisation — is the root of almost everything else that's structurally different about card-present payment architecture. It changes who bears fraud loss, how PCI DSS scope is drawn, what reconciliation has to match against what, and what "the same customer" even means when they show up in both channels. This is the operator breakdown of what changes when a merchant has to run — and reconcile — both.

Two paths, one card network

A CNP transaction runs browser or app → payment gateway → acquirer → card network → issuer, and back. The gateway is a software layer; nothing about the path requires physical proximity to the cardholder, and nothing in the path can proceed without a network round-trip.

A card-present transaction runs card or device — a phone or watch tapped via Apple Pay or Google Pay reads through the same NFC path a contactless card does — → point-of-sale terminal → acquirer → card network → issuer — with one addition CNP doesn't have: the terminal itself is a certified compute environment that can make an approval decision using data stored on the EMV chip, without reaching the acquirer at all. The terminal is not just an input device relaying data to a gateway; under defined conditions, it is the authorising party.

Both paths ultimately touch the same card networks and the same interchange and scheme fee structure — a Visa transaction is a Visa transaction whichever channel it came from. What differs is everything upstream of the network: who owns the hardware, who certifies it, how authorisation decisioning is split between the terminal and the issuer, and what happens when the connection isn't there. Acquiring economics themselves also shift by channel — card-present interchange and routing costs aren't identical to CNP, which is one more reason the acquiring margin math looks different once a merchant runs both.

Terminal and POS roles: who owns what

An e-commerce stack has one hardware-adjacent question — whose SDK renders the checkout field. A card-present stack has three, and they're usually owned by different parties:

The terminal estate. Physical devices, purchased or leased, deployed across every register or location. Someone owns the inventory, the firmware update cycle, and the physical replacement pipeline when a device fails or is lost.

Certification. Every terminal model has to be certified — by the card networks (EMV Level 1/2), and separately by each acquirer or gateway it connects through (EMV Level 3, acquirer-specific). A terminal certified against one acquirer's host doesn't automatically work against another's without re-certification. This is a real switching cost that CNP operators, who can usually re-point a checkout SDK in an afternoon, don't have an equivalent for.

Key management. Terminals hold cryptographic keys used for PIN encryption and, where deployed, P2PE (covered below). Key injection happens either at manufacture, at a key-injection facility, or remotely via the acquirer/gateway's key management service. Losing control of key management — a terminal deployed without properly injected keys, or a vendor relationship that lapses mid-fleet — is an operational failure mode e-commerce has no analogue for.

Who plays these roles depends on the stack. Square built its business around owning all three for the merchant — plug-and-play hardware, pre-certified against Square's own acquiring, keys injected before the device ships. Stripe Terminal, Adyen, and Worldpay-class providers instead hand the merchant (or a POS/ISV partner) a certified device and a hardware SDK, with the merchant's team or a systems integrator responsible for deployment. Neither model is wrong; the point is that a card-present RFP has to answer these three ownership questions explicitly, where a CNP RFP mostly doesn't need to.

Online vs offline authorisation: the core conceptual difference

This is the part of card-present architecture with no CNP equivalent whatsoever. A CNP transaction is either approved online or declined — there is no third state. A card-present EMV transaction has three possible outcomes: approved offline, approved online, or declined — and the terminal, not the issuer, decides which of the first two paths a given transaction takes.

The decision runs through EMV terminal risk management, three checks operating together:

Any one of the three can force a transaction online; none of them can force an offline-eligible, sub-floor-limit transaction to decline outright without a network check. The issuer also sets its own offline transaction-count and offline-amount limits encoded on the card, independent of what the terminal enforces — a second layer of control the merchant doesn't configure at all.

The practical consequence: a card-present merchant's authorisation logic lives partly in software they don't operate (the chip, the issuer's parameters) and partly in terminal configuration they do (floor limits, random-selection thresholds). An e-commerce operator tuning decline rates is tuning 3DS2 rules and PSP-level risk settings — a card-present operator is also tuning terminal risk parameters that determine whether a transaction gets an online check at all.

Store-and-forward: what happens when the terminal loses its connection

Offline-eligible authorisation solves one problem; connectivity loss creates another. When a terminal genuinely cannot reach the acquirer — an outage, a mobile terminal out of signal range — merchants running store-and-forward (SAF) continue accepting transactions, which the terminal queues locally and forwards once connectivity returns.

This is where the risk in offline authorisation actually lands. An offline-approved transaction is not a guaranteed-good transaction — it is a transaction the terminal decided didn't need an immediate online check, forwarded later for the issuer to actually decide. Vendor documentation is consistent on the exposure:

• Adyen enforces separate chip floor limits, contactless floor limits, and a store-and-forward maximum before allowing offline processing, states plainly that the merchant is "fully liable for the risk of failed captures, chargebacks, and disputes" on offline-processed payments, and runs Auto Rescue to retry failed store-and-forward payments for up to one month. Typical SAF authorisation rates run from roughly 95% up depending on industry — meaning several percent of offline-approved transactions come back declined after the fact, with no way to reverse a completed sale.
• Stripe Terminal requires a reader to have connected online at least once, and again at least every 60 days, to remain eligible to collect offline; the merchant "assumes all decline and tamper-related risk" for offline transactions, and a declined offline transaction cannot be recovered.
• Square defaults its offline cap to $100 per transaction (merchant-adjustable up to a $50,000 hard maximum), gives sellers 24 hours to reconnect before payments are considered overdue, and expires unforwarded offline payments after 72 hours — with the seller responsible for any that expire, decline, or get disputed.

The design pattern across all three is identical even though the specific limits differ: cap the exposure per transaction, cap the exposure per device, force a reconnection window, and put the loss on the merchant if a stored transaction ultimately fails. No e-commerce checkout has an equivalent "accept it now, find out later if it was good" mode — offline authorisation is a deliberate availability-over-certainty trade-off that only makes sense at a physical point of sale where refusing service costs a sale on the spot.

Merchant IDs and store hierarchy: the reconciliation problem hiding in plain sight

A single-location e-commerce merchant typically has one merchant ID (MID) per PSP relationship. An omnichannel operator with physical locations almost never does — and MID sprawl is one of the most under-appreciated reconciliation problems in card-present operations.

Structurally, most acquirers model this the same way: a top-level account owns one or more merchant accounts, and each merchant account can have multiple physical stores underneath it. Adyen's version is explicit about it — company account → merchant account(s) → stores, where each store carries its own ID unique across the entire platform, letting a retailer separate settlement, reporting, and risk configuration by store while still rolling everything up to a single merchant account for payout purposes.

The reconciliation consequence: every additional MID or store ID is another settlement stream to match, another set of fee schedules to verify, and another place a transaction can land in the wrong bucket. A 40-store retail chain that provisioned MIDs store-by-store as it grew — sometimes across more than one acquirer, if locations were added through acquisitions or regional deals — is running dozens of parallel settlement reconciliations where the underlying business logic wants one. This is functionally the same class of problem online-only PSP reconciliation already has, multiplied by however many MIDs the store estate has accumulated, and it's rarely visible until finance tries to close the month and can't cleanly map store-level revenue back to a single settlement report.

The fix is structural, not procedural: consolidate onto the fewest MIDs the acquiring relationship and card network rules allow, use the store-hierarchy layer the acquirer already provides instead of provisioning a new top-level MID for every location, and treat "how many MIDs do we have and why" as a standing finance question, not a one-time onboarding decision.

Card-present fraud and liability shift

EMV's liability shift is the single biggest reason card-present and CNP fraud exposure look nothing alike. Before EMV, counterfeit card-present fraud loss defaulted to the issuer. After the shift, liability for counterfeit fraud falls on whichever party in the transaction has the lower technology: if a chip card is run through a chip-capable terminal, the issuer still eats the loss; if a chip card gets swiped at a stripe-only terminal, the acquirer/merchant does. Properly processed chip-on-chip transactions carry counterfeit-fraud liability the merchant essentially never sees.

The chargeback taxonomy reflects this split directly. Mastercard's card-present liability-shift code — 4870, Chip Liability Shift — exists specifically for fraud that occurred because a chip card wasn't processed as a chip transaction. It sits apart from 4837 (No Cardholder Authorization), the network's general fraud code that dominates CNP disputes, and from Visa's 10.4 (Other Fraud: Card-Absent Environment) — the single highest-volume e-commerce fraud code and the only one eligible for Compelling Evidence 3.0 defense. A merchant running chip-capable terminals essentially never fights a 10.4-equivalent card-present dispute for counterfeit fraud; that liability was already shifted away before a chargeback could be filed.

What card-present chargeback exposure actually looks like instead: processing errors (duplicate charges, incorrect amounts), cardholder disputes over goods or services rather than card authenticity, and — the category EMV liability shift doesn't touch at all — offline-approved transactions that come back declined after the fact, which behave more like a bad debt than a disputed fraud claim. CNP exposure is the mirror image: liability defaults to the merchant far more often, which is exactly why network tokens and 3DS2 exist as CNP's answer to what chip-and-PIN already solved at the physical point of sale.

Omnichannel credential identity: the hard part

Here is the question that terminal vendor marketing skips entirely, and where most of the real operator value in omnichannel sits: is the card a customer taps in-store the same credential as the card they have on file online?

Structurally, the answer is usually no — not automatically. A card-present transaction produces a cryptogram and, if tokenised, a token scoped to that terminal's MID. An online stored-credential transaction produces a separate card-on-file token scoped to the PSP vault or, if the merchant has adopted them, a scheme-issued network token. Nothing in the base architecture links "the physical card that was tapped in Store #14" to "the card-on-file token attached to this customer's online account" unless the platform is deliberately built to do that matching — typically through a shared shopper reference that both the in-store and online integrations write to consistently, so the platform can recognise the same person (and ideally the same underlying PAN, via the scheme token relationship) regardless of channel.

This is what a genuinely unified platform buys an omnichannel merchant, and it's also exactly where split stacks quietly fail. Click-and-collect (pay online, verify and hand over in-store) and buy-online-return-in-store (BORIS — refund in-store against an online purchase) both depend on the in-store system being able to look up an online transaction and, in the return case, credit back to the original instrument. If online runs through one PSP and in-store through an entirely separate acquirer with no shared customer or token identity, both flows degrade to manual lookups by order number — workable, but it's staff friction on every transaction rather than a platform capability, and it's the first thing that breaks when a customer's online card and in-store card are the same physical plastic but the systems have no way to know that.

Refunds across channels

Refund mechanics for card-present transactions follow the same core control logic covered in PaymentBrief's refund operations runbook — a refund is a new credit to the original instrument after settlement, not a reversal, and it should be locked against any transaction with an open dispute. What's different in card-present is the credential-identity question above intersecting with channel: a same-channel refund (in-store purchase, in-store return, card physically re-presented) is mechanically simple. A cross-channel refund — an online purchase returned in-store, or an in-store purchase refunded through a customer service team that only has web tooling — requires the in-store system to locate the original online transaction and issue the credit against the instrument that was originally charged, not whatever card the customer happens to have in hand at the return counter.

Where this breaks in practice: a store associate cannot look up the online order, so they process a new manual refund to whatever card is presented, or issue store credit instead — both of which can violate the "refund to the original instrument" rule and weaken any later dispute defense if the transaction is also charged back. The fix is the same credential and order-identity linkage the click-and-collect problem needs — if in-store tooling can pull up an online order by reference, refunding it correctly stops being a policy exception and becomes the default path.

Reconciliation across online and offline

Online-only reconciliation is a three-way match: internal order ledger, PSP settlement report, bank statement — the model PaymentBrief's PSP reconciliation runbook covers in depth. Card-present adds a layer in front of all three: the POS terminal's own batch.

A terminal batch close is the point where a physical location finalises the day's authorisations into a settlement submission — conceptually similar to an online gateway's capture step, but running on its own schedule, driven by the terminal or POS system rather than the checkout flow, and vulnerable to failure modes online capture doesn't have (a terminal that never got batched because a manager forgot to close it out, or a device that batched twice after a connectivity blip). The full chain becomes: POS terminal batch → acquirer settlement file → PSP/gateway ledger → bank statement — a four-way match instead of three, with the store-hierarchy and MID-sprawl problem from earlier multiplying how many parallel instances of that four-way match a multi-location merchant actually has to run every settlement cycle.

The specific breaks worth building detection for: a terminal batch that never closed (revenue the POS system shows as sold but that never entered the settlement pipeline at all — the single worst version of the "missing bank credit" break, because it's invisible until someone manually audits terminal-level sales against deposits); store-and-forward transactions that settle on a delayed timeline relative to same-day terminal batches, creating a timing gap that looks like a break but resolves itself a day or two later; and per-store or per-MID fee schedules that differ from the online rate card, producing fee-mismatch breaks that are actually correct once you know which MID a given settlement line belongs to.

PCI scope: P2PE vs standard terminals

PCI DSS scope is one of the few places card-present architecture can genuinely come out ahead of e-commerce, but only if the terminal deployment is validated for it. A validated PCI P2PE solution encrypts cardholder data inside the terminal itself, the moment the card is read, and only decrypts it inside the P2PE solution provider's secure environment — the merchant's own POS, network, and back-office systems never see usable card data at all. PCI SSC is explicit that merchants using a PCI-listed P2PE solution carry fewer applicable PCI DSS requirements than a standard implementation, typically validating on the lighter SAQ P2PE rather than a standard terminal SAQ.

A standard, non-P2PE terminal — one where card data is encrypted in transit but decrypted somewhere inside the merchant's own network or POS application before reaching the processor — doesn't get that scope reduction. The merchant's network segment carrying that decrypted data is in scope, same as any other system that touches cardholder data.

This runs parallel to, not instead of, the e-commerce scope questions covered in PaymentBrief's PCI DSS 4.0 year-one review — script inventory, MFA on the cardholder data environment, and the rest of the 51 requirements that became mandatory in 2025 still apply wherever card data or its output actually flows, in-store included. What P2PE buys is a narrower answer to where that flow touches the merchant's own systems in the first place — the same objective SAQ-A eligibility chases for a fully outsourced e-commerce checkout, achieved through hardware encryption instead of an iframe boundary. An omnichannel merchant running a validated P2PE terminal estate and an outsourced-checkout e-commerce site can genuinely minimise PCI scope on both channels — but each channel earns that reduction through a different mechanism, and neither one is automatic.

Choosing a stack: unified acquirer vs separate providers

Every omnichannel merchant eventually faces the same build decision: one acquirer/PSP across both channels, or separate providers for online and in-store.

Adyen's Unified Commerce positioning is built on exactly this trade-off — one platform, one data model, across online, in-app, and in-person, versus a legacy acquirer's online and in-store stacks that were built or acquired separately and integrated after the fact. The same tension shows up a level down in the market: an operator can run Stripe online and Square in-store and make it work, but it means two reconciliation streams, no token portability between the stacks, and separate support relationships — a deliberate trade of unification for best-of-breed fit in each channel. Neither approach is universally correct. The unified stack wins whenever credential identity and consolidated reconciliation matter more than getting the single best tool in each channel; the split stack is defensible when the physical estate has requirements — a specific POS ecosystem, a regional acquiring relationship, a hardware format — that the unified provider genuinely can't match.

Failure modes

What this means for operators

The gap between card-present and CNP architecture isn't a hardware detail — it's that card-present has a mode CNP structurally cannot have: approving a transaction with nobody on the other end of the line, right now, to ask. Every other difference in this piece — liability shift, PCI scope, the extra layer in reconciliation, the credential-identity problem — traces back to that one capability and the trust it requires the merchant to extend to the terminal.

For an operator building or auditing an omnichannel stack, the sequencing that matters: get the terminal and PCI scope questions right first (they're mostly one-time architecture decisions), then build the MID/store hierarchy deliberately rather than letting it sprawl, then solve credential identity before promising customers click-and-collect or a unified return policy — because that promise is only as real as the token linkage underneath it. Reconciliation and fraud liability mostly fall out correctly once those three are solved; they're where the pain shows up when they weren't.