Art of Codeartofcode
Lesson 10 of 16

42. Design E-commerce Cart and Checkout (Amazon / Flipkart)

1
The interview prompt
2
42.1 What do you ask first?
3
42.2 How big is this, really?
4
42.3 What are the doors?
5
42.4 What do we store?
6
42.5 What does the whole system look like?
7
42.6 How is the cart stored?
8
42.7 How do you reserve inventory?
9
42.8 How do you make order creation idempotent?
10
42.9 How does the payment hand-off work?
11
42.10 How does the checkout saga work?
12
42.11 What would you say in the last five minutes?
13
Score yourself
14
Variations to practise
15
Sources
16
Code lab
42. Design E-commerce Cart and Checkout (Amazon / Flipkart)

42.9 How does the payment hand-off work?

3 min read+10 XP

Payment is asynchronous and unreliable: UPI approvals take time, gateways time out, webhooks arrive late or twice. Model the order as a state machine with a place for every outcome:

created → payment_pending → paid → confirmed; payment_failed → cancelled; no payment in time → expired; payment after expiry → refund_due.

Figure: every payment outcome has a state to go to; nothing is left ambiguous.

In the chapter's code:

  • A success webhook moves an order to confirmed and confirms its stock hold; a duplicate webhook is ignored.
  • A failure webhook cancels the order and releases stock.
  • A customer who takes too long: the order expires and stock is released; when the money arrives later, the order goes to refund_due, never shipped without stock.
  • Illegal moves (cancelling a confirmed order through this path) are refused.

Also:

  • Verify webhooks (signature, timestamp, Chapter 24) and reconcile periodically by asking the gateway for the status of every payment_pending order, in case a webhook never arrives.
  • Show the shopper the truth: "payment processing" until confirmed, never "order placed" on a guess.

Memory code: "Every payment outcome has a state, and late money goes back."