Offline payments

How Offline Card Payments Work

When connectivity drops, online-only payment flows stop. This page explains how to accept card payments offline, queue them safely, and sync when your systems come back online.

Built for kiosks, transport, events, and remote terminals. Also see alternative to online-only payment gateways and how to prevent double-spending offline.
Offline card payment path Offline-capable
💳
Card / Device
tap, chip, or swipe
intent
Local Approval Logic
limits, rules, yes/no decision
decision
Secure Offline Queue
store transaction + proof
queued
Reconnect & Sync Service
upload, verify, settle
synced

Why online-only payment flows fail offline

Most gateways assume a clean, low-latency network. A terminal sends an authorisation request and waits for a response. In reality, kiosks, transport and event environments experience dropouts, jitter, and long periods with no signal at all.

When the network disappears, a strictly online flow gives you two bad options: decline the customer, or accept the card without structure and hope you can reconcile it later. Both damage trust. You either lose revenue in the moment, or accept risk with no clear audit trail.

A remote kiosk during a connectivity outage

A ticket kiosk in a rural station sells passes throughout the day. For several hours, the backhaul link is down. With an online-only gateway, every card tap fails and queues form. With an offline-capable system, the kiosk:

  • applies local limits and risk rules to decide whether to accept the payment,
  • prints or displays a confirmation to the customer, and
  • writes a signed record into a secure offline queue for later sync.

When connectivity returns, the kiosk syncs its queue with the platform. Each transaction is reconciled against the acquirer, with clear proofs of what the terminal did while offline.

Four stages of an offline card payment

1. Capture the payment intent at the edge

The cardholder taps or inserts their card. The terminal reads card data and constructs a payment intent just as it would for an online transaction. The key difference is that the “can I approve this?” question can be answered locally when the network is unavailable.

2. Apply local rules and limits

The terminal evaluates merchant-configured rules: per-card limits, number of offline transactions allowed, velocity rules, or AffixIO policy decisions cached from an earlier sync. The result is a binary answer: approve or decline.

3. Write a proof-backed record into a queue

For each approved transaction, the terminal writes a record to a secure local queue. At minimum this includes a unique transaction identifier, card token or PAN alias, amount, timestamp, and the policy decision that allowed it.

4. Reconnect and synchronise

When connectivity returns, the terminal connects to an online sync service. It uploads queued records, receives definitive responses from the acquirer or AffixIO-backed verification layer, and marks each local entry as captured, reversed, or in dispute.

Keep selling when networks fail
Clear audit trail of offline approvals
Merchant-controlled risk and limits
Compatible with existing terminals and PSPs

From card tap to reconnect sync

The diagram shows a typical architecture for offline-capable card payments. AffixIO sits next to your payment stack as a binary decision and proof layer, so terminals can enforce the same policies online and offline.

The same pattern works for kiosks, vending, aircraft, and festival terminals. When you are ready to compare providers, read our page on alternatives to online-only payment gateways for disconnected environments.

Offline card payment architecture Queue + sync
💳
Card / Device
tap or insert
request
Local Approval Engine
limits · policies · AffixIO decision
YES / NO
Secure Queue
proof, nullifier, state
offline
Reconnect Sync Service
AffixIO + PSP / acquirer
settled

acceptPayment() with offline queue and sync

The following pseudocode shows a simplified edge application that accepts card payments, evaluates policies with AffixIO, and queues transactions while offline.

Edge terminal service pseudo / TypeScript-like
type PaymentIntent = {
  id: string;
  amount: number;
  currency: string;
  cardToken: string;
};

async function acceptPayment(intent: PaymentIntent) {
  const online = await connectivity.isOnline();

  // Ask AffixIO for a binary decision when online
  const decision = online
    ? await affixio.decide('card_payment', {
        intentId: intent.id,
        amount: intent.amount,
        currency: intent.currency,
        cardToken: intent.cardToken
      })
    : { allowed: null, reason: 'offline' };

  const canApproveLocally =
    decision.allowed === true || localRules.allowWhileOffline(intent, decision);

  if (!canApproveLocally) {
    return { status: 'declined', reason: 'policy_denied' };
  }

  // Record a proof-backed offline entry
  const record = {
    intent,
    decision,
    approvedAt: new Date().toISOString(),
    nullifier: affixio.nullifierFrom(intent.id, intent.cardToken)
  };

  await offlineQueue.append(record);
  printer.printReceipt(intent, record);

  if (online) {
    // Best-effort sync in-session
    syncService.flushQueue();
  }

  return { status: 'approved_offline', queueId: record.nullifier };
}

// Called by a background task when connectivity returns
async function syncOfflineQueue() {
  if (!(await connectivity.isOnline())) return;

  const batch = await offlineQueue.readBatch(50);
  if (!batch.length) return;

  const result = await syncService.pushBatch(batch);

  // Mark confirmed, reversed or in-dispute according to upstream response
  await offlineQueue.applyResults(result);
}

To go deeper into risk controls around repeated use of the same offline state, see how to prevent double-spending offline.

Questions about offline card payments

Yes. Most card schemes explicitly support offline-capable terminals and card risk parameters. The exact limits depend on scheme rules and your acquirer, but the idea is the same: the terminal can approve transactions up to agreed limits and then reconcile them later.

Risk is managed through local rules and limits, combined with verification signals from services like AffixIO. You define what is acceptable: per-card amount caps, maximum number of offline approvals, velocity checks and other constraints that keep loss within a controlled envelope while still serving customers.

When you sync, some entries may be declined by the acquirer or issuer. With a structured offline queue and a proof-backed record, you can trace exactly what happened on the device, adjust future limits, and optionally use AffixIO's eligibility or access layers to reduce similar risk in the future.

Traditional store-and-forward features are often opaque: it can be hard to see which transactions were approved, on what basis, and how they reconcile. AffixIO treats offline payments as first-class decisions with a binary yes/no signal, cryptographic proofs, and explicit nullifiers, so you can reason about double-spend prevention and compliance across fleets of devices.

You can start with our overview of offline payment verification and our trend piece on resilient offline verification. For disconnected environments, compare options in alternative to online-only payment gateways.

See how AffixIO fits your offline payment stack

If you run kiosks, vending, aircraft or festival terminals and need offline-capable card payments, AffixIO gives you a binary decision and proof layer that works alongside your existing PSP or acquirer.

Talk to us about offline payments