Katkat
Back

Card Issuer Backend: Fast Purchase Approvals and a Secure PII Vault

Capital OneSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design the issuer-side platform that approves or declines card purchases in tens of milliseconds, settles them later, and stores cardholder identity data so a breach of any one service exposes as little as possible.

You are building the backend for a company that issues credit cards. When a cardholder taps a card at a coffee shop, the merchant's acquirer sends the request through the card network, which forwards it to your platform. You must answer approve or decline before the network times out. Hours or days later, the network sends a clearing file and the purchase becomes a settled entry on the cardholder's statement.

Functional requirements

  1. Approve or decline purchase requests based on card status, available credit, and fraud risk.
  2. Support partial reversals, full reversals (voids) and authorizations that expire if never cleared.
  3. Post cleared transactions to the account ledger and generate monthly statements.
  4. Let cardholders freeze a card and see pending and posted activity in the app.
  5. Store cardholder personal data: full name, address, date of birth, national ID number, income, and the card number (PAN).

Non-functional requirements (propose and justify your own numbers)

  • Suggested scale: 30 million accounts, 25 million purchases on an average day, peaks of ~4,000 authorizations per second on holiday weekends.
  • The network gives the issuer a hard budget (assume ~1-2 s end-to-end, of which your platform should use well under 200 ms).
  • Never approve more than the available credit, even when two purchases on the same account arrive at the same instant.
  • Availability target for authorization: 99.99%.
  • Regulatory regimes for card data and personal data apply; a stolen database backup must not reveal card numbers or national IDs.

Deliverables

  • Part 1: Components, data model, and the lifecycle of a purchase from authorization to posting.
  • Part 2: A latency budget for authorization. What is a reasonable p99 for your service, where does the time go, and how do you hit it during peaks and partial outages?
  • Part 3: How you store and access sensitive personal data: encryption, tokenization, key management, access control, auditing and deletion.

Call out trade-offs, failure modes (fraud model slow, database primary fails, duplicate network messages), and what you would build first.

Hints

Hint 1

Distinguish the authorization hold (reduces available credit now) from the posted ledger entry (created at clearing).

Hint 2

Per-account serialization or a conditional atomic update avoids two simultaneous purchases both passing the credit check.

Hint 3

Write down a millisecond budget per step; anything on the hot path must be an in-region, in-memory or single-row read.

Hint 4

Tokenize the PAN and national ID into a separate vault so most services never see real values; use envelope encryption with keys in an HSM/KMS.

Follow-up questions

  • A network retransmits an authorization after your approval timed out on their side. How do you guarantee the hold is not taken twice?
  • How would you support a multi-region active-active setup without risking over-limit approvals?
  • An engineer needs real card numbers to debug a clearing mismatch. What process do you allow?
  • How do you handle a clearing amount larger than the authorized amount (e.g., restaurant tip or hotel incidentals)?