Offline Payments: Taking Cards When the Internet Drops

There is no "offline mode" in the rulebook

What terminal vendors sell as offline or store-and-forward maps onto two different things in Visa's rules, and merchants who conflate them get the risk wrong. The first is a below-floor-limit transaction: Visa defines a floor limit as "a currency amount that Visa has established for a Transaction, above which Online Authorization is required," and Section 5.7.3.4 lists a transaction amount below an applicable floor limit as one of the situations in which a merchant need not obtain an approval response before completing a transaction. The second is deferred authorisation, which covers a transaction that cannot be submitted at the time because of connectivity, a system issue or other limitations. These are not the same exception, they do not apply to the same transactions, and only one of them involves a clock.

Deferred authorisation has a deadline, and an indicator

Section 5.7.3.3 sets out what an acquirer or merchant must do when a transaction cannot be submitted at the time. Both of the following apply: include a deferred authorisation indicator in the authorisation request, and request authorisation within 24 hours of the transaction date for all merchant categories other than MCC 4111, 4112 and 4131, which get 4 days. In the Europe Region (Denmark), MCC 5411 and 5912 get 7 days, and only where a temporary connectivity or system issue outside the merchant's control prevented a request within 24 hours. The indicator is not optional formatting. A queued batch that goes up the next morning without it is not a deferred authorisation in the sense the rule permits — it is a late submission, and the difference matters when something is disputed.

Who eats the loss, in the rules' own words

Section 5.8.2.3 makes an acquirer liable for counterfeit transactions completed in a card-present environment where a list of conditions all hold, and one of them is: "The Transaction was below the Merchant's Floor Limit and did not receive Authorization." Separately, and effective for disputes processed through 23 October 2026, an issuer may initiate a dispute under Dispute Condition 11.1: Card Recovery Bulletin where the transaction was below the merchant's floor limit, the merchant did not obtain authorisation, and the account number was listed in the Card Recovery Bulletin for the Visa region in which the merchant outlet is located on the transaction date. Whether that liability reaches you or stops at your acquirer is set by your merchant agreement, not by the network rules — which is the contract clause to find before you turn the feature on, not after.

Contactless terminals have their own floor limit setting

Offline behaviour on a contactless reader is a configured value, and Visa's Table 5-8 says what it has to be. An acceptance device compliant with the Visa Contactless Payment Specification version 2.1 or later, or the EMV Contactless Specification for Payment Systems Book C-3, must set the "Reader CVM Required Limit" to the applicable cardholder verification limit and the "Reader Contactless Floor Limit" to the applicable proximity payment floor limit. The same table also requires that a contactless device must not limit the transaction amount of a contactless transaction. If a terminal is queueing contactless taps at a threshold nobody chose, that is a configuration your acquirer set and can explain. Ask what the values are rather than what the feature is called.

A queued transaction is still account data

The device holding a queue is holding payment account data until it clears, and the PCI Security Standards Council is unambiguous about who that reaches: PCI DSS "is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD)." Storing transactions locally is storage, which is why offline behaviour belongs in the same conversation as your PCI scope rather than being treated as a terminal convenience. The device itself has a parallel set of approvals: EMVCo states that EMV Level 1 testing "assesses the compliance of the acceptance device with the communication protocols defined within the EMV Chip Contact and Contactless Specifications" and that Level 2 testing "assesses the compliance of the acceptance device with the software features" in those specifications — and it is the Level 2 software layer that implements the offline decision. Ask your provider where queued transactions are held, in what form, and for how long, and ask your acquirer what that does to your scope.

Setting your own exposure, without inventing a number

Nothing in the public rules tells a merchant what total offline exposure to accept, and any figure quoted as a standard is somebody's default rather than a requirement. What the rules give you is the shape of the decision: the clock is 24 hours for most categories, an unauthorised below-floor-limit sale has a named liability path, and the merchant agreement decides whether that path ends at you. So the inputs are your average ticket, how long your outages actually last, and what your agreement says about chargeback and counterfeit liability. Set the limit against those three, review it after any outage that filled the queue, and write down who is allowed to change it.

An illustrative example of the trade being made

Illustrative example, made-up round numbers. A café with a $12 average ticket loses connectivity for 90 minutes on a Saturday and queues 200 sales worth $2,400. Every one of those goes up inside the 24-hour window with a deferred authorisation indicator, and a handful decline — the customers are gone, and the café absorbs those. A jeweller with a $3,000 average ticket running the same configuration queues eight sales worth $24,000 against the same decline risk, with no cardholder present to re-run. The feature is identical; the exposure is not. The question is never whether offline is safe, it is what your own queue is worth at the moment the connection drops.