Unit 3.

Case Study: Mobile-First Payments – eSewa & Khalti Infrastructure Choices

IT 204: E-Commerce

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/payment
Idempotency-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!

Client App

Network

→

Server

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

A stored card number is never sent over the network — a placeholder token is used instead.

A user must enter the 6-digit code sent to their phone before a payment proceeds.

An account is locked after 50 failed login attempts within one minute.

The app refuses to open after the SIM is moved to a different handset without re-registration.

Security Layers

Tokenization

OTP / MPIN Authentication

Rate Limiting & Anomaly Detection

Device Binding

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).

Thank You

Any questions?

Next Up: Unit 4 - E-Commerce Marketing & Advertising Strategies

Course Home | Unit 3 Resources