Design A Payment System Without Internet
Design a payment system that enables secure transactions without internet connectivity, using distributed authority mechanisms to avoid reliance on a single source of truth.
Asked at:
Apple
An offline digital payment network is a system that lets people pay merchants or peers even when neither party has internet connectivity, and later reconciles with issuers and banks when connectivity returns. Think of tap-to-pay systems that can work in airplane mode, stored-value transit cards, or mobile wallets exchanging signed value via NFC/QR—except designed to operate with distributed authority instead of a single central ledger. Interviewers ask this to see if you can design for extreme network partitions, prevent double-spend without a live authority, and reason about cryptography, risk, reconciliation, and consistency. It tests your ability to balance user experience (instant, offline payments) with security (tamper resistance, revocation), and to model multi-party settlement across issuers without a single source of truth.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to initiate and complete a payment when both payer and payee are offline, with immediate confirmation and a receipt for both parties.
Users should be able to view an accurate local balance and recent transactions offline, with safeguards that prevent overspending beyond risk limits.
Merchants should be able to validate payments offline using locally available credentials, policies, and revocation data, and accept or decline on the spot.
The system should reconcile and settle transactions across multiple issuers/authorities when connectivity resumes, without relying on a single source of truth.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
This is the crux of offline payments. Without a live central ledger, you must assume adversarial conditions and design local checks that bound risk until reconciliation. - Consider issuing “signed spendable tokens” or value blocks to the device’s secure element, with per-issuer quotas, velocity limits, and expirations so you cap exposure. - You could enforce merchant-side checks: deduplication windows, token serial validation, and local revocation lists, so a reused token is flagged before acceptance. - Think about tiered acceptance rules (e.g., small amounts allowed offline, higher amounts require more co-signatures or recent sync). Make the risk knobs adjustable by issuers.
The interviewer wants to see how you model multi-party trust. Distributed authority means no single ledger decides; instead, issuers co-validate value and revocations. - You could use multi-issuer provisioning: devices receive value endorsed by a quorum (e.g., 2-of-N issuers), so any one party’s outage doesn’t halt payments. - Consider threshold signatures or multi-signature certificates on value blocks and keys, plus independent revocation channels per issuer to decentralize control. - Define a federation/clearing model: issuers publish transaction claims and revocations to a shared log and reconcile via deterministic rules when back online.
Reconciliation turns offline receipts into settled ledger entries and resolves conflicts. Interviewers look for idempotency, ordering guarantees, and clear dispute handling. - You could model each offline payment as an immutable event with unique IDs and proofs; on reconnect, ingest into an append-only log and apply idempotent settlement. - Define deterministic conflict rules: token serials are single-use; first-seen by a quorum wins; late duplicates are rejected or clawed back per policy. - Plan for long-running workflows: chargebacks, revocations, and partial settlements handled via sagas with compensating actions instead of brittle distributed transactions.
Offline security relies on strong key management and timely revocation, even when you can’t dial home. Interviewers expect a practical path to mitigate stolen devices and fraud. - You could provision keys into a secure element, require local biometric/PIN, and rotate short-lived spending certificates that expire quickly to bound exposure. - Maintain compact revocation data structures (e.g., Bloom filters plus periodic CRL deltas) that merchants refresh when online and can enforce offline. - Consider risk-aware policies (lower limits after long offline periods, require recent sync for high-value payments) to reduce impact of outdated revocation data.
Relevant Patterns
Relevant patterns that you should know for this question
Offline payments inherently split into issuance, local transfer, and later settlement. Using sagas/durable workflows lets you orchestrate reconciliation, chargebacks, and revocations with compensations instead of fragile distributed transactions.
Double-spend is a contention problem over the same value token. You need idempotent operations, deduplication windows, and first-writer-wins rules to safely handle conflicting claims when multiple parties present the same value.
Fraud review, dispute resolution, and issuer settlement can take minutes to days. Treat them as durable, retryable, observable tasks rather than synchronous calls, so the system remains robust through outages and retries.
Relevant Technologies
Relevant technologies that could be used to solve this question
Each issuer still needs an ACID-compliant ledger for settled balances and disputes. PostgreSQL is a widely expected choice in interviews for financial correctness, transactional integrity, and rich SQL for reconciliation reporting.
Similar Problems to Practice
Related problems to practice for this question
Both require secure transaction flows, ledgers, idempotency, and reconciliation/settlement. The offline variant adds partition tolerance and double-spend controls, but many core payment primitives are shared.
Clients operate offline, create updates, and later sync to a distributed backend that resolves conflicts deterministically. Replace files with payment events and you have a similar sync-and-merge problem.
Preventing overspend offline is analogous to enforcing distributed quotas and velocity limits. Techniques like token buckets, deduplication, and time-bounded counters help cap risk until global state is reconciled.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Relying on a central online ledger for authorization
This violates the offline constraint and the requirement to avoid a single source of truth. If your design needs a real-time central check, it will fail during partitions—the exact scenario the system must support.
Handwaving double-spend prevention
Assuming users will not attempt reuse of value without concrete mechanisms (signed tokens, serials, quotas, expirations, dedup) is a critical security gap. It leads to unbounded financial risk for issuers and merchants.
No plan for key management and revocation in offline mode
Without secure element storage, short-lived spending keys, and offline-enforceable revocation data, a stolen device can drain funds. This is a foundational security requirement for any offline payment design.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid September, 2024
Apple
Senior
Design a payment system that would work even if the internet was unavailable, focusing on security, distributed authority, and avoiding a single source of truth
Your account is free and you can post anonymously if you choose.