--:-- --
↓ Scroll for more

Unit 3.

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

IT 204: E-Commerce

eSewa Title

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.
API Nervous System

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 Shield

Idempotency in Action

Example: A User Pays a Bill

  1. Client Request: App sends a payment request with a unique key.
    POST /v1/payment
    Idempotency-Key: order-xyz-123
  2. Network Glitch: The request succeeds on the server, but the response is lost before reaching the phone. The user sees a spinner. 🔃
  3. Client Retry: The app automatically retries the exact same request with the same `Idempotency-Key`.
  4. 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. ✅
Mobile UX Offline Bridge

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")
Security Fortress

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.
Ecosystem City

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.

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.
Checkout Relay

Practical Application: The Checkout Flow 🔍

Scenario: Buying a ticket on a partner app (e.g., a cinema)

  1. User selects their item and chooses "Pay with eSewa/Khalti".
  2. The cinema app uses the wallet's SDK to initiate a payment request with a unique order ID.
  3. The user is deep-linked into the wallet app and authenticates with their MPIN or fingerprint.
  4. The wallet's server processes the payment and notifies the cinema's server via a secure webhook.
  5. The cinema app receives confirmation and displays the ticket. The idempotent design ensures this happens only once.

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