Can your platform send 500 supplier payments in one call and know, within seconds, which ten failed and why? A bulk payment API accepts many payment instructions in a single call and returns individual, per-payment status for each one, not one verdict for the whole batch.
Most payment infrastructure still tracks one payment at a time: create, authorise, confirm. At bulk volume you’re tracking hundreds or thousands of outcomes at once, without polling every record by hand. That’s a batch payment problem, not a single-payment one, and it needs different design decisions.
If your team is scoping this for supplier runs, payroll, refunds or marketplace payouts, the sections below cover the API design questions that matter: batch behaviour, idempotency, webhook design, recipient validation and reconciliation output. This sits alongside our broader payments API evaluation guide if you need the wider picture before narrowing into bulk-specific behaviour.
In July 2026, UK Open Banking’s infrastructure processed 2.94 billion successful API calls, including 171.38 million payment initiation (PIS) calls specifically, with weighted API availability at 99.99%. As payment initiation scales, batch-level design starts to matter as much as single-payment reliability.
Key takeaways
- A bulk payment API is judged on per-payment status, not batch-level status: one failure should never block the rest of the run.
- Idempotency keys are not optional at bulk volume; without them, a retry risks paying someone twice.
- UK Open Banking bulk payments carry their own atomicity rules, set by the receiving bank rather than by your integration.
- Reconciliation depends on what the API returns, not on manual matching afterwards.
What Does a Bulk Payment API Actually Do?
A single-payment API and a bulk payment API share the same building blocks (authorise, confirm, report), but bulk changes what “report” has to mean. The table below is the fastest way to check whether a provider’s payment processing API is genuinely built for batches, or just wraps a single-payment endpoint in a loop.
| Point of Distinction | Single-payment API | Bulk payment API |
|---|---|---|
| Request shape | One payment per call | Many payments per call |
| Response | One status | Status returned per payment |
| Partial outcomes | Not applicable | Some succeed, some fail, same call |
| Identifiers | Payment ID only | Payment ID plus batch ID |
| What to check in the docs | n/a | Batch limits, partial-success format, per-payment identifiers |
If a provider’s payment processing API documentation is silent on that right-hand column, it’s a single-payment API with a bulk wrapper attached, not a genuine bulk payment API.
How Should Partial Failures Be Handled?
This is the question most evaluations skip, and it’s the one that causes production incidents. A dependable payment API treats a batch as a set of independent outcomes, not one pass/fail result.
Atomic batches versus per-payment batches
Some providers treat a batch as one atomic unit: every payment succeeds, or the entire batch rolls back. Others treat each payment independently, so one failed payment doesn’t block the remaining 499. For most B2B use cases (supplier runs, payroll, refunds) per-payment handling is what you want. Full atomicity sounds safer on paper, but one bad account number can then hold up an entire payroll run.
UK Open Banking’s own atomicity behaviour
If this runs over UK Open Banking rails rather than card or file-based rails, the receiving bank, not your provider, often decides whether a submitted batch executes as a whole or per-payment, and some UK institutions require each payee to already be a recognised, trusted beneficiary before a bulk instruction will go through. This constraint is rarely covered in generic payment processing API guides, and it shapes how you design pre-submission validation.
What a partial-failure response needs
A response format that actually holds up under partial failure includes:
- Successful, failed, and pending payments listed separately in the same response
- A reason code on every failed payment: insufficient funds, invalid account, expired consent, duplicate reference
- A payment-level ID alongside the batch-level ID, so one failure can be looked up directly without re-scanning the batch
- No requirement to re-fetch or re-poll the whole batch just to find what went wrong
Without this, your support team ends up manually re-checking every failed line by hand.
Why Does Idempotency Matter More at Bulk Volume?
Idempotency keys matter for any payment API, but the stakes rise with volume. A retried single-payment request without an idempotency key risks one duplicate payment. A retried bulk request without one risks duplicating an entire batch.
The double-payment risk
Network timeouts happen. If your platform doesn’t know whether a submission actually reached the provider, the instinct is to retry. Without an idempotency key tied to that specific batch, a retry can submit the same 300 payments a second time.
Setting idempotency keys correctly
A dependable provider expects a unique idempotency key on every batch submission, stores it against the full request, and returns the original result, not a new payment, if the same key is submitted again. Test this before going live: submit the same batch twice with the same key and confirm only one set of payments is created.
How Should Webhooks Work for Bulk Runs?
A single webhook firing “batch complete” isn’t enough information to safely update hundreds of individual records.
Per-payment events versus batch-complete events
The more useful pattern is a webhook per payment, carrying the payment ID, previous status, new status and timestamp, alongside a final batch-summary event once every payment has been resolved. This lets your platform update records as they land instead of waiting for the slowest payment in the batch. The same status-event thinking applies to a standalone payout API, where the difference is scale rather than principle.
Ordering, retries and delivery guarantees
Bulk runs generate a burst of events. Your provider should sign every webhook, retry failed deliveries, and let your endpoint deduplicate on event ID rather than assume once-only, in-order delivery.
What Recipient Validation Should Happen Before Execution?
The cheapest failure to prevent is the one caught before submission. Checking account details, sort codes and payee names up front, before funds are reserved, avoids discovering an invalid account halfway through a 500-payment run, and reduces exceptions later as batch size grows.
What Should Reconciliation Output Look Like?
UK late payments cost businesses almost £11 billion a year, with an estimated £26 billion owed to businesses at any given time (GOV.UK, late payment consultation response). Slow, manual reconciliation is part of that problem: finance teams want a report they can match against their ledger, not a batch acceptance message.
Every payment in the response should carry a reference your platform already recognises, an invoice ID, payroll run ID or supplier reference, alongside amount, status and timestamp.
A payment processing API that only returns opaque provider IDs pushes the matching work back onto your finance team, which defeats the purpose of automating the run in the first place.
Integrating a Bulk Payment API Into Your Platform
For most SaaS, accounting, payroll and marketplace platforms, a bulk payment API sits behind existing approval workflows rather than replacing them. Your platform still owns the “who gets paid, how much, when” decision; the API executes it and reports back.
This is one part of a broader bank API integration: the payments side needs to work alongside banking data access to confirm funds have actually landed, not just that a payment was submitted.
Where Does Finexer Fit for Bulk Payment API Runs?
Finexer’s Payments product product is built for exactly this operator problem: running a bulk payment API where a single failure shouldn’t hide inside a batch or block the rest of the run.
| Capability | Detail |
|---|---|
| Payment initiation | Multi-recipient bulk runs submitted in a single API call |
| Status reporting | Per-payment webhook status as each one completes |
| Failure handling | Isolated per payment, the rest of the run continues |
| Reconciliation | References carried through to reconciliation output |
| Authorisation | FCA-authorised (FRN 925695) for AIS and PIS |
| Pricing | Transparent pricing (no hidden charges) |
To be clear about the boundary: Finexer is a payment processing API, not an accounting or payroll system. It doesn’t decide who gets paid, calculate amounts, or make reconciliation decisions for you. It executes the run and reports status on every payment as it happens, the core job of any bulk payment API.
If your platform sends supplier payments, payroll or refunds at volume, a bulk payment system built on Open Banking payment initiation and banking data together, rather than payments alone, gives finance teams a clearer view of what has actually landed, not just what was submitted.ather than payments alone, gives finance teams a clearer view of what has actually landed, not just what was submitted.
What is a bulk payment API?
It lets a platform submit many payment instructions in one call and receive per-payment status back, rather than a single result for the whole batch. It is built for volume, supplier runs, payroll, refunds, where checking each payment individually isn’t practical.
Is a bulk payment API the same as a payout API?
They overlap. A payout API typically covers sending money out to recipients, one-off or in bulk. This is specifically optimised for batch behaviour: partial failure handling, per-payment identifiers and batch-level idempotency, which matter less at single-payment volume.
Does it guarantee every payment in a batch succeeds together?
Not usually, and it shouldn’t. Most B2B use cases need per-payment handling, so one failed payment doesn’t block the rest of the run. Fully atomic batches (where the whole batch rolls back on any single failure) exist but are rarely what a payroll or supplier-payment workflow actually needs.
How does idempotency work at bulk volume?
Each batch submission carries a unique idempotency key. If the same key is submitted again, after a timeout or retry, the provider returns the original result instead of creating a new set of payments, preventing accidental duplicate runs.
Can a bulk payment API run over UK Open Banking rails?
Yes, but the receiving bank often controls whether a batch executes atomically or per-payment, and some banks require payees to already be recognised beneficiaries before a bulk instruction is accepted. This is worth checking directly with your provider rather than assuming card-style batch behaviour.
See how per-payment status and reconciliation references work for bulk payment runs on Finexer’s Open Banking infrastructure.
Explore with AI
About the Author
Ravi Ranjan
Ravi Ranjan is Co founder & CEO of Finexer