Unattended payments

Offline Payment API for Kiosks, Vending, Aircraft and Festivals

Your devices cannot wait for perfect connectivity. This offline-first payment API lets kiosks, vending machines, aircraft POS and festival terminals keep accepting card payments, then sync safely when the network returns.

Queue and sync built in. Compare with online-only payment gateways.
Unattended device payment flow Offline-ready
🕹
Device app
kiosk, vending, onboard POS
intent
Local AffixIO SDK
policy · limits · proofs
YES / NO
Secure offline queue
transactions + proofs
pending
Backend sync API
push batches to AffixIO
synced
Settlement / records
PSP and back office
final

Why unattended devices cannot rely on always-on connectivity

Kiosks, vending machines, aircraft and festival terminals operate at the edge of networks. They move, they roam, and they sit behind constrained links. Assuming a clean online gateway call for every tap is unrealistic.

The result is revenue lost to avoidable declines and fallback modes that are hard to reason about. Operators need a way to keep devices selling while still enforcing risk and business rules.

A vending machine during a signal drop

A commuter taps to buy a drink. At that moment, the cellular connection is down. With an online-only gateway, the transaction fails and the customer walks away.

With an offline-first payment API backed by AffixIO, the device:

  • evaluates local rules and AffixIO decisions to decide whether to approve,
  • dispenses the product and prints or displays a confirmation, and
  • writes a proof-backed record into a queue for later synchronisation.

API pattern: local accept, queue, sync

1. Device calls the local AffixIO client

The device app constructs a payment request and sends it to a local AffixIO SDK or sidecar. The client evaluates merchant policies, offline limits and any cached AffixIO decisions.

2. Approve and queue when policy allows

If policies allow, the device treats the transaction as approved, updates its UI and dispense logic, and appends the request and decision to a secure queue on disk.

3. Sync batches when connectivity returns

A background task monitors connectivity. When links are available, it reads queued items and sends them in batches to a backend sync endpoint. AffixIO provides proofs and reconciles with your PSP, returning definitive statuses to update device state.

4. Integrate with your existing rails

The same pattern can be layered alongside online-only gateways: unattended devices use the offline-capable path, while web and in-store flows keep using real-time processing.

Keep selling when gateways are unreachable
Single policy surface for online and offline
Proof-backed audit trail per device
Lower support load for field operations

Device app → local accept → queue → sync → settlement

The diagram shows a typical layout for kiosks, vending, aircraft and festivals. Devices integrate with a lightweight AffixIO client and your PSP; the control plane for offline decisions lives in AffixIO's infrastructure.

For an overview of offline card flows beyond unattended devices, see how offline card payments work.

Offline payment API architecture Queue + sync
🕹
Unattended device
kiosk / vending / onboard
intent
Local AffixIO client
policies · limits · proofs
YES / NO
Offline queue
per-device transaction log
offline
Sync API
AffixIO + PSP
synced
Settlement and records
issuer / acquirer / back office
final

Example payment request from an unattended device

The example below shows how a device might call an offline-first payment API: first to ask for a decision, and then to sync queued transactions when the link returns.

Device → AffixIO backend TypeScript / HTTP
import fetch from 'node-fetch';

async function requestPayment(deviceId: string, cardToken: string, amount: number) {
  const intent = {
    device_id: deviceId,
    card_token: cardToken,
    amount_minor: amount,
    currency: 'USD',
    context: { location: 'KIOSK-17', vertical: 'vending' }
  };

  const online = await connectivity.isOnline();

  if (!online) {
    // Evaluate locally and queue
    const decision = localAffixio.decide('card_payment', intent);
    if (!decision.allowed) return { status: 'declined_offline' };

    await offlineQueue.append({ intent, decision });
    return { status: 'approved_offline' };
  }

  // Online: call AffixIO API directly
  const res = await fetch('https://api.affix-io.com/payments/offline/intents', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.AFFIXIO_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(intent)
  });

  const body = await res.json();
  if (body.allowed) {
    printer.dispenseProduct();
    return { status: 'approved_online', proof: body.proof };
  }

  return { status: 'declined_online', reason: body.reason };
}

// Called periodically from the device when it regains connectivity
async function syncQueuedTransactions() {
  if (!await connectivity.isOnline()) return;

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

  const res = await fetch('https://api.affix-io.com/payments/offline/sync', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.AFFIXIO_API_KEY}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ batch })
  });

  const result = await res.json();
  await offlineQueue.applyResults(result);
}

For more detail on the reconnect flow and risk controls, see how offline card payments work and how to prevent double-spending offline.

Questions about offline payment APIs for unattended devices

Not necessarily. AffixIO can sit alongside your current PSP or acquirer as a control and verification layer. Devices call AffixIO for yes/no decisions and proofs, and you keep your existing rails for capture and settlement.

Policies include caps on offline exposure: per-device, per-card and per-time-window limits. Once those thresholds are reached, the device can downgrade to requiring online approval or alternative payment methods until it synchronises again.

Yes. The API is environment-agnostic. You can send context such as sector, route or event ID so that your policies can differ by deployment while still using a single decisioning surface.

Online-only gateways work well in web and in-store environments with stable links, but they fail hard when the network disappears. An offline-first API is built around queue and sync behaviour from day one. For a deeper comparison, read alternative to online-only payment gateways for disconnected environments.

AffixIO uses replay protection patterns including nullifiers and uniqueness checks so that repeated use of the same credential or card state can be detected. See how to prevent double-spending offline for more detail on these controls.

Evaluate AffixIO for your unattended fleet

If you operate kiosks, vending, aircraft or festival terminals and need a robust offline payment API, AffixIO can provide the decision layer, proofs and sync patterns while you keep your existing rails.

Talk to us about offline APIs