What offline authorization actually means
The card payment ecosystem has three distinct offline authorization mechanisms. Floor limits define a transaction amount below which a terminal may approve without requesting online authorization from the issuer. Stand-in processing (STIP) is a network-level fallback where the card network's own system approves transactions on behalf of an unavailable issuer, using stored cardholder data and issuer-configured rules. Offline capable (OC) is a card-level setting that allows the chip to authorize certain transactions using internal counters without any network contact at all.
Each of these mechanisms was designed for a specific failure mode: brief issuer unavailability, short network outages, or constrained connectivity environments. They were not designed for extended outages, high-value transaction environments, or situations where the cardholder's account status might have changed significantly since the last online contact. The assumption underlying all three is that the risk of approving a transaction offline is bounded and that the issuer's historical data is a reasonable proxy for current eligibility.
That assumption breaks in several scenarios. Accounts closed or suspended shortly before an outage remain approved under floor limits. Cards involved in detected fraud that has not yet propagated to STIP rules continue processing. OC counters on high-value cards may not reflect recent large transactions on the same card from different terminals. In each case, the authorization is blind to current state.
Where current offline modes fail
The core problem is that offline authorization is designed around historic snapshots rather than current state. Floor limits are set based on historical chargeback rates for a merchant category, not on the current standing of the specific cardholder attempting a transaction. STIP rules are configured in advance and cannot be updated dynamically during an outage. OC counters track cumulative transaction amounts since the last online contact, but they do not know whether that last contact reflected a material account change that occurred five minutes later.
Fraud during offline windows exploits this gap directly. A card compromised after the last STIP refresh or after the OC counter was reset will process normally under offline rules. By the time connectivity is restored and the fraud is detected, multiple transactions may have completed across different terminals. Each one is a chargeback liability for a merchant who had no mechanism to detect the problem at the point of sale.
Eligibility problems compound this. A customer whose account was suspended for non-payment, whose subscription was cancelled, or whose benefits entitlement has lapsed may have their card approved offline even if an online check would have declined it immediately. The merchant completes the transaction in good faith; the chargeback arrives later. The merchant's recourse is limited because the transaction was technically authorized through a recognized offline mode.
The double-spend problem in offline payment flows
Double-spend is the most technically specific failure mode in offline payments. It occurs when the same balance or credit line is used to authorize multiple transactions during a connectivity gap, each at a different terminal. Each terminal approves the transaction independently based on local OC counters or floor limit rules, with no visibility into what other terminals have approved during the same window.
Cryptographic nullifiers address this at the transaction level. A nullifier is a SHA-256 hash derived from a combination of the card identifier, transaction amount, timestamp, and a terminal-specific nonce. Before approving any transaction, the local system checks whether a nullifier for this transaction already exists in the local proof ledger. If it does, the transaction is rejected even if the amount would otherwise be within floor limits. If it does not, the nullifier is written to the proof ledger and the transaction proceeds.
This mechanism requires that the proof ledger be distributed or synchronized across terminals in the same physical environment, such as all terminals at a single merchant location. For a single-terminal environment, the nullifier check is local. For multi-terminal environments, a local mesh synchronization protocol is needed to ensure that a transaction approved on terminal A's nullifier ledger cannot be replayed at terminal B. The proof ledger syncs with the central infrastructure when connectivity is restored, enabling post-reconnect deduplication across the full transaction history.
Cryptographic proof generation without connectivity
Generating a verifiable payment proof without network connectivity requires that all the cryptographic material needed for the proof be available locally. The AffixIO infrastructure uses HMAC-SHA256 based proofs that are under 90 bytes in size. At that scale, a proof can be stored on constrained terminal hardware, transmitted over low-bandwidth connections, and processed rapidly when a batch of queued proofs syncs on reconnect.
The proof contains enough information to verify the transaction's integrity and uniqueness: the transaction identifier, the circuit result (eligible or not), the timestamp, and a signature that can be validated against the issuing system's public key on reconnect. No raw card data or PII is included in the proof. The proof does not contain the underlying verification data; it contains evidence that the verification was performed and what it returned.
This structure means that the proof is independently auditable after the fact. If a transaction is disputed, the proof record demonstrates that an eligibility check was performed at the time of the transaction, what that check returned, and when it occurred. This is separate from the payment network's own authorization record, providing a second evidentiary layer that is particularly useful when the dispute involves the offline authorization mode itself.
How the affixiomerchant SDK handles offline flows
The affixiomerchant SDK is available via npm as affixiomerchant. It is under 33KB with no native dependencies, runs on Node.js 18+, browser environments, and Deno, and uses the Web Crypto API (crypto.subtle) for all cryptographic operations. This means it can be embedded in terminal software, point-of-sale applications, or edge payment infrastructure without requiring a separate cryptographic library.
The SDK's offline handling starts with reconnection detection at 1ms intervals using exponential backoff to a maximum of 5 seconds. When the network is available, verification calls complete normally via the API. When the network is unavailable, the SDK switches to local proof generation using cached cryptographic material, queues the transaction with its proof, and continues processing. The queue is flushed automatically in order on reconnect, with each queued proof submitted and validated against the central infrastructure before the next is processed.
# Install the merchant SDK
npm install affixiomerchant
# Basic offline-capable payment flow
import { AffixMerchant } from 'affixiomerchant';
const merchant = new AffixMerchant({ apiKey: process.env.AFFIX_API_KEY });
const result = await merchant.pay({
circuit_id: 'offline-payment-eligibility',
identifier: 'card:tok_4xB9...',
amount_cents: 4200,
currency: 'USD',
payment_method: 'contactless'
});
// result.eligible: true | false
// result.proof: 'sha256:8d2f1c...' (under 90 bytes)
// result.queued: false (true if processed offline)
// result.nullifier: 'sha256:nullif_7e3a...'The SDK supports chip, contactless, NFC, QR code, and swipe payment methods. The proof structure is identical regardless of the payment method, so the offline queue can contain a mix of transaction types and they sync in sequence without format conversion on reconnect.
The offline authorization flow
The nullifier check happens before proof generation. If the nullifier already exists in the local ledger, the transaction is rejected at that point and no proof is generated. If the nullifier is new, the proof is generated and the transaction proceeds, with the nullifier written to the ledger to prevent any subsequent duplicate. The proof is then either submitted immediately if connectivity is available or queued for later submission.
Terminal, POS hardware, and edge device implications
Payment terminals present specific integration requirements. Most commercial terminals run embedded operating systems with constrained memory and storage. The under-33KB SDK footprint and under-90-byte proof size were chosen specifically to fit within these constraints. A terminal with 128MB of application RAM can maintain a proof ledger of tens of thousands of entries before any storage pressure occurs.
Point-of-sale applications running on general-purpose hardware, such as tablets or integrated POS systems, have fewer constraints but more surface area. The SDK's Web Crypto API dependency means it runs without modification in any modern browser-based POS environment, and the Node.js runtime support covers server-side POS integrations. Edge devices in unmanned payment contexts, such as transit validators, parking meters, or vending machines, benefit from the exponential backoff reconnection logic, which prevents a degraded connection from generating rapid-fire retry storms that could exhaust local resources.
For multi-terminal environments, the distributed nullifier ledger is the most significant integration consideration. Terminals that share a local network can synchronize their proof ledgers using a simple gossip protocol without requiring central coordination. The critical invariant is that a nullifier written on any terminal in the environment propagates to all others before the next transaction is accepted on any of them.
Where AffixIO fits
AffixIO's offline payment verification infrastructure provides the local proof generation, nullifier management, and queue synchronization described above. The offline-payment-eligibility circuit runs the eligibility check locally using cached cryptographic material when the network is unavailable, generating a proof that is valid for submission when connectivity is restored. The circuit is composable with finance-account-standing and finance-fraud-indicator checks to build a pre-transaction verification pass that covers account state and fraud signals in addition to payment eligibility.
Relevant circuits
offline-payment-eligibility: Verifies payment eligibility locally during offline windows, generating a proof for later submissionfinance-account-standing: Checks current account standing; uses cached state during offline operationfinance-fraud-indicator: Surfaces active fraud signals; operates on the last synchronized fraud index during offline windowscross-timestamp-proof: Generates a verifiable timestamp for the offline transaction, binding it to a specific time window for post-reconnect validation
The key distinction: Proof-based offline authorization does not eliminate the need for online synchronization, but it ensures that each transaction that occurs during an offline window has been locally verified, uniquely identified by a nullifier, and cannot be replayed. Connectivity becomes a settlement mechanism rather than an authorization dependency.
Frequently asked questions
What is offline payment authorization?
Offline payment authorization is a mode where a terminal or merchant system approves a transaction without real-time communication with the issuing bank or payment network. Floor limits define the maximum transaction amount that can be approved offline. Stand-in processing and offline capable card settings are the two primary technical mechanisms. The result is that certain transactions complete even when connectivity is unavailable, but the approval is made without current eligibility information.
What is the double-spend problem in offline payments?
Double-spend in offline payments occurs when the same balance or credit line is used to authorize multiple transactions during a connectivity gap, each at a different terminal with no visibility into what others have approved. Cryptographic nullifiers, SHA-256 hashes generated from transaction-specific data, prevent this by uniquely marking each transaction so duplicates are detected locally before any payment instruction is queued. The nullifier ledger syncs to the central infrastructure on reconnect for full deduplication across the transaction history.
How does the affixiomerchant SDK handle offline payments?
The affixiomerchant SDK handles offline payment flows by generating a proof locally before issuing any payment instruction. The proof is HMAC-SHA256 based and under 90 bytes. If the network is unavailable, the transaction is queued with its proof. The SDK detects reconnection at 1ms intervals with exponential backoff to a 5-second maximum, then automatically flushes the queue in order. It is under 33KB, has no native dependencies, and uses the Web Crypto API for all cryptographic operations.
How small are offline payment proofs?
Payment proofs generated by the AffixIO infrastructure are under 90 bytes. This size is deliberate: proofs must be storable on constrained terminal hardware with limited flash storage, transmittable over low-bandwidth connections, and processable rapidly when multiple queued transactions sync on reconnect. The proof is HMAC-SHA256 based and contains enough information to verify the transaction's integrity and uniqueness without including any raw payment data or PII.
What are floor limits and why are they insufficient?
Floor limits are dollar thresholds set by acquirers or card networks below which a terminal may approve a transaction offline without real-time authorization. They are set based on historical chargeback rates for a merchant category, not on the current standing of the specific cardholder. During extended outages, the aggregate of floor-limit approvals can significantly exceed what a standard online authorization flow would have permitted, and accounts suspended or compromised after the last network contact continue to approve normally until connectivity is restored.
What environments benefit most from proof-based offline authorization?
Environments with frequent or predictable connectivity gaps benefit most: transit systems, parking and tolling infrastructure, remote retail locations, event venues, aircraft and maritime payment systems, and edge computing deployments where the device is geographically remote from reliable network infrastructure. In each case, the gap between offline approval and online sync creates a window where unverified transactions accumulate. Proof-based authorization closes that window by performing eligibility verification locally before any transaction is queued.
Build offline payment verification into your stack
See how AffixIO handles proof-based offline authorization for terminals and edge devices.