Unit 3.
Case Study: Mobile-First Payments – eSewa & Khalti Infrastructure Choices
Learning Objectives
By the end of this case study, you will be able to:
- ✅ Analyze the core architectural patterns of mobile-first payment systems in a market with variable connectivity.
- ✅ Explain how mobile apps handle network latency and offline states to ensure payment reliability.
- ✅ Describe the critical role of APIs, idempotency, and webhooks in preventing payment errors.
- ✅ Identify the key security layers and integration points in a digital wallet ecosystem.
The Context: Nepal's Payment Backbone
Digital wallets like eSewa and Khalti are not just apps; they are critical infrastructure for Nepal's digital economy.
Challenge: How do you build a reliable payment system on mobile networks with variable latency and coverage?
- They enable e-commerce by "leapfrogging" traditional, card-based systems.
- Success depends on handling the reality of mobile networks.
- This case study explores the architectural choices that make them work.
📱 USSD or App? Channel Is Not the Payment Rail
- Channel: how the customer sends an instruction: app, browser, USSD or a SIM-toolkit menu.
- Backend and rails: systems that authenticate, record and route the transfer; changing the screen does not replace these systems.
- Kenya example: Safaricom documents M-PESA access through USSD
*334#, SIM toolkit and smartphone apps. - USSD does not require a smartphone data session, but still requires mobile-network service. It is not an offline transfer.
Do not assume eSewa or Khalti offers the same channels. Compare access requirements before comparing interfaces.
🎬 Watch: Sending Money by USSD
Key Theme 1: API-First Design ⚡
API-First: A strategy where the application is built around its Application Programming Interface (API) as the central component, treating it as a first-class product.
Core Components
- REST/JSON Endpoints: Standardized way for apps and merchants to communicate. (e.g., `POST /payments`)
- Webhook Callbacks: Server-to-server notifications for events like successful payments.
- Merchant SDKs: Pre-built code to simplify integration into other apps.
Crucial Principle: Idempotency
An operation is idempotent if making the same request multiple times produces the same result as making it once. This is vital for payments to prevent double-charges during network errors.
Idempotency in Action
Example: A User Pays a Bill
- Client Request: App sends a payment request with a unique key.
POST /v1/paymentIdempotency-Key: order-xyz-123 - Network Glitch: The request succeeds on the server, but the response is lost before reaching the phone. The user sees a spinner. 🔃
- Client Retry: The app automatically retries the exact same request with the same `Idempotency-Key`.
- Server Response: The server recognizes the key, sees the payment is already complete, and returns the original success message without charging the user a second time. ✅
Interactive: Idempotency Payment Simulator
Click Send Payment to simulate a payment. A network failure will occur — watch what happens when you retry!
🔍 Real Contract: Verify a Khalti Web Payment
- The merchant backend initiates payment with a unique purchase order ID and an amount in paisa.
- Khalti returns a payment identifier,
pidx, and a payment URL. The customer is redirected to that URL. - A return URL brings the customer back. The merchant uses the lookup API to validate the payment on the server.
- Treat only Completed as success. A pending response is not permission to issue the ticket.
A browser redirect is not the same as a signed server webhook. Follow the provider's documented contract, not an assumed generic flow.
Key Theme 2: Mobile UX Resilience 📱
A great user experience anticipates failure. This is how apps remain usable even with poor connectivity.
Offline States
- Cached menus & biller lists
- Local form validation
- Clear "Offline" indicators
Smart Retries
- Automatic retries on transient errors
- "Exponential backoff" logic
- Transparent progress indicators
Error Surfacing
- User-friendly messages ("Could not connect. Please check your internet.")
- Avoids technical jargon ("Error 503: Service Unavailable")
Interactive: Network Resilience Analyzer
Select a network condition to see how the wallet app applies UX resilience strategies in that situation.
Select a network condition above to see the app response.
Key Theme 3: Multi-Layered Security 🛡️
Building customer trust requires a defense-in-depth security strategy.
- Tokenization: Sensitive financial data (like linked cards) is replaced with a secure, non-sensitive token.
- Device Binding: A user's account is cryptographically tied to their specific mobile device.
- Authentication Flows: Multi-factor authentication using OTP (One-Time Passwords) and user-set MPINs for transactions.
- Backend Monitoring: Server-side rate limiting and anomaly detection algorithms to identify and block fraudulent activity in real-time.
Interactive: Security Layer Matching Quiz (1/2)
Match each threat scenario to the security mechanism that defends against it. Click a scenario, then click the correct security layer.
Scenarios
Security Layers
Interactive: Security Layer Matching Quiz (2/2)
Match each threat scenario to the security mechanism that defends against it. Click a scenario, then click the correct security layer.
Scenarios
Security Layers
Key Theme 4: The Integration Ecosystem 🤝
A payment platform is only as useful as the number of places it's accepted.
Merchant & Biller Integration
- SDKs (Web/App): Makes it easy for developers (e.g., Daraz, Foodmandu) to embed payments into their checkout flows.
- QR Rails (Fonepay): Standardized QR codes create a vast network of acceptance, from large stores to small street vendors.
Banking & Settlement
- Bank Linking APIs: Securely connect user bank accounts for loading funds.
- Settlement Cycles: Automated processes for moving funds from the wallet system to merchant bank accounts.
🔗 Interoperability Has Several Layers
- Acceptance: can this wallet pay this merchant's QR?
- Transfer: can money move to another wallet or bank account?
- Settlement: when and how does the merchant receive usable funds?
- Shared QR appearance alone proves none of these. Check the participating providers, scheme rules and merchant agreement.
Research task: identify the relevant Nepal Rastra Bank document before claiming a Nepal requirement; use Reserve Bank of India sources for an India comparison.
Do not treat an Indian rule, or one network's commercial support, as a universal rule for Nepal.
Interactive: Integration Readiness Scorecard
Rate your merchant's situation on each factor, then click Calculate Best Fit to find the ideal integration approach for eSewa / Khalti.
| Business Factor | Your Rating | SDK | QR / Fonepay | Direct API |
|---|
Outcomes: Transforming Nepali E-Commerce 📊
Widespread Merchant Adoption
- ✅ Payments embedded into e-commerce checkouts.
- ✅ Core to utility bill payments (electricity, internet).
- ✅ Dominant in ticketing (airlines, movies, events).
Improved Customer Trust & Conversion
- 📈 Higher conversion rates compared to cumbersome card payment forms.
- 🔍 Increased trust due to transparent transaction states and reliable retries.
Practical Application: The Checkout Flow 🔍
Scenario: Buying a ticket on a partner app (e.g., a cinema)
- User selects their item and chooses "Pay with eSewa/Khalti".
- The cinema app uses the wallet's SDK to initiate a payment request with a unique order ID.
- The user is deep-linked into the wallet app and authenticates with their MPIN or fingerprint.
- The wallet's server processes the payment and notifies the cinema's server via a secure webhook.
- The cinema app receives confirmation and displays the ticket. The idempotent design ensures this happens only once.
Interactive: Checkout Flow Ordering Challenge
The five steps of a wallet-based checkout are scrambled. Assign each step a position (1–5) by clicking the numbered buttons on the right, then click Check Order.
🎬 Watch: Did the Payment Really Settle?
🧮 Worked Example: The Missing Payment Is Pending
Illustrative end-of-hour records: 100 attempted purchases of NPR 500 each. These are not eSewa or Khalti results.
- Provider lookup shows 96 completed, 3 failed and 1 pending: 96 + 3 + 1 = 100 attempts.
- Confirmed customer payments total 96 × NPR 500 = NPR 48,000, before fees or refunds.
- The pending NPR 500 is not confirmed revenue. Do not issue a second charge simply because the first screen timed out.
- Match order IDs and provider transaction IDs; investigate the pending attempt and reconcile settlement records separately.
Payment confirmation, fulfilment and bank settlement are related states, not the same event.
🌍 Compare Payment Systems Without Guessing
Choose M-PESA, Paytm or Alipay as a comparison for a Nepali wallet. In pairs, name what evidence you would need before recommending the same design here.
Consider: access channel, funding source, merchant acceptance, confirmation, dispute handling and local regulation.
Supported example: M-PESA demonstrates that a payment service can have both non-app and app channels. That does not prove the same channels are available for a Nepali wallet.
For Paytm and Alipay, record “needs a primary source” rather than inventing market shares, transfer limits or regulatory permissions.
Key Takeaways & Lessons 🎯
Lessons from this case study through the lens of Unit 3 (Internet & Mobile Infrastructure):
- Reliability is a product feature. Network variability is a given; it must be handled gracefully in both the client app and the server logic.
- Clear API contracts prevent chaos. Well-defined, idempotent APIs are non-negotiable for financial systems to prevent errors like double charges.
- You can't manage what you can't measure. Comprehensive observability (logs, traces, alerts) is essential to meet payment reliability SLOs (Service Level Objectives).
Case Practice 📝
- Why have mobile wallets, rather than cards, become the main digital payment method in Nepal?
- Explain idempotent transactions in simple terms. Why are they essential on unreliable mobile networks?
- Which security layers described in the case protect authenticity, and which protect confidentiality?
- How do APIs and QR standards help wallets build an ecosystem of merchants and banks?
- What trade-offs exist between strong security (OTP, device binding) and a fast, simple payment experience?
Revise the answers in the full note.
Image & Video Credits
Images
- Existing images: keep the current credit lines (source to be confirmed by Arjan)
Videos (YouTube)
- Sending Money by USSD (0–58 s)
- Did the Payment Really Settle? (0–88 s)
Thank You
Any questions?
Next Up: Unit 4 - E-Commerce Marketing & Advertising Strategies