Products

Get paid

Move money

Infrastructure

Solutions

By industry

Developers

Build

Tools

npm i @pediwave/node
Pricing
Company
Get started Sign in

Offline payments

Get paid where the network isn't.

A customer's phone taps your terminal with no signal on either side. Both devices sign. When the network returns, the tap settles on the ledger and you are paid. You choose, in advance, who carries a double-spend.

Talk to sales Read the protocol ↗ (opens docs site)

Offline payments are available to pilot merchants. Talk to sales to join.

  1. 1 Connected
  2. 2 Offer sent
  3. 3 Accepted
  4. 4 Signed
  5. 5 Confirmed
A tap with no network, settled the moment the network returns.

How it works

From enrolment to payout in five steps.

The money stays on the ledger throughout. The phone carries a signed claim to it, and the terminal carries the customer's signature.

Choose a step

  1. Step 1

    Enrol a terminal

    The terminal generates its own signing key inside secure hardware, so the key never leaves the device. PediWave verifies the hardware attestation, records the key, and issues the terminal its own credential. You attach a policy: how much it may accept per tap, how much it may hold before it must settle, and how long it may wait.

    Works on POS terminals, Android handsets and soft-POS.

  2. Step 2

    Load an offline balance

    While online, the customer moves money into an offline balance tied to their phone. The balance lives on the ledger, in an account bound to that device. The phone receives a signed claim on it and an identity assertion valid for 24 hours. It can never spend more than was loaded.

    Your own app can hold this balance for your customers. See “Your app can be the wallet” below.

  3. Step 3

    Tap

    The terminal asks for the amount. The customer's phone checks the terminal is genuine, confirms with a PIN and signs the payment. The terminal checks the customer's signature and its own limits, then signs the acknowledgement. Both devices keep the signed pair. No network is involved.

    Over BLE, NFC, local Wi-Fi or a two-scan QR exchange.

  4. POST /v1/offline/batches 
    POST /v1/offline/batches
Authorization: Bearer tk_test_…
Idempotency-Key: term_01J9…-118
PediWave-Version: 2026-10-01

{
  "sequence": 118,
  "previous_hash": "…",
  "items": [ /* 43 dual-signed pairs */ ],
  "terminal_signature": "…"
}

// 200 OK
{
  "id": "obat_01J9…", "sequence": 118,
  "accepted": 41, "failed": 1, "quarantined": 1,
  "gap_detected": false, "items": [ … ]
}
    One upload, a result per tap. A quarantined tap is held for review; the rest settle.

    Step 4

    Settle

    When either device reconnects, it uploads its signed pairs. Whichever side uploads first settles the tap; the other side's later upload is matched, not paid twice. Each tap is value-dated at the moment it was signed, and every signature is checked against registered keys.

    A terminal uploads a signed, sequenced batch, so a missing batch is detected.

  5. Step 5

    Get paid

    A settled tap is a payment like any other. Fees, splits and settlement work the same way, the tap appears in your settlement report with its terminal and signing time, and your systems receive the offline.payment.settled event.

    Taps bound to a payment intent also fire payment_intent.succeeded.

What it needs

Three things on each side of the counter.

What offline payments need from the customer and from you
For the customerFor you
A phone with hardware-backed keys (StrongBox or TEE) A terminal, soft-POS or your own app with the PediWave Offline SDK
A supported wallet, or a purse your app issued A policy: per-tap limit, outstanding cap, settlement window
An identity assertion refreshed every 24 h A loss policy: yours, PediWave-assured, or shared

The identity assertion refreshes automatically whenever the phone is online. If it is older than 24 hours, the phone stops paying offline until it reconnects; it can still receive.

POST /v1/offline/policies 
{
  "floor_limit_per_tap": 2000000,
  "max_outstanding": 50000000,
  "max_taps_per_hour": 60,
  "max_offline_hours": 72,
  "settlement_window_hours": 168,
  "loss_allocation": "merchant"
}

201 Created

{ "id": "opol_01J9…", "object": "offline_policy",
  "policy_expires_at": "2026-10-11T09:00:00Z" }
Amounts are in kobo: ₦20,000 per tap, up to ₦500,000 held. Settle within seven days.

Limits

Limits apply before anything is signed.

Each terminal carries a policy signed by PediWave: the most it may accept per tap, the most it may hold unsettled, how many taps an hour, and how long it may wait before settling. The terminal checks every tap against it before it signs. A policy expires 24 hours after it was last refreshed, and a terminal with an expired policy stops accepting until it reconnects.

Read the policy reference (opens docs site)
Who carries a double-spend loss

Merchant: You carry a verified double-spend loss. You receive the signed proof of both taps and an offline dispute you can pursue against the payer.

PediWave-assured: PediWave covers verified double-spend losses from its assurance pool, in return for a premium in basis points on your offline volume.

Shared: Verified losses are split between you and PediWave in the proportion agreed at underwriting.

  • Tap 1 ₦9,000 · settled
  • Tap 2 ₦8,000 · same phone · quarantined
  • Balance at load ₦10,000

Your policy is set at underwriting. The premium is shown on Pricing.

Loss policy

Double-spend has an owner, and you choose it.

The ledger cannot be overdrawn. If a cloned or rolled-back phone signs the same balance twice, the first tap settles and the second fails. The question is only who carries that loss, so you decide before you accept a single tap. In every case the payer's device is blocked, a fraud case is opened, and recovery is pursued from the payer's account when funds appear.

How the assurance pool works

Exposure

See what is held, where, and for how long.

Exposure is shown per terminal and for the whole business: how much is held unsettled, the ceiling, the headroom, and the age of the oldest unsettled tap. You are alerted at 80 % of the ceiling, and when a terminal holding taps stays silent longer than its policy allows. Each terminal also sends a signed "no taps since" note when it reconnects, so a quiet terminal is never mistaken for a lost batch.

Payer mode

Your customers can pay offline from your own app.

The same SDK runs in payer mode inside your app. Customers you have already verified are registered on your attestation, with no extra one-time code, and hold a purse you fund from your float after taking their money your way. Loading a purse goes through your server; settlement goes straight to PediWave, which sends you a webhook for every settled tap. Customers can also pay each other offline, if you allow it.

Payer mode in the docs (opens docs site)

Banks and agents

Cash in and cash out at the POS, with no network.

Agents take deposits and pay withdrawals offline. A customer with your bank's app withdraws with a tap from their purse; a customer with a feature phone withdraws with a single-use cash-out code obtained from the bank's own channels, such as its USSD menu. Deposits are signed by the agent's terminal and credited when it reconnects.

Banks & agents

Revocation

A stolen terminal's future taps fail. Its honest past taps still settle.

Revoke a terminal and its credential stops working at once. Taps it signed before the moment of revocation still settle; taps signed after it are quarantined and never paid. Customers' phones stop trusting the terminal at their next identity refresh, within 24 hours.

How the devices talk

Four ways to tap without a network.

  • BLE

    Bluetooth Low Energy between phone and terminal, for most Android POS devices.

  • NFC

    The phone acts as a card to the terminal's reader, or reads the terminal itself.

  • Local Wi-Fi

    A direct local link where Bluetooth and NFC are unavailable.

  • QR two-scan

    The terminal shows a signed request, the phone scans it and shows its signed reply back. For merchants with a screen and no radio.

POS vendor transport SPI

POS makers can plug their own transport into the SDK.

The protocol, briefly

Three keys make a tap trustworthy. The customer's phone and the terminal each hold a P-256 key generated in secure hardware. The ledger signs a short-lived identity assertion for each device, valid for 24 hours. A tap is a pair of signed statements, and money moves only when both verify against registered keys.

  • Payer key. Signs the payment statement (cx): amount, currency, both device fingerprints, a nonce, a timestamp, a sequence number and the collection reference.
  • Terminal key. Signs a binding to a one-time response key; the response key signs the acknowledgement (ack). The terminal also signs each batch it uploads.
  • Assertion key. Held by the ledger. Signs each device's 24-hour identity assertion, which the other device checks during the tap.

In this order, at settlement

  1. The terminal was enrolled, and not revoked, at the time of the tap.
  2. The batch is in sequence, chained to the previous one, and signed by the terminal.
  3. The pair has never been seen before.
  4. The amount was within the terminal's policy at the time of the tap, and the upload is within the settlement window.
  5. The payer's identity assertion was valid at the time of the tap, and signed by the ledger.
  6. The payment statement is signed by the asserted payer key.
  7. The response key is bound to this terminal, and the acknowledgement is signed by it.
  8. The ledger debits the payer's offline balance. If the balance is short, the tap is quarantined as a suspected double-spend and your loss policy applies.
Read the full protocol (opens docs site)

Limits, stated plainly

What offline does not do.

What offline payments do not do
Offline does not
No card-present offline. Offline taps are paid from a phone's offline balance, not from a bank card. Card payments at the POS need a network.
No taps between different ledger tenants. A terminal accepts payers from the payer base it was set up for. A phone whose balance was issued in another tenant is refused, never approximated.
No deposits without a merchant server online. Loading a customer's offline purse needs your server, because you take the customer's money first. A deposit is never queued offline.
No voucher tenders offline, yet. Vouchers can pay online today. Offline vouchers are planned. Coming

Cash deposits at an agent's POS are different: the agent's terminal signs them offline and they are credited when it reconnects. See Banks & agents.

Questions, answered.

How long can a terminal stay offline?

A terminal accepts taps for up to 24 hours after it last refreshed its policy; after that it stops accepting until it reconnects. Taps it holds must be uploaded within the settlement window in your policy, for example seven days, or they are refused at settlement. If a terminal holding taps stays silent longer than its policy allows, you are alerted.

What if the customer's phone is stolen?

The thief needs the customer's PIN to pay, and repeated wrong PINs lock it. The customer, or your support team, blocks the device: taps signed after the block fail at settlement and taps signed before it still settle. Without a fresh identity assertion, the phone cannot pay offline more than 24 hours after its last refresh. On a new phone, the remaining balance follows the customer.

Who pays the fee?

You do, as the merchant receiving the payment. The fee is calculated when the tap settles, not at the tap, and appears in your settlement report. If you choose PediWave-assured cover, a premium applies to your offline volume. Loading an offline balance may carry a load fee, shown to the customer before they confirm. See Pricing.

Can two customers pay each other?

Yes, if both use your app in payer mode. They tap phones, both keep the signed pair, and either can settle when back online. You can switch person-to-person payments off for any group of customers.

What hardware is supported?

Android devices that generate keys in secure hardware: StrongBox or a trusted execution environment (TEE). That covers modern Android phones, Android POS terminals and soft-POS. PediWave records each device's attestation level, and your underwriting can require hardware-backed keys. Devices without them can be accepted only at lower limits.

See offline in your sandbox.

Simulate taps, double-spends and revocations with test terminals.

Get a test key Talk to sales