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.
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!
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
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.
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.
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.
Thank You
Any questions?
Next Up: Unit 4 - E-Commerce Marketing & Advertising Strategies