Design a Gift Card & Store Credit System

Problem statement

Design a gift card and store credit system for a large e-commerce platform. Customers and businesses purchase gift cards, recipients redeem codes for purchases, refunds may issue store credit instead of returning to the original payment method, and the platform must track balances, partial usage, expiration, and region rules. The system must generate secure codes, apply balances as partial or full payment at checkout, protect codes from brute-force guessing, scale redemption checks inside the checkout latency budget, and provide auditing for suspicious redemption patterns.

The defining insight is that a gift card is a financial liability. When a customer pays $100 for a card, the platform receives cash and owes $100 of merchandise later. Every redemption reduces that liability; every refund to store credit increases it. That means the core of this system is a double-entry ledger with the same correctness bar as a payment system: no double spends, no negative balances, no lost refunds, and a complete, immutable journal that finance and regulators can audit. A naive design that stores only a mutable balance column on a cards table will pass the happy path and fail under concurrency, retries, and fraud.

Why this question is distinctive

Most e-commerce designs treat payment as an external gateway call. Gift cards invert that: the platform is the issuer, the acquirer, and the settlement authority. It must handle: secure code generation with enough entropy to resist guessing; balance holds during checkout so two carts cannot spend the same card; partial payment orchestration where a gift card covers part of an order and a credit card covers the rest; refund-to-credit flows that must be idempotent; expiration and escheatment rules that vary by jurisdiction; and fraud patterns such as card draining, where attackers test stolen card numbers at scale.

Analysts such as Mercator Advisory Group have estimated United States gift card purchase volume in the hundreds of billions of dollars annually, and retailers report significant outstanding stored-value liabilities on their balance sheets. Starbucks public filings have described billions of dollars of annual stored-value card load activity with roughly a third of US company-operated transactions paid by stored value. These figures anchor why this subsystem is treated as treasury-grade infrastructure rather than a promotional feature.

The four planes of the design

1. Issuance plane: purchase, code generation, activation, corporate bulk programs, physical card logistics.
2. Ledger plane: double-entry journal, balances, holds, captures, reversals, expiration, breakage.
3. Checkout plane: balance queries, hold-capture orchestration, partial payment splits, refund-to-credit.
4. Trust plane: brute-force protection, velocity checks, fraud scoring, reconciliation, audit, escheatment.

A strong answer keeps these planes separate. Checkout latency pressure must not weaken ledger consistency, and fraud tooling must not sit synchronously in the critical path beyond a bounded budget.