When a POS has no connectivity, merchants still need to accept payments. The industry uses terms like “offline transaction” and “offline processing” loosely — but in EMV terms, offline EMV authorization and store-and-forward (SAF) are two completely different mechanisms. Conflating them leads to wrong assumptions about risk, liability, and what your terminal is actually doing.
The Core Difference
| Offline EMV | Store-and-Forward | |
|---|---|---|
| Who decides | Card + terminal jointly, using EMV risk rules | Terminal “approves” unilaterally; issuer decides later |
| Authorization | TC (offline approved) or AAC (offline declined) — issuer may never see an auth | ARQC stored; online auth sent when connectivity returns |
| Risk control | Card/terminal parameters: floor limits, AUC, DDOL, consecutive offline caps | Acquirer/PSP rules: amount limits, count limits, BIN rules |
In short: Offline EMV = the card decides now, and the issuer may never see an auth. Store-and-forward = the terminal approves the sale now, and the issuer actually decides later.
Offline EMV: The Card Decides
In a true offline EMV transaction, the EMV kernel and the card jointly determine the authorization outcome locally. During Terminal & Card Action Analysis, if floor limits and risk checks permit, and the card’s Application Usage Control (AUC) allows offline, the kernel requests a cryptogram from the card. The card can return:
- TC (Transaction Certificate) — offline approved; the transaction can go straight to clearing with no issuer auth message
- AAC (Application Authentication Cryptogram) — offline declined
- ARQC (Authorization Request Cryptogram) — go online; if connectivity is unavailable, the merchant may fail the transaction or fall back to SAF, depending on configuration
Offline Data Authentication (SDA/DDA/CDA), CVM, and EMV risk management (AIP, floor limits, DDOL, etc.) still run. From a scheme perspective, the transaction remains a full EMV transaction. Risk is bounded by the issuer’s configuration in the card and by terminal parameters — typically low amounts and a cap on consecutive offline approvals.
Store-and-Forward: The Issuer Decides Later
Store-and-forward (also called deferred authorization) works differently. From the EMV kernel’s point of view, the transaction is intended to be online — an ARQC is generated. But because there is no host connectivity, the PSP or terminal application:
- Fabricates an “offline accepted” result at the application/UI level
- Stores PAN, track data, EMV tags, ARQC, and contextual fields for later forwarding
- When connectivity returns, sends normal online authorization messages for all stored items
The issuer then responds approve or decline as usual. You can get post-facto declines for insufficient funds, risk rules, closed accounts, or any normal decline reason. There is no EMV offline authorization by the card — the terminal has simply deferred the real decision.
Risk is controlled purely by acquirer/PSP rules: per-transaction amount limits, daily caps, count limits per MID/TID, BIN rules. The merchant assumes the exposure: they delivered goods or services without a confirmed authorization. Acquirers respond with tight limits on number and amount per terminal per day.
Risk and Liability
| Offline EMV | Store-and-Forward | |
|---|---|---|
| Fraud exposure | Limited by card and terminal EMV parameters | Substantially higher; issuer may decline later |
| Chargeback position | Stronger if EMV profile was followed correctly | Merchant bears exposure; no confirmed auth at time of sale |
| Typical controls | Floor limits, offline caps, AUC | Amount limits, daily caps, count limits per MID/TID |
Practical Impact: SmartPOS vs SoftPOS on COTS
This distinction matters when you choose or implement a platform.
Many PSPs explicitly state that mobile and SoftPOS solutions do not support true offline EMV — they only support store-and-forward (or no offline at all). On COTS-based SoftPOS, “offline transaction” almost always means SAF/deferred authorization, not EMV offline TC.
On dedicated SmartPOS with full EMV kernels and secure elements, acquirers may enable both:
- Try EMV offline first (if the card profile allows)
- Fall back to store-and-forward when offline EMV is not supported or when the card demands online (ARQC)
So in a SoftPOS-COTS context, you typically have:
- Online EMV as the main path
- Optional store-and-forward with configurable thresholds (per-transaction amount, daily cap, count) at the payment engine or gateway level
On SmartPOS, you may have true EMV offline decisions plus an additional SAF layer for resilience when the card requires online but connectivity is down.
Key Takeaways
Offline EMV and store-and-forward are not the same. One is a card-driven EMV decision; the other is a deferred online authorization.
Terminology is misleading. Acquirers sometimes call SAF “offline transaction processing” — but it is not EMV offline authorization.
Risk profiles differ. Offline EMV is bounded by EMV parameters; SAF is bounded by acquirer rules, and the merchant carries more exposure.
Platform matters. SoftPOS on COTS usually means SAF only. SmartPOS may support both EMV offline and SAF.
Scoping and ops. When you design limits, reporting, and reconciliation, know which mechanism you’re actually using — it affects liability, chargeback handling, and how you explain “offline” to merchants.
For a deeper dive: This topic is covered extensively in Point-of-Sale Systems Architecture: A Practical Guide to Secure, Certifiable POS Systems — Chapter 14: Offline and Store-and-Forward Implementation. The book includes storage architecture, synchronization protocols, reconciliation patterns, and scheme-specific rules.