Batch card payment processing allows a business to submit or manage multiple card transactions together rather than dealing with each transaction manually.
It can be useful for businesses processing high volumes of card payments, refunds or other payment actions from billing software, an ERP, CRM or another internal system.
However, the term batch payment processing is often used to describe several different parts of the card-payment process.
It might mean:
- submitting multiple card transactions in a file;
- processing multiple captures or refunds together;
- retrying failed payment actions;
- closing or reconciling card-terminal transactions;
- grouping transactions for settlement; or
- passing card-payment data between business software and a payment processor.
These are not necessarily the same thing.
If your business needs batch card processing, the important question is what needs to be processed in bulk and how that information needs to move between your systems and your payment provider.
What is batch card payment processing?
Batch card payment processing generally means grouping multiple card-payment instructions together and submitting them to a payment processor in a structured format.
For example, instead of a member of staff manually processing hundreds of transactions one at a time, a business system could generate a file containing multiple payment instructions.
That might look broadly like:
business system → batch file created → secure submission → payment processor → individual transactions processed → results returned → reconciliation.
Payment providers can support different types of batch activity.
Adyen, for example, currently supports bulk payment requests and payment modifications through batch files. Its documentation includes batch functionality for actions such as authorisations, captures and refunds.
This does not mean every payment provider supports the same functionality or uses the same file structure.
Batch-processing capability should therefore be treated as a specific technical requirement when comparing payment gateways or merchant account providers.
What card-payment actions can be processed in batches?
The answer depends on the processor, but batch functionality may support actions such as:
- card-payment authorisations;
- captures;
- refunds;
- cancellations;
- cancel-or-refund instructions;
- retrying failed captures;
- updating stored card information; and
- other transaction modifications.
The business case can vary considerably.
A retailer might need to capture a large number of previously authorised orders after goods are dispatched.
A ticketing, travel or events business might need to process a large number of refunds.
A subscription or membership platform might generate payment instructions from its billing system.
A larger corporate business may have payment instructions originating inside an ERP rather than from a conventional ecommerce checkout.
The processor needs to support the particular transaction type as well as the volume involved.
Need a payment provider that supports batch card processing?
If your card payments need to connect with billing software, an ERP, CRM or another business system, provider compatibility can be just as important as processing rates.
Tell Merchant Advice Service how your current payment process works and what a new provider needs to support. We can help identify providers that may suit the requirement.
Get personalised recommendations
How does a card-payment batch file work?
The exact process varies by provider.
A typical file-based setup may start with payment instructions being created inside the business's own software.
The resulting batch file can contain multiple transaction records, potentially including information such as:
- merchant account;
- transaction reference;
- amount;
- currency;
- transaction type;
- customer reference;
- a token or permitted payment credential; and
- other information required by the processor.
The file is then submitted using the method supported by the payment provider.
For example, some processors use secure file transfer such as SFTP for more complex batch processing.
The processor validates the file and individual records, attempts the requested payment actions and returns information about the results.
That information then needs to flow back into the business's own systems so successful and unsuccessful transactions can be identified and reconciled.
Batch card processing vs payment APIs
Batch processing is not necessarily the best approach for every high-volume payment operation.
Modern payment platforms increasingly use APIs that allow software to communicate directly with the payment provider as individual events happen.
A real-time payment flow might look like:
transaction created → API request sent → processor responds → result recorded immediately.
A batch process might instead look like:
multiple transactions created → file generated → batch submitted → transactions processed → results returned.
An API may be more appropriate where:
- an immediate payment response is needed;
- payments form part of a live customer journey;
- individual transactions trigger other software actions;
- the business is building a new payment integration; or
- real-time visibility is important.
Batch processing can remain useful where:
- large numbers of transactions originate from one back-office system;
- the payment action does not require an immediate customer-facing response;
- the business already has an established file-based workflow;
- large numbers of refunds or captures need to be processed;
- legacy systems cannot easily make individual API calls; or
- transactions are intentionally processed during defined windows.
Some businesses use both approaches.
Adyen, for example, provides batch-processing functionality but states that its API is preferable for regular payments or modifications where appropriate. :chatgpt-content-reference{index="0"}
For businesses connecting payments to other software, our guide to integrated payments explains the wider integration considerations.
Is a card-payment batch the same as a settlement batch?
No. This is an important distinction.
A card transaction can be authorised and processed individually but later become part of a group of transactions used to calculate the merchant's settlement.
A settlement or payout batch can include activity such as:
- completed card payments;
- refunds;
- chargebacks;
- fees;
- adjustments; and
- other account movements.
The resulting amount is then paid to the merchant according to the provider's settlement arrangement.
Depending on the acquiring and payout model, transactions from one sales day do not necessarily have to appear in one single bank payment.
For example, some settlement models can place transactions from different sales days into later payout batches according to when funds become payable. :chatgpt-content-reference{index="1"}
This is why understanding payment processing, capture and settlement as separate stages becomes important for businesses with more complex card-payment operations.
What does “batch” mean on a card machine?
The term can also appear in card-present payment environments.
Traditionally, card-terminal transactions could be grouped into a batch that was closed and submitted for further processing or settlement.
Modern terminal and acquiring setups often automate more of this process, so businesses may not manually close a batch in the way older card-terminal systems required.
If your terminal displays a batch number or provides a batch report, that does not necessarily mean your business is using the type of file-based bulk card processing described elsewhere in this guide.
It may simply be part of the terminal provider's transaction, reconciliation or settlement process.
Which businesses use batch card payment processing?
Batch card processing becomes more relevant where transaction volumes are high or where payment instructions originate in another business system.
Examples may include:
Subscription and membership businesses
Payment instructions may originate from membership or billing software rather than being manually entered by staff.
Retailers and ecommerce businesses
Businesses using separate authorisation and capture may need to capture transactions once orders are fulfilled or goods are dispatched.
Travel and ticketing businesses
High transaction volumes, cancellations and refunds can create requirements for bulk payment modifications.
Large corporates
Payment data may originate inside ERP, finance or bespoke internal systems and need to pass into the payment-processing environment.
Platforms and software businesses
Software platforms may need payment functionality that can handle large volumes of card transactions and modifications programmatically.
Businesses moving from legacy payment systems
An established company may already have a long-running batch-payment process that needs to be replicated or modernised when changing gateway or acquirer.
Batch processing for card authorisations and captures
Understanding the difference between authorisation and capture is particularly useful in batch-payment environments.
A card payment does not always have to be captured immediately when it is authorised.
With payment methods and providers that support separate capture, the authorisation can reserve the funds and the capture can take place later.
For example:
customer places order → card authorised → stock confirmed → goods dispatched → payment captured.
If a business has a large number of authorised transactions ready for fulfilment, batch functionality may allow multiple captures to be submitted together where the provider supports this.
Similarly, a business handling a large number of cancellations or refunds may use batch modifications rather than processing each transaction manually.
Separate capture is provider and payment-method dependent, so the workflow needs to be confirmed with the processor. :chatgpt-content-reference{index="2"}
Reconciliation is a major part of batch card processing
Processing thousands of transactions efficiently is only useful if the business can work out what happened to them afterwards.
A robust payment setup should allow an internal transaction to be followed throughout the payment lifecycle.
For example:
customer/order reference → payment instruction → processor reference → transaction result → settlement → bank receipt.
Consistent references make it easier to automate this process.
Before choosing a provider, establish what information is available through:
- batch result files;
- APIs;
- webhooks;
- settlement reports;
- merchant dashboards;
- downloadable transaction reports; and
- accounting or ERP integrations.
This becomes increasingly important as transaction volume grows.
A single settlement may represent hundreds or thousands of underlying transactions, refunds and adjustments.
Our guide to payment reconciliation explains this in more detail.
What happens if transactions in a batch fail?
Error handling is one of the most important parts of a batch integration.
A business should understand the difference between:
- an entire file being rejected;
- a file passing validation but containing invalid records;
- a transaction being submitted successfully but later declined;
- a capture or refund failing;
- a duplicate transaction being detected; and
- a transaction requiring manual investigation.
Providers handle these situations differently.
For example, Adyen's batch-modification process provides results for individual records after validation, while final processing failures can also be communicated asynchronously. :chatgpt-content-reference{index="3"}
Before going live, ask:
What happens if one transaction in a batch fails?
Can that transaction be corrected and resubmitted without repeating transactions that have already succeeded?
This becomes particularly important where files contain large numbers of records.
Batch files, APIs or an integrated payment setup?
A new provider needs to fit the way your business actually creates and manages card payments.
If you already know what your software needs to send and receive, Merchant Advice Service can use those requirements to help narrow down suitable merchant account and gateway providers.
Find suitable providers
PCI DSS and batch card-payment files
Security needs particular attention if a batch process involves cardholder data.
PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, as well as organisations that can affect the security of the cardholder-data environment. :chatgpt-content-reference{index="4"}
The implications depend on how the integration has been designed.
Questions to establish include:
- what card data is contained within the file;
- whether payment credentials are tokenised;
- where payment data is stored;
- who can access it;
- how files are encrypted;
- how files are transferred;
- how long data is retained; and
- how files and results are deleted or archived.
For example, Adyen requires SFTP and PGP encryption for its advanced transaction batch-file process. :chatgpt-content-reference{index="5"}
A business should not create its own spreadsheet or CSV containing raw card details and assume that uploading it to a provider automatically makes the process secure or PCI compliant.
The proposed workflow should be reviewed with the payment provider and the business's appropriate technical or PCI advisers before implementation.
Changing payment provider when you already use batch processing
A payment-provider switch can become a technical migration when batch processing is involved.
Two providers may both support batch card processing while having completely different:
- file formats;
- required fields;
- transaction references;
- upload methods;
- encryption requirements;
- tokenisation systems;
- error handling;
- response formats;
- reporting; and
- settlement processes.
Before choosing a replacement provider, document the current flow.
source system → batch creation → secure transfer → processor → result → settlement → reconciliation.
Then establish how each stage would operate with the proposed provider.
This can expose integration requirements that might otherwise be missed by comparing merchant account pricing alone.
What should you compare between batch card payment providers?
Start with functionality before comparing headline processing rates.
Supported transaction types
Can the provider batch the authorisations, captures, refunds or other actions your business requires?
Submission method
Does the provider use SFTP, a portal, an API or another integration method?
File specification
Can your existing systems create the required format without substantial redevelopment?
Transaction volumes
Check any file-size, transaction-count, processing-time or frequency restrictions.
Error handling
Understand what happens when an individual record fails and how it can safely be resubmitted.
Security and PCI
Establish how card credentials are handled, whether tokenisation can be used and what responsibilities remain with the merchant.
Reporting and reconciliation
Make sure individual transactions can be matched back to your own customer, order or invoice records.
Settlement
Batch-processing capability does not determine how quickly the business receives its money. Compare settlement arrangements separately.
API capability
Even if batch processing is required today, consider whether the provider can also support APIs if the payment architecture changes later.
How Merchant Advice Service helps with batch card-payment requirements
Merchant Advice Service helps businesses understand their payment requirements before identifying providers that may be suitable.
For a batch card-processing requirement, monthly turnover alone is unlikely to tell us enough.
We may also need to understand:
- the type of card transactions being processed;
- transaction volumes;
- average transaction value;
- where payment instructions originate;
- which software is involved;
- whether batch files, APIs or both are required;
- how payment credentials are stored or tokenised;
- how files are currently transferred;
- how results need to be returned;
- reconciliation requirements;
- settlement requirements;
- your existing gateway or acquirer; and
- why you are considering a change.
This creates a much more useful provider profile than simply asking which processor offers the lowest transaction percentage.
We can then help identify payment gateway providers and merchant account providers that may be able to support the required payment flow.
You can also browse the Payments Directory® if you would prefer to research providers directly.
Find a provider that fits your card-payment workflow
Tell us how your business currently creates, processes and reconciles card payments and what your next provider needs to support.
Merchant Advice Service can use that information to help identify payment providers that may be suitable.
Get personalised recommendations Explore providers
Editorial & Commercial Disclosure
Batch card-processing functionality varies between payment gateways, acquirers and processors. The examples in this guide explain different processing approaches and should not be taken as a recommendation of a particular provider.
Provider APIs, batch specifications, transaction capabilities, security requirements and settlement arrangements can change. Businesses should confirm current technical requirements directly with the relevant provider before implementing or changing an integration.
Merchant Advice Service is an independent payments information and provider-matching service. MAS is not an acquiring bank or payment processor and does not process card transactions itself.
MAS may receive a referral fee or commission from some payment providers where a business proceeds following an introduction. Commercial relationships do not determine the factual information or provider-selection principles contained within this guide.
Payment-provider approval, technical acceptance, pricing, settlement and final contract terms remain the responsibility of the relevant provider.
