Flipkart Marketplace Platform  ·  View 14 of 25  ·  5 · Runtime

Checkout and Payment Sequence

The one flow that must never take money without creating an order, or create an order without taking money.

Editable source SVG draw.io All views
Shopper Customer BFF Checkout Inventory Payment orch UPI / PSP Order Kafka 1. POST /checkout 2. create intent + idem key 3. reserve(listing, qty, ttl 900s) 4. Lua CAS on Redis counter 5. reservation_id 6. authorise(amount, idem key) 7. collect request 8. approve in bank app 9. webhook: authorised 10. dedupe on psp_ref 11. create order (Temporal saga) 12. confirm(reservation_id) 13. OrderCreated 14. order_id, ETA 15. confirmation screen 16. no webhook in 90 s 17. status poll, then void 18. release(reservation_id) Critical Flow — Reserve, Pay, Confirm Stock is reserved before money is asked for, and the reservation expires on its own. Every step carries the same idempotency key, so a retried webhook cannot create a second order or a second debit. v 1.0 · owner Commerce Engineering · date 2026-09

Decisions

  • Stock is reserved before payment is requested, with a 900-second TTL that expires on its own
  • One idempotency key travels from checkout intent through authorisation, webhook and order creation
  • Order creation is a Temporal saga: if confirmation fails after capture, the compensation is a refund, not a retry loop

Failure handling

  • No webhook within 90 seconds triggers a status poll, then a void — the platform never waits indefinitely on a rail
  • A duplicate webhook is deduplicated on the PSP reference before it reaches the order service
  • Every abandoned path releases the reservation explicitly; expiry is the backstop, not the mechanism

Targets

  • Checkout p95 500 ms excluding the time the customer spends in their bank app
  • Reservation call p99 under 20 ms — it is a Redis compare-and-set, not a database transaction
  • Zero tolerance on oversell and on double capture; both are alerted, not sampled