Batch processing
What is batch processing?
Batch processing is a method of handling multiple transactions as a single group, automatically, with no user interaction during the run. That's what separates it from transaction processing, where each transaction is handled individually and involves user interaction at the moment it happens.
In card payments, the batch is the set of transactions a merchant accumulates over a period and submits together for clearing and , instead of sending each one to the on its own. The same pattern runs outside cards: end-of-day bank reports, payroll files, and overnight trade settlement are all scheduled runs against a pre-assembled queue.
Key facts
- Also known as: batch settlement, batch capture
- What a payment batch holds: captured sales and recorded since the last batch close
- Applies to: card capture files, and files, payroll runs, end-of-month , overnight trade settlement
- Batch schedule: batches close on a cut-off set by the merchant or the acquirer, typically once per day; the exact timing varies by acquirer and processing setup
- Origin: reached large enterprises with mid-20th-century mainframes, when jobs were fed to the machine on punched cards
How it works
- Authorization – the approves the transaction and reserves the amount on the account. No money moves yet.
- Capture – the merchant marks the authorized transaction for , and it joins the open batch.
- Accumulation – captures build up in the open batch until the cut-off time.
- Batch close – at cut-off, the batch is sealed and transmitted through the to the acquirer as one file rather than one message per sale.
- Clearing – the acquirer passes the batch to the , which route each item to the issuer and apply .
- Settlement and reconciliation – the acquirer credits the net of fees, and the merchant matches the batch report line by line against its own .
Why it matters
- Batching replaces one network submission per sale with one submission per file, which cuts the message volume an acquirer and the merchant's systems handle for the same sales.
- The batch cut-off sets the funding clock. A sale captured after cut-off rides in the next batch, which pushes its back by a full settlement cycle.
- Clearing delay carries a pricing consequence: schemes rate transactions partly on how quickly they clear after authorization, so a batch submitted late can settle at a less favorable category, depending on scheme rules.
- The batch is the unit of reconciliation. Because the acquirer reports funding per batch, a merchant matches one acquirer total against one internal total instead of chasing individual transactions.
Common issues
- Missed cut-off – transactions captured after the batch closes wait for the next cycle, which surfaces as a funding delay the order data alone doesn't explain.
- Authorization expiry before capture – an approved amount is only held for a limited window, and the window varies by scheme, card type, and . Capture attempted after it lapses fails and needs a fresh authorization.
- Batch that never closes – a terminal or connection failure at cut-off leaves the batch open, so the sales inside it stay authorized but unsubmitted, and the revenue is uncollected until the batch is resubmitted.
- Duplicate submission – resubmitting a batch that already cleared bills cardholders twice and produces tied to the second charge.
- Reconciliation mismatch – refunds, , and fees land at different points in the cycle, so a batch total and a bank credit rarely line up without adjustment entries.
