HOW IT WORKS
Crunchfish’s offline payment approach is designed to deliver availability as a built-in part of the payment system, without increasing systemic risk, fragmenting settlement, or weakening governance. Offline capability is implemented as critical infrastructure, not as an exception or fallback mode. This is achieved by separating offline execution from online verification and settlement, enforcing risk limits locally at the point of execution, and verifying all offline activity centrally before settlement in the underlying payment system. As a result, offline payments remain fully integrated with existing ledgers, liquidity management, and regulatory controls.
Offline execution improves continuity and usability in everyday situations, such as environments with intermittent connectivity or latency constraints, while preserving predictable outcomes once the system synchronises.
Payments execute offline, settlement remains central.
Layer-2 Offline Architecture
The goverened offline capability is realised through a small set of offline components, each with a distinct role in execution, acceptance, and governance. Together, offline wallets, offline terminals, offline backend components, with offline protocols and APIs form a coherent Layer-2 capability that operates above the underlying payment system. Responsibilities are deliberately separated to allow offline payments to execute offline (layer-2), while risk control, verification, and settlement authority remain central in the underlying payment system (layer-1).
Offline Wallets
Offline wallets operate within isolated runtime environments, implemented using secure elements or virtual secure elements.
Trust is established through cryptographic verification and PKI. Offline interaction is agnostic to proximity method, including QR, NFC, BLE, or combinations.
Consecutive offline payments are supported within defined limits, using sequencing and expiry rules to prevent replay or double-spending.
Offline risk is enforced at the sending side.
Offline Terminals
Offline terminals are receive-only offline wallets used by merchants, agents, and payees in person-to-person for acceptance.
They verify incoming offline payment instructions and store them for later upload, enabling asymmetric acceptance at scale.
Acceptance scales through receive-only offline terminals.
Offline Backend
The offline solution includes multiple backend components that may be deployed at different levels, including the system-and service-level.
These backend components support onboarding, configuration, risk rule distribution, synchronization, verification, and certificate management.
These mechanisms are delivered as shared offline payment infrastructure that can be governed centrally and deployed consistently across payment ecosystems.
Reserve, Pay, and Settle
The offline components work together to support governed offline payments across their full lifecycle. Offline wallets and offline terminals handle execution and acceptance locally, while offline backend components coordinate synchronisation, verification, and conversion back into the underlying payment system once availability returns. The lifecycle that governs this process is expressed as Reserve, Pay, and Settle.
Reserve
Offline capability begins with reservations created in the underlying payment system. Funds remain held in regulated accounts and under the authority of the existing ledger.
The offline layer does not manage value; it manages the availability and update of offline spending limits derived from these reservations and synchronised to offline wallets through governed processes.
Offline spending is pre-funded by reservations.
Pay
Offline payments begin with a payment request initiated by the payee and presented to the payer.
The payer’s offline wallet evaluates the request, enforces locally held balance and risk rules, and generates a signed offline payment instruction if all conditions are satisfied.
Offline payments are only created after local balance checks.
Signed payment instructions are stored locally by both payer and payee, pending online synchronisation, verification and settlement.
Settle
When connectivity and system availability return, stored offline payment instructions are uploaded from offline wallets and offline terminals to the offline solution’s backend components.
These instructions are verified centrally before being converted into settlement transactions in the underlying payment system.
Settlement occurs only after verification, ensuring that offline execution does not bypass central control.
Settlement occurs only after online verification.
The architectural principles, security mechanisms, and intellectual property that underpin these mechanisms are further described in the Technology & IP section. Please click here for a visual introduction
Offline payments are executed under local enforcement, while verification and settlement remain under the authority of the underlying payment system.
Offline payments follow a Reserve–Pay–Settle lifecycle. Funds are reserved while systems are available, payments are executed offline under locally enforced limits, and settlement occurs only after verification when connectivity and system availability return.
