Katkat
Back

Design Payment Authorization, Capture, and Batch Settlement

OpenAISoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a resilient payment processing platform supporting two-phase payment operations (authorize and capture), double-entry ledgering, and asynchronous batch settlement with external financial gateways.

Scenario

You are tasked with designing the core payment infrastructure for a large-scale API platform. The platform supports pay-as-you-go billing and subscription tiers, requiring real-time fund reservations (authorizations), deferred claims (captures), and end-of-day asynchronous batch settlements and reconciliation with payment networks and acquiring processors.

Requirements

Functional Requirements

  • Authorize (/v1/payments/authorize): Synchronously verify card validity and hold funds on the customer's account for up to 7 days.
  • Capture (/v1/payments/capture): Collect previously authorized funds (supporting full and partial captures, as well as voids for cancellations).
  • Batch Settlement: Aggregate captured transactions into bounded, deterministic batch files (e.g., NACHA/ISO 20022 or processor-specific formats) transmitted to acquiring banks.
  • Reconciliation: Ingest provider settlement and clearing reports to reconcile external state against the internal financial ledger, flagging discrepancies.
  • Auditable Ledger: Every monetary movement must be recorded in an immutable, double-entry ledger.

Non-Functional Requirements

  • Strict Idempotency: Guarantee that network timeouts, client retries, or internal worker crashes never result in duplicate charges or captures.
  • Latency: Authorize p99 latency < 250ms (excluding downstream processor time).
  • Availability & Consistency: High availability for authorization ingestion (99.999%), with strong consistency for balance and ledger states.
  • Fault Recovery: Clean recovery from partial provider responses (e.g., request sent, socket drop before response).

Scale Assumptions

  • Peak authorization throughput: 10,000 requests/sec.
  • Daily transaction volume: 50 million authorizations and captures per day.
  • Batch processing window: Daily settlement files generated within a 2-hour cutoff window, bounded to a maximum of 500,000 records per file.

What the Answer Should Cover

  1. API & Data Model: Key schemas for transactions, idempotency records, and immutable double-entry ledger entries (debits/credits).
  2. State Machine: Explicit payment lifecycle states (AUTHORIZED, CAPTURE_PENDING, CAPTURED, VOIDED, SETTLED, DISCREPANCY).
  3. Failure Modes & Retries: Handling downstream processor timeouts during auth/capture using two-phase commit patterns, reverse-auth calls, or reconciliation queues.
  4. Batch Settlement & Reconciliation: Architecture for chunking settled records into deterministic files, handling provider response acknowledgments, and matching clearing records to internal transactions.

Hints

Hint 1

Treat the external gateway as an unreliable third party: design state transitions around explicit pending states, background polling, and automated reverse-authorization on indeterminate timeouts.

Hint 2

Model the financial core as an append-only, double-entry ledger where accounts always balance to zero, decoupled from the mutable transaction status table.

Hint 3

Make batch file generation idempotent and deterministic by partitioning records via monotonically increasing sequence IDs or checkpoint cursors rather than timestamp ranges.

Follow-up questions

  • How does your architecture handle an authorization that expires (e.g., after 7 days) before a capture is executed?
  • If the external provider acknowledges a batch file with 99% success and 1% validation errors, how does your reconciliation pipeline isolate and remediate the failures without reprocessing the whole batch?
  • How would you support multi-currency authorization where the authorization currency differs from the capture and settlement currency?