Mobile checkout is one of the highest-leverage UI flows in commerce. Every percentage-point reduction in cart abandonment is worth real revenue. The system design interview tests whether you can build a checkout that survives flaky networks, syncs cart state across devices, and integrates with Apple Pay / Google Pay without losing the order.
Functional requirements
- Add items to a cart from a product page
- Cart syncs across devices for logged-in users
- Guest checkout (no signup required)
- Saved addresses, payment methods
- Apple Pay / Google Pay support
- Address autocomplete
- Order confirmation and tracking
Architecture
Three modules: cart store, payment, order pipeline.
Cart store
Per-user cart on the server. Local copy on device. Each cart line has:
- Product ID, variant (size, color)
- Quantity
- Added-at timestamp
- Reserved-until (for inventory holds)
For guest users, cart is stored in a server-side anonymous session (cookie or device ID). On login, anonymous cart merges with logged-in cart.
Cart sync
Two-way: device pushes adds/removes, server pushes updates from other devices via push notification or pull on app foreground.
Conflict resolution: union of items, max quantity. If user added 2 of item X on phone and 3 on tablet, the cart has 5 (assuming inventory allows).
Inventory checks
Soft checks at add-to-cart (in-stock visible). Hard checks at checkout (transactional reservation, typically held for 15 minutes).
If item goes out of stock between add and checkout, surface a clear error and offer alternatives.
Apple Pay / Google Pay
Native SDKs. Flow:
- User taps “Pay with Apple Pay”
- OS sheet appears with payment, address, name
- User authorizes with biometric
- Wallet returns a payment token (encrypted, network-routable)
- Client sends token to your server with order details
- Server forwards to processor (Stripe, Adyen, etc.)
- Processor returns success/failure; server commits or rolls back
Total time: 5–15 seconds for a smooth checkout.
Address autofill
Use platform autofill (iOS AutoFill, Android Autofill) for first-time entry. Save to user profile after order. Subsequent orders default to last-used address.
Address validation: server-side via USPS / SmartyStreets / Google. Suggest corrections if the entered address is invalid.
Order placement
The riskiest moment. Apply same rules as banking:
- Idempotency key in the request header
- Server dedupes — never charge twice
- Show clear “submitting” UI; do not allow back button
- On failure, show specific error; preserve cart for retry
Recovery from interruption
If the app is killed mid-checkout:
- Cart preserved on server
- Order draft (with idempotency key) preserved locally
- On relaunch, resume from where the user was
Push notifications
Order confirmation, shipping updates, delivery updates. All non-sensitive, content visible.
Frequently Asked Questions
How do you handle a price change between cart and checkout?
Re-fetch prices at checkout. If different, surface the new price and ask user to confirm. Some implementations honor the cart price for a short window.
Should I save credit cards on the device?
No. Save tokens via the payment processor (Stripe Customer object, Adyen Customer Profile). The actual card number never touches your servers or the device.
What about PCI compliance?
Use a tokenization vendor (Stripe Elements, Braintree Hosted Fields, Apple Pay). Reduces your PCI scope from full DSS to SAQ-A.