The complete NexPay Q&A

NexPay is an offline-first digital payment application that allows verified users to send and receive digital value even when internet connectivity is unavailable.

The user experience should remain simple:

Select recipient → Enter amount → Authenticate → Confirm → Payment completed locally.

The complexity of cryptographic verification, Secure Transaction Packages, Chain of Custody, synchronization, risk analysis, and server settlement must remain mostly invisible to ordinary users.

No. Users should NOT need to understand:

• STPs
• hashes
• digital signatures
• transaction graphs
• public/private keys
• Chain of Custody
• Two-Phase Commit
• synchronization internals

These belong in advanced transaction details and developer/security documentation. The normal user should experience NexPay like a conventional payment app.

For a normal user:

OPEN APP → SEE BALANCE → SEND / RECEIVE → SELECT PERSON → ENTER AMOUNT → AUTHENTICATE → CONFIRM → ✓ DONE

For the backend:

Authentication → Device Trust → Offline Reserve Validation → Transaction Construction → STP Generation → Hash → Digital Signature → Peer Verification → Two-Phase Commit → Local Storage → Pending Synchronization → Server Upload → Graph Reconstruction → Cryptographic Verification → Risk Analysis → Conflict Detection → Settlement

The first flow is what the user sees. The second flow is what NexPay does.

NexPay must follow this rule:

1. Do not invent contradictory behavior.
2. Follow this specification as the UX source of truth.
3. Follow the NexPay Offline Payment Protocol specification for protocol behavior.
4. Keep business logic separate from UI.
5. Never implement financial logic only on the client.
6. Never treat client-side data as inherently trustworthy.
7. Implement proper cryptographic libraries rather than custom cryptography.
8. Write unit, integration, and end-to-end tests.
9. Handle every loading, success, failure, offline, synchronization, and conflict state.
10. Never use fake payment success in production logic.
11. Clearly distinguish Locally Verified, Pending Synchronization, Server Verified and Settled.
12. Make every critical financial operation idempotent.
13. Maintain complete auditability.
14. Protect private cryptographic keys using platform secure storage where available.
15. Make the system modular so the offline protocol can evolve without rewriting the UI.

The NexPay app is not considered complete merely because the screens exist. A feature is complete only when:

• UI exists.
• Backend exists where required.
• Database behavior exists where required.
• Security validation exists.
• Offline behavior is handled.
• Online behavior is handled.
• Error states are handled.
• Loading states are handled.
• Authentication is handled.
• Synchronization is handled.
• Tests exist.
• Accessibility is considered.
• Logging exists.
• Auditability exists.
• Documentation exists.
• The feature works on a real device where applicable.

When a user performs Send Rs. 500, the system must always be able to answer:

1. Who sent it?
2. Who received it?
3. How much was transferred?
4. When was it created?
5. Which device created it?
6. Was the sender authenticated?
7. Was the receiver verified?
8. Was the transaction cryptographically signed?
9. Was the transaction locally committed?
10. Has it synchronized?
11. Has it been server-verified?
12. Has it settled?
13. What transaction came before it?
14. What transaction came after it?
15. Is there any conflicting evidence?

This traceability is fundamental to NexPay.

The home screen must immediately show:

1. Total wallet balance
2. Available balance
3. Offline Reserve
4. Current connectivity state
5. Send button
6. Receive button
7. Scan QR button
8. Recent transactions
9. Synchronization status
10. Security/device status when relevant

NexPay                         🔔 👤

Total Balance
Rs. 12,500.00

Available
Rs. 10,000.00

Offline Reserve
Rs. 2,500.00
━━━━━━━━━━━━━━━━━━
50% maximum

        SEND        RECEIVE

          [ SCAN QR ]

Recent Activity
────────────────────────
↓ Rahul       - Rs. 500
↑ Suman       + Rs. 1,000

Home   Activity   Wallet   Profile

Show a small status indicator.

Online:

🟢 Connected

Offline:

🟠 Offline Mode

When offline, display:

Offline Mode

You can continue making eligible
payments using your Offline Reserve.

Available Offline:
Rs. 2,000

The wallet must clearly separate:

Total Balance
Rs. 12,500

Online Balance
Rs. 10,000

Offline Reserve
Rs. 2,500

Yes.

Offline Reserve

Current
Rs. 2,500

Maximum
Rs. 6,250

Amount to Reserve

Rs. [ 4,000 ]

[ Update Reserve ]

This operation requires synchronization with the server.

Yes. Users can choose:

Offline Reserve

Auto Refresh
ON

Target:
○ Fixed Amount
● Percentage

Target:
50%

Wallet

Total Balance
Rs. 12,500

Online
Rs. 10,000

Offline Reserve
Rs. 2,500

────────────────

Offline Reserve

Current:
Rs. 2,500

Maximum:
Rs. 6,250

[ Manage ]

────────────────

[ Add Money ]

[ Withdraw ]

[ Bank Accounts ]

Profile

Jitesh
@nexpay_user

✓ Verified Account

Account
Security
Devices
KYC
Notifications
Privacy
Limits
Help & Support
About NexPay

Primary:

SEND
RECEIVE
SCAN

Secondary:

Wallet
Activity

The primary flow is:

Home
 ↓
Send
 ↓
Select recipient
 ↓
Enter amount
 ↓
Select/confirm payment method
 ↓
Review
 ↓
Authenticate
 ↓
Local verification
 ↓
Payment confirmation

Support four methods:

Method A — QR: Sender taps Scan QR and scans the recipient's NexPay QR.

Method B — Nearby Device: Sender taps Nearby. NexPay searches for nearby compatible NexPay devices.

Method C — Contacts: For online transactions, the sender can select a registered contact.

Method D — NexPay ID: The sender can manually enter a NexPay username/ID where online connectivity allows verification.

Example: Alice wants to pay Bob. Both phones have no internet.

Send
 ↓
Nearby
 ↓
Searching...

The app displays:

Nearby NexPay Users

👤 Bob
   Verified NexPay User
   Nearby

[ Connect ]

The implementation may use an appropriate supported local communication mechanism such as Bluetooth Low Energy, NFC, Wi-Fi Direct, or QR-assisted pairing. The final transport must be determined according to platform capabilities and security requirements.

Before payment, show:

Pay Bob

✓ Verified NexPay Account
✓ Trusted Device

Bob
@bob123

[ Continue ]

Pay Bob

Rs.

[ 500.00 ]

Available:
Rs. 2,000.00

Payment Mode:
Automatic

[ Continue ]

The amount must be validated before proceeding. Reject:

• Zero
• Negative values
• Values exceeding available offline funds
• Values exceeding transaction limits
• Invalid currency amounts

Normally, no. Use Payment Mode: Automatic. NexPay determines whether the transaction should use the online or offline pathway.

If internet is available:

Online Payment

If internet is unavailable and the transaction satisfies all offline conditions:

Offline Payment

Advanced users may optionally view the selected mode.

The application must verify locally that:

• User is authenticated.
• Device is trusted.
• Offline Reserve is available.
• Requested amount is within offline limits.
• Offline Reserve has not expired.
• Device security requirements are satisfied.
• Sender's offline funds are valid.
• Required transaction history/proofs are available.
• Receiver is compatible.
• Protocol version is supported.
• Transaction has not already been committed.

If any critical condition fails:

Payment unavailable offline.

Please connect to the internet
to synchronize your wallet.

Confirm Payment

Rs. 500.00

To
Bob

Payment Method
OFFLINE

Available Offline
Rs. 2,000.00

After Payment
Rs. 1,500.00

────────────────

[ Confirm & Pay ]

Use adaptive authentication.

• Low-risk transactions: Fingerprint, Face authentication, or NexPay PIN fallback.
• Higher-risk transactions: Biometrics or NexPay PIN.
• Very high-risk transactions: Require online verification according to configured policy.

The UI can show:

Securing Payment...

✓ Sender authenticated
✓ Receiver verified
✓ Funds verified
✓ Transaction secured
✓ Payment committed

Internally:

1. Create transaction.
2. Generate Transaction ID.
3. Construct Secure Transaction Package.
4. Attach relevant transaction references.
5. Generate cryptographic hash.
6. Sign the transaction.
7. Exchange required proof with receiver.
8. Receiver verifies the transaction.
9. Execute Two-Phase Commit.
10. Update sender state.
11. Update receiver state.
12. Store transaction locally.
13. Mark transaction as Pending Synchronization.

             ✓

       Payment Sent

          Rs. 500

            to
           Bob

────────────────────

Offline Payment

Status:
Pending Synchronization

Transaction ID:
NPX-7F82...A91C

────────────────────

[ Done ]

[ View Details ]

Home → [ RECEIVE ] opens:

Receive Money

Your NexPay ID

@jitesh

        [ QR CODE ]

[ Request Amount ]

[ Show QR ]

[ Nearby ]

The receiver displays a NexPay QR. The QR should contain only the information required for secure identification/payment initiation.

┌────────────────────┐
│       QR CODE      │
│      JITESH        │
└────────────────────┘

Jitesh
@nexpay_user

[ Share ]

Yes.

Request Money

Amount

Rs. [ 500 ]

Optional Note

[ Lunch ]

[ Generate Request ]

The app generates a payment request/QR. The sender scans it.

Payment Incoming

Bob is sending you

Rs. 500.00

✓ Sender verified
✓ Transaction verified
✓ Cryptographic proof verified

[ Accept ]

[ Decline ]

             ✓

      Payment Received

          + Rs. 500

            From
           Bob

────────────────────

Offline Payment

Pending Synchronization

[ Done ]

[ View Details ]

Receive
 ↓
Show QR
 ↓
Sender scans
 ↓
Incoming payment
 ↓
Verify sender
 ↓
Accept
 ↓
Authentication if required
 ↓
Payment received
 ↓
Pending synchronization

Preparing
Awaiting Acceptance
Committing
Pending Synchronization
Synchronizing
Verified
Settled
Archived

The user-facing labels may be simplified — e.g. Pending Synchronization rather than STP awaiting server reconciliation.

Activity

Today

↓ Bob
Sent
-Rs. 500
Offline • Pending Sync

↑ Suman
Received
+Rs. 1,000
Online • Settled

Yesterday

↓ Rahul
Sent
-Rs. 250
Online • Settled

Filters:

All · Sent · Received · Online · Offline · Pending · Settled · Failed

Normal section:

Payment Details

Amount        Rs. 500
Type          Sent
Recipient     Bob
Date          13 Aug 2026
Method        Offline
Status        Pending Synchronization
Transaction ID  NPX-...

Advanced section:

Security Details

✓ Digital Signature
✓ Hash Verified
✓ Device Verified
✓ Chain Verified
✓ Authentication Verified

Chain of Custody

Previous verified links: 10

[ View Verification Details ]

NexPay

Payment Receipt

Status:        Pending Synchronization
Amount:        Rs. 500
From:          Jitesh
To:            Bob
Date:          13 Aug 2026 20:30
Transaction ID: NPX-XXXXXXXX
Payment Method: Offline
Verification:  Locally Verified

Yes. Generate a receipt that contains safe information.

Internet Connected

Synchronizing...

3 offline transactions found

✓ Transaction 1 verified
✓ Transaction 2 verified
✓ Transaction 3 verified

✓ Transaction graph reconstructed
✓ Security checks completed
✓ Wallet synchronized

Then:

Synchronization Complete

3 transactions processed

Rs. 1,250

Your wallet is up to date.

[ Done ]

Only after the server successfully:

• Receives the transaction.
• Verifies signatures.
• Verifies hashes.
• Reconstructs transaction relationships.
• Detects conflicts.
• Performs risk analysis.
• Validates the transaction against server state.
• Completes settlement.

Normal users should see:

Payment Verification

✓ Transaction verified

Ownership history:
Bob → Jitesh

10 previous verified links available

Advanced users can expand:

Transaction Graph

A
 ↓
B
 ↓
C
 ↓
D
 ↓
Current Owner

The device maintains up to 10 previous transaction links as defined by the protocol. The server reconstructs the complete transaction graph after synchronization.

No. The system must NOT claim that fraud is mathematically impossible. Instead:

The server remains responsible for final reconciliation.

The transaction becomes ineligible for further offline circulation.

Offline Transaction Expired

This offline payment can no longer
be used for another offline transfer.

Connect to the internet to synchronize
your wallet.

[ Synchronize ]

Default TTL currently specified: 30 days. The TTL must remain configurable by server policy.

Block the payment. Do NOT allow one final offline transaction.

Payment Unavailable Offline

Your offline funds require synchronization.

Connect to the internet and try again.

Your existing balance has not been lost.

[ Connect & Synchronize ]

Payment Limits

Daily Online Limit
Rs. XX,XXX

Daily Offline Limit
Rs. X,XXX

Maximum Offline Reserve
50% of wallet balance

Actual limits should be configurable by policy.

Normally, no. Do not display Risk Score: 73/100 unless there is a legitimate product reason. Instead show actionable messages:

Additional verification required.

This payment requires stronger
security verification.

Additional Verification Required

For your security, this payment
requires additional verification.

[ Continue Verification ]

[ Cancel ]

For critical risk:

Offline Payment Unavailable

This transaction requires online
verification.

Connect to the internet to continue.

Absolutely not. Never put private keys, passwords, authentication secrets, or sensitive personal information inside QR codes.

Never expose internal technical errors to normal users.

Bad: STP_HASH_MISMATCH_ERR_409

Good:

Payment could not be securely verified.

No money was transferred.

Technical information can be available under Technical Details for debugging/support.

Never:

• Display private keys.
• Ask users to manually copy private keys.
• Store PINs in plaintext.
• Display sensitive cryptographic secrets.
• Claim an offline transaction is server-settled before synchronization.
• Hide important security warnings.
• Automatically retry an uncertain financial transaction without reconciliation.

The recovery flow is:

1. User signs in on a new device.
2. User completes identity verification.
3. Server revokes old device.
4. Old device public key is revoked.
5. New device generates a new key pair.
6. Online wallet is restored.
7. Old device Offline Reserve is invalidated.
8. New Offline Reserve can be created after synchronization.

Devices

This Device
✓ Trusted
Android
Last synchronized: Today

Other Device
Trusted
Last active: Yesterday

[ Revoke Device ]

Merchant opens:

Merchant Mode

Today's Sales
Rs. 25,500

[ Receive Payment ]

[ Generate QR ]

[ Transactions ]

For a customer payment:

Enter Amount

Rs. [ 500 ]

[ Generate Payment QR ]

Customer scans it. If supported offline:

Offline Payment

✓ Customer verified
✓ Payment proof received
✓ Transaction committed

Rs. 500

Pending Synchronization

Do not simply edit the original transaction. Create a new cryptographically linked refund transaction.

Original Payment
Rs. 500
      ↓
Refund
+ Rs. 500

The refund should have its own Transaction ID.

The user-facing UI should not expose unnecessary technical information.

Transaction Requires Review

We could not automatically verify
this transaction.

Your account is protected while
we investigate the transaction.

[ View Details ]

[ Contact Support ]

The backend should preserve all evidence.

Payment Failed

No money was transferred.

Your balance has not changed.

[ Try Again ]

NexPay must determine whether the transaction was committed. Never blindly retry.

Checking Payment Status...

Please wait.

• If committed → show success.
• If not committed → allow retry.
• If uncertain → reconcile with server before creating another transaction.

If both transaction records are identical:

Duplicate record detected.

Existing transaction retained.

If the same Transaction ID contains different content:

Security verification required.

The transaction could not be reconciled
automatically.

Include:

• NexPay PIN
• Biometrics
• Device management
• Trusted devices
• Login sessions
• Security notifications
• Transaction authentication
• Recovery options

Payment Sent
Rs. 500 sent to Bob

Payment Received
Rs. 1,000 received from Suman

Synchronization Complete
3 offline transactions verified.

Security Alert
A new device was added to your account.

Local notifications can work offline:

Offline payment recorded.

Pending synchronization.

Server-dependent notifications require connectivity.

The app should support:

• Screen readers
• Large text
• High contrast
• Keyboard/accessibility navigation where applicable
• Clear labels
• Non-color-only status indicators
• Haptic feedback where appropriate

Architecture should support localization from the beginning. Initial languages may include English and Nepali. Future languages can be added without redesigning the application.