# Design a Mobile E-Commerce Checkout: Cart Sync and Apple Pay

Source: https://www.techinterview.org/post/3233475023/design-mobile-ecommerce-checkout-apple-pay/
Updated: 2026-07-13 · techinterview.org

Mobile checkout is one of the highest-impact 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.