All 66 sections of the NexPay transaction process specification: how online and offline payments work, how they differ, and how they synchronize back into one authoritative ledger.
NexPay supports two transaction modes:
The user experience should be similar:
Select recipient → Enter amount → Authenticate → Confirm → Receipt
However, the underlying transaction architecture is significantly different.
An online transaction is a transaction where the sender's device can communicate with NexPay's backend infrastructure during the payment process.
The server can therefore participate in:
Scenario: Jitesh wants to send Rs. 500 to Rahul. Jitesh has Rs. 10,000 available. Both phones have internet access.
Jitesh opens NexPay
↓
Taps SEND
↓
Selects Rahul
↓
Enters Rs. 500
↓
NexPay contacts server
↓
Server verifies account
↓
Server verifies balance
↓
Server verifies transaction limits
↓
Risk checks
↓
Jitesh authenticates
↓
Transaction is created
↓
Server records transaction
↓
Wallet balances updated
↓
Rahul receives confirmation
↓
SUCCESS
Step 1 — User Authentication. Jitesh is already logged in. The app verifies the session/device. For sensitive transactions, NexPay may require biometrics, PIN, or additional verification.
Step 2 — Recipient Selection. Jitesh selects Rahul. The app verifies that Rahul corresponds to the intended NexPay account/device identity.
Step 3 — Amount. Jitesh enters Rs. 500. The application performs basic validation.
Step 4 — Server Request. The app sends a transaction request to the NexPay backend. Conceptually:
Sender: Jitesh Recipient: Rahul Amount: Rs. 500 Currency: NPR Device: Jitesh's trusted device Transaction Request ID: unique Timestamp: current time
Account: Is sender authenticated? Is the account active? Is the recipient valid?
Wallet: Is sufficient balance available? Is the account restricted? Are transaction limits satisfied?
Security: Is the device trusted? Is the request authentic? Has the request already been processed?
Risk: Is this transaction suspicious? Does it require additional verification?
Before:
Jitesh Balance = Rs. 10,000
Transaction: Send = Rs. 500
After successful settlement:
Jitesh Balance = Rs. 9,500 Rahul Balance = Previous Balance + Rs. 500
The user sees:
✓ Payment Successful Rs. 500 To Rahul Status: Settled Transaction ID: NPX-XXXXXXXX [Done]
Where "Settled" means the server has successfully processed the transaction according to the system's settlement rules.
SENDER
│
↓
NexPay Mobile App
│
HTTPS / API
│
↓
API Gateway
│
┌────────┼────────┐
↓ ↓ ↓
Auth Wallet Risk
│ │ │
└────────┼────────┘
↓
Transaction
Service
│
↓
Database
│
↓
Settlement
│
┌─────┴─────┐
↓ ↓
Sender Receiver
An offline transaction is a transaction where the sender cannot reach NexPay's backend at the moment the transaction is initiated.
Instead of requiring immediate server communication, NexPay uses locally available:
The transaction is stored locally and later synchronized with the server.
Offline does NOT mean "the server is unnecessary." It means "the server does not need to participate immediately."
The server remains important for:
Before a user can make offline payments, the system must establish an Offline Reserve.
Total wallet balance: Rs. 10,000 Maximum Offline Reserve: 50% Maximum permitted reserve: Rs. 5,000
If the user chooses Offline Reserve: Rs. 3,000, then:
Online/normal balance: Rs. 7,000 Offline Reserve: Rs. 3,000
The 50% rule is a risk-control mechanism. If a user has Rs. 10,000, NexPay should not permit the entire amount to become exposed to unresolved offline transactions.
Maximum Rs. 5,000 can be designated as Offline Reserve. This limits potential exposure while the offline transaction graph is not yet reconciled by the server.
Scenario: Jitesh has Total wallet balance = Rs. 10,000 and Offline Reserve = Rs. 3,000. Jitesh wants to pay Rahul Rs. 500. Both devices have no internet.
Jitesh opens NexPay
↓
Taps SEND
↓
Selects Rahul
↓
Enters Rs. 500
↓
NexPay detects no internet
↓
Offline eligibility check
↓
Offline Reserve check
↓
Nearby device / QR communication
↓
Receiver verification
↓
Transaction package creation
↓
Hash generation
↓
Digital signature
↓
Receiver verifies proof
↓
Two-Phase Commit
↓
Local transaction record
↓
Payment locally confirmed
↓
Pending Synchronization
The app detects that the backend cannot currently be reached.
🟠 Offline Mode Internet unavailable. Eligible offline payments may still be available.
Before allowing payment, NexPay checks locally:
✓ User authenticated ✓ Device trusted ✓ Offline Reserve available ✓ Amount within limits ✓ Transaction TTL valid ✓ Required transaction evidence available ✓ Protocol version compatible ✓ Receiver compatible
If any mandatory condition fails:
Offline payment unavailable. Please connect to the internet to synchronize your wallet.
Possible mechanisms include:
QR: Sender scans receiver QR.
Nearby communication: Compatible devices discover each other. Possible transports: Bluetooth Low Energy, NFC, Wi-Fi Direct.
The sender should see:
Pay Rahul ✓ Verified NexPay account ✓ Compatible device ✓ Secure connection Amount: Rs. 500
The receiver should also see who is paying.
NexPay constructs a transaction package containing the information required by the protocol. Conceptually:
Transaction ID Sender identity reference Receiver identity reference Amount Currency Timestamp Protocol version Previous transaction references Transaction state Expiration/TTL Cryptographic metadata Digital signature
A canonical transaction representation is hashed. Conceptually:
Transaction Data
↓
Canonical Encoding
↓
Cryptographic Hash
↓
Transaction Hash
Transaction Hash: 9a7c...42ef
The sender's device signs the transaction using its protected private key. Conceptually:
Transaction Hash
↓
Private Key
↓
Digital Signature
The receiver can then verify the signature using the corresponding public key.
Receiver verifies:
✓ Signature valid ✓ Transaction hash valid ✓ Sender identity valid ✓ Amount valid ✓ Transaction not expired ✓ Protocol version supported ✓ Required transaction evidence valid
If verification fails:
Payment could not be verified. No payment was committed.
NexPay can use a two-stage local transaction process to avoid inconsistent states between sender and receiver. Conceptually:
Phase 1 — Prepare: Both sides verify the transaction and prepare their local state.
Sender: READY Receiver: READY
Phase 2 — Commit: Both sides commit the transaction locally.
Sender: COMMITTED Receiver: COMMITTED
After successful local commit, the transaction evidence is securely stored on both devices.
Transaction: NPX-7F82A91C Amount: Rs. 500 State: Pending Synchronization
Sender:
✓ Payment Sent Rs. 500 To Rahul Offline Payment Pending Synchronization
Receiver:
✓ Payment Received + Rs. 500 From Jitesh Offline Payment Pending Synchronization
An offline transaction has not yet been reconciled against the authoritative server state. Therefore:
BAD: Settled
Better: Locally Verified · Pending Synchronization
After successful server reconciliation:
Server Verified → Settled
NexPay maintains bounded transaction history/proof links. Current design: up to 10 previous transaction links.
Transaction 101
↓
Transaction 102
↓
Transaction 103
↓
...
↓
Transaction 110
↓
Current Transaction
These references provide additional evidence for verification.
A device cannot know future transactions that have not happened yet. Therefore NexPay should NOT attempt to verify future transfers at transaction creation time. Instead:
Offline devices produce:
A → B B → C C → D D → E
After synchronization, the server receives the records and reconstructs:
A ↓ B ↓ C ↓ D ↓ E
It can then examine whether the history is consistent.
Potential signals include:
When internet becomes available:
Internet Restored
↓
Authentication
↓
Sync Manager
↓
Upload Offline Records
↓
Signature Verification
↓
Hash Verification
↓
Transaction Graph Reconstruction
↓
Conflict Detection
↓
Risk Analysis
↓
Ledger Reconciliation
↓
Settlement
Jitesh made three offline transactions:
1. Rs. 500 → Rahul 2. Rs. 200 → Suman 3. Rs. 300 → Amit
Internet returns. NexPay displays:
Synchronizing 3 offline transactions found ✓ Transaction 1 verified ✓ Transaction 2 verified ✓ Transaction 3 verified ✓ Transaction relationships reconstructed ✓ No conflicts detected Synchronization Complete
| Category | Online | Offline |
|---|---|---|
| Internet | Required during transaction | Not required during eligible local transaction |
| Server | Immediately reachable | Temporarily unavailable |
| Balance validation | Server | Pre-authorized local reserve + protocol rules |
| Fraud analysis | Immediate / server-side | Deferred + local checks |
| Settlement | Immediate / near-real-time | After synchronization |
| Transaction storage | Server + local cache as needed | Local first |
| Communication | Internet / API | Nearby / local communication |
| Risk | Lower uncertainty | Higher uncertainty |
| Reserve | Normal wallet state | Offline Reserve required |
| Synchronization | Usually immediate | Required later |
| Conflict detection | Immediate | Often deferred |
| Transaction graph | Server authoritative state | Local bounded evidence + later reconstruction |
| User status | Settled / processed | Pending synchronization initially |
| Failure handling | Server reconciliation | Local protocol recovery + later reconciliation |
T0 User initiates payment T1 Server validates T2 Authentication T3 Transaction created T4 Server commits T5 Receiver notified T6 Settlement completed
T0 User initiates payment
T1 Offline eligibility check
T2 Peer connection
T3 Transaction created
T4 Hash generated
T5 Signature generated
T6 Receiver verifies
T7 Local commit
T8 Transaction stored locally
... TIME PASSES ...
T9 Internet returns
T10 Synchronization
T11 Server verification
T12 Graph reconstruction
T13 Risk/conflict analysis
T14 Settlement
Online — user sees:
Send ↓ Confirm ↓ ✓ Payment Successful
Offline — user sees:
Send ↓ Confirm ↓ ✓ Payment Successful Pending Synchronization
The difference should be understandable without exposing protocol complexity.
Online: The server can immediately verify:
Account Balance Transaction Risk State
Offline: The device must rely on:
Trusted Device Offline Reserve Cryptographic Keys Transaction Evidence Protocol Rules Peer Verification
and the server verifies everything possible after synchronization.
The system must safely determine the transaction state. Possible states:
Checking transaction status... Please wait.
The transaction state must survive application restart. The app should securely persist the required transaction state.
Recovering payment state... ✓ Transaction state recovered Status: Pending Synchronization
Same principle. The transaction protocol must define durable state transitions.
Pending transaction detected. [ Review ] [ Synchronize ]
If the transaction has not reached the required commit state:
Payment not completed. No successful transfer was recorded.
If it has reached a committed state: the protocol must recover deterministically rather than allowing the sender to blindly retry.
Every transaction requires a unique identifier and idempotent server processing.
If the server receives the same transaction again:
Existing transaction detected. Duplicate request ignored.
If the same identifier contains different content:
Transaction conflict detected. Transaction placed under security review.
Changing transaction data should cause cryptographic verification failure.
Original:
Amount = Rs. 500
Tampered:
Amount = Rs. 5,000
The canonical transaction hash/signature should no longer match. Result:
✕ Transaction verification failed
Offline transactions must have a configurable TTL.
Transaction created: 1 Aug TTL: 30 days Expiration: 31 Aug
After expiration:
Offline transaction expired. Connect to the internet to synchronize.
Offline payments unavailable. Offline Reserve: Rs. 0 Connect to the internet to restore/synchronize offline capability.
Example: Offline Reserve: Rs. 1,000 and Payment: Rs. 1,500.
Offline payment unavailable. Available Offline: Rs. 1,000 Required: Rs. 1,500
If internet is available, the app may attempt the normal online payment flow.
Internet available
↓
User begins payment
↓
Connection disappears
↓
NexPay checks transaction state
↓
If not committed:
switch to eligible offline flow
Offline ↓ Payment recorded ↓ Internet returns ↓ Sync starts ↓ Server verifies ↓ Status updated
A transaction can conceptually move through:
CREATED ↓ PREPARED ↓ LOCALLY_VERIFIED ↓ COMMITTED ↓ PENDING_SYNC ↓ SYNCING ↓ SERVER_VERIFIED ↓ SETTLED
Failure states:
REJECTED EXPIRED CANCELLED CONFLICT UNDER_REVIEW
Online: Trust is anchored heavily in:
Server + Authenticated Client + Secure Communication
Offline: Trust is distributed temporarily across:
Trusted Device + Protected Keys + Offline Reserve + Cryptographic Proof + Peer Verification + Transaction Evidence
Then eventually returns to:
Server + Complete Transaction History
Online advantages:
Offline advantages:
Online main dependency:
Network connectivity.
Offline main challenge:
The server cannot immediately observe every transaction.
Therefore offline architecture requires additional controls.
NexPay should NOT attempt to make everything offline.
Use:
Normal situation
↓
ONLINE
and:
Connectivity unavailable
↓
OFFLINE
This produces a hybrid architecture.
NEXPAY
│
┌────────┴────────┐
↓ ↓
ONLINE OFFLINE
│ │
Server Local
Ledger Protocol
│ │
│ Peer Verification
│ │
│ Local Commit
│ │
└────────┬────────┘
↓
Synchronization
↓
Server Reconciliation
↓
Settlement
The offline engine should be a separate module. Recommended architecture:
NexPay App │ ├── Authentication ├── Wallet ├── Payments │ ├── OnlinePaymentEngine │ └── OfflinePaymentEngine │ ├── QR ├── DeviceCommunication ├── Cryptography ├── LocalStorage ├── Synchronization └── UI
The backend:
NexPay Backend │ ├── Authentication Service ├── Wallet Service ├── Transaction Service ├── Offline Sync Service ├── Graph/Reconciliation Service ├── Risk Engine ├── Fraud Detection ├── Settlement └── Audit Service
A normal user should not need to decide "Should I use online or offline?" Instead:
Payment Mode Automatic
NexPay determines the appropriate pathway.
For technical transparency:
Payment Details Mode: OFFLINE Local Verification: ✓ Cryptographic Proof: ✓ Peer Verification: ✓ Local Commit: ✓ Server Synchronization: Pending
Jitesh
Balance = Rs. 10,000
↓
Send Rs. 500 to Rahul
↓
Internet available
↓
Server validates balance
↓
Authentication
↓
Risk check
↓
Transaction created
↓
Ledger updated
↓
Jitesh: Rs. 9,500
Rahul: + Rs. 500
↓
Status:
SETTLED
Jitesh
Total Balance = Rs. 10,000
Offline Reserve = Rs. 3,000
↓
Internet unavailable
↓
Send Rs. 500 to Rahul
↓
Offline eligibility
✓ Trusted device
✓ Valid reserve
✓ Valid transaction
✓ Valid TTL
↓
Peer connection
↓
Receiver verification
↓
Secure Transaction Package
↓
Hash
↓
Digital Signature
↓
Receiver verifies
↓
Two-Phase Commit
↓
Local storage
↓
Payment successful
Status:
PENDING SYNCHRONIZATION
...
Internet returns
↓
Upload records
↓
Verify signatures
↓
Verify hashes
↓
Reconstruct transaction graph
↓
Risk analysis
↓
Conflict detection
↓
Server reconciliation
↓
SETTLEMENT
The most important distinction is:
Online payment relies on immediate server participation.
while:
Offline payment temporarily relies on pre-authorized local value, trusted devices, cryptographic evidence, peer verification, and later server reconciliation.
Do NOT publicly claim:
Instead:
"NexPay uses a layered offline transaction architecture designed to limit exposure, provide cryptographically verifiable transaction evidence, detect conflicting transaction histories, and reconcile offline activity when connectivity returns."
NexPay works online when connectivity is available and can continue eligible payments offline when it isn't. Offline transactions are locally verified using trusted device credentials, reserved funds, and cryptographic transaction evidence. Once connectivity returns, NexPay synchronizes the records with its backend, reconstructs transaction relationships, performs additional verification and risk checks, and reconciles the transactions with the authoritative ledger.
"NexPay is a hybrid payment architecture. Online transactions are validated and settled through the server in real time. When connectivity is unavailable, eligible users can use a controlled Offline Reserve. The sender and receiver exchange and verify a cryptographically protected transaction locally. The transaction is stored as pending synchronization. Once connectivity returns, the server verifies the cryptographic evidence, reconstructs the broader transaction graph, checks for conflicts and fraud, and then reconciles the transaction."
"The key difference between NexPay's online and offline modes is where verification happens and when the server participates. In online mode, the server is available during the transaction, so it can validate the wallet balance, transaction limits, account state, risk, and ledger state immediately.
In offline mode, the server isn't reachable. Therefore NexPay cannot simply trust a client-side balance. Instead, the system uses an Offline Reserve that is established while the wallet is synchronized. The current design limits that reserve to a maximum of 50% of the wallet balance.
When two users make an eligible offline transaction, their devices establish a local communication channel, authenticate the participants, create a secure transaction package, hash and digitally sign the transaction, verify the receiver-side evidence, and commit the transaction locally according to the protocol.
The transaction is then marked as pending synchronization rather than immediately claiming server settlement. When internet connectivity returns, the devices upload their records. The server verifies signatures and hashes, reconstructs the broader transaction graph from the uploaded transaction records, detects conflicts or suspicious histories, performs risk analysis, and reconciles the transaction with the authoritative ledger.
So NexPay isn't trying to eliminate the server. It's moving part of the transaction process to the edge temporarily and then bringing the transaction history back to the server for reconciliation."
NexPay is best understood as:
NEXPAY
│
┌───────────┴───────────┐
│ │
ONLINE OFFLINE
│ │
Server-first Device-first
validation temporary validation
│ │
└───────────┬───────────┘
↓
SYNCHRONIZATION
↓
RECONCILIATION
↓
SETTLEMENT
See how every process decision translates into the product — all 62 product & UX questions answered.
Read the complete product Q&A Why NexPay exists Back to the homepage