Problem Statement: Multi-Instrument Checkout
Why split payments exist in modern commerce — split payment interview depth
Problem Statement: Multi-Instrument Checkout
Design a split payment platform that lets a shopper combine a card, stored value (gift card / store credit), a wallet balance, and BNPL installments on a single order — while preserving money correctness and the PCI boundary. Klarna, Afterpay, and PayPal all ship variants of this pattern: one checkout total, several funding sources, asynchronous provider callbacks, and refund logic that must stay fair to every instrument.
What makes this different from a payment gateway
A gateway authorizes one instrument per intent. Split payment adds an allocation layer on top: given an order total T, choose non-negative leg amounts a₁…aₙ in integer cents such that Σaᵢ = T, authorize each leg independently against its own provider, and mark the order paid only when every mandatory leg reaches a terminal success state. The hard part is the unhappy path: if leg 2 declines after leg 1 already captured, we owe the shopper a compensating void on leg 1. That is classic saga territory — a sequence of local transactions, each with a compensating action, coordinated without a distributed lock across external processors.
Who is at the table
| Persona | Need |
|---|---|
| Shopper | Pay a $200 order as $50 gift card + $150 card, and see each leg's status live |
| Merchant | One settlement view; chargebacks attributed to the correct leg |
| Risk | Velocity limits per instrument and per user, not just per order |
| Finance | An immutable audit trail so every partial refund reconciles |
The framing that wins the interview
State the model upfront: the order is the aggregate root, and each payment leg is a child entity with its own idempotency key, provider reference, and state machine. The order's paid status is derived from its legs — never written directly by a single leg's handler. That one sentence buys you the whole correctness story: no leg can declare the order paid on its own, and recovery after a crash is just re-deriving the parent from durable child state.
Key Highlights
- •One checkout total, several funding legs — each with an independent lifecycle, idempotency key, and provider reference
- •Allocation invariant: leg amounts are non-negative integer cents that sum EXACTLY to the order total (Σaᵢ = T)
- •Order 'paid' is DERIVED from leg terminals, never written by a single leg handler; partial failure triggers compensating voids (a saga)
- •Partial refunds must reverse each leg proportionally or by an explicit policy, with an immutable audit trail
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "If stuck on Problem Statement: Multi-Instrument Checkout, I'll write the allocation equation Σaᵢ = T first."
- "I'll separate PCI card flow from internal gift card ledger."