Skip to content

Design a Payment Processor with Batch Settlement

Published 4 October 2026

An OpenAI system design question.

Problem Description

Design a payment processor that receives payment requests from merchants and talks to upstream payment networks. It must support authorization holds, later charge requests, and scheduled batch submission to the networks.

The flow has three stages:

  1. Hold — the merchant sends a hold request. The processor forwards it to the upstream payment network, which eventually approves or rejects it.
  2. Charge — if the hold succeeds, the merchant may later send a separate charge request.
  3. Batch processing — charge records are grouped by payment network and sent upstream periodically as batch files.

Each stage has its own trigger, processing behavior, and result that must be communicated back to the merchant. Most of the discussion was about pinning down the lifecycle and semantics of these three stages.

Follow-ups

What does the merchant receive?

If the hold request is just written to Kafka and the API returns immediately, the merchant still doesn't know whether the network approved or rejected the hold. What result should the merchant receive, and at what point is the request considered complete?

Deduplication

Where in the architecture should deduplication happen? Prevent duplicate payment operations both when merchants retry requests and when asynchronous components reprocess the same work.

Scaling

How should the processor scale as request volume grows? Cover scaling the asynchronous processing pipeline and making sure each stage of the payment flow can handle higher throughput.

Large batch processing

How do you produce very large batch files for the payment networks? Ideas discussed:

  • Generate batches independently per payment network so the work runs in parallel.
  • Don't do all batch preparation at the scheduled cutoff. Prepare batch data incrementally throughout the day so little work remains when the final files are submitted.