Scaling settlement batching

Settlement batching — grouping captured transactions into batches for submission to the acquirer — sounds like an accounting problem. It's actually a distributed systems problem with financial-grade correctness requirements.

Written February 2025 from a platform scaling engagement.

Why it's a systems problem

• Batch boundaries must be exact. A transaction is either in this batch or the next; never both. Never neither.
• Batches settle atomically. Half a batch settling is worse than a batch failing to settle entirely.
• Batches are irreversible. Once submitted, a batch can't be recalled; corrections require adjustment transactions.
• Batch identity is a coordination point. Multiple services (capture, settlement, reporting) reference the batch by ID.

Getting any of these wrong produces incidents that are hard to unwind.

The design pattern that works

• Batch construction is a single-writer operation. One process (or one leader in a coordinator election) constructs each batch. Multiple processes reading from the same source produces overlaps.
• Batch ID assigned at construction, not at submission. Every transaction knows its batch before submission; downstream systems can reference it.
• Batch closing is explicit. A batch is "open" (accepting new transactions), "closing" (no new transactions, being submitted), or "closed" (submitted and settled). Never assume state from time-of-day.
• Retry submits the same batch, not a different one. If submission fails partway, the retry submits the identical batch; the acquirer's idempotency handles the duplicate.

The failure that catches people

A batch that fails to close because of a downstream error, then gets held open past its intended window. New transactions accumulate. The batch grows past what the acquirer accepts. Now you have a batch that can't be submitted as-is.

Building batch-size limits with automatic close-and-open behavior avoids this. Not building them is a hard incident to recover from.