Batch payments let you send many payments in one go. It’s a multi-step flow on a single endpoint, POST /v1/customers/{customerId}/batch-payments, where an action field selects the step. You verify the items, initiate to get a total and an authentication challenge, then submit with strong customer authentication.
Batch payments are an optional capability, enabled per program. If your program doesn’t have it, the endpoint isn’t available to you. See Program capabilities. Every call uses the user’s bearer token.

​
The items

Each item is one payment. Send the destination fields your program uses:
  • UK programs use accountNumber + sortCode.
  • EU programs use iban + bic.
{
  "payee": { "name": "Ada Lovelace", "accountNumber": "87654321", "sortCode": "040506" },
  "reference": "Invoice 1024",
  "amount": "150.00"
}
A reference (6–64 chars) and amount are required. Add scheduledDate (YYYY/MM/DD) to send an item on a future date.

​
The flow

  1. Verify — submit the items. We validate each one and run a name check on the payee (Confirmation of Payee for UK, Verification of Payee for EU). You get a requestId.
  2. Check status — poll until validation finishes. The result marks each item valid or invalid, with errors.
  3. Initiate — get the totalAmount, currency, and an scaChallenge for the set you’re sending.
  4. Submit — send the batch with the challenge plus a confirmation object (passkey, 2FA code, or PIN on supported programs). You get a batchId.
  5. Track — fetch the batch to watch each item move through QUEUED → SUCCESS or FAILED.

​
Status

A batch reports an overall status: CREATED, FUNDING_PENDING, FUNDED, PROCESSING, QUEUED, and the failure states FUNDING_FAILED and PARTIALLY_FAILED. Individual items are QUEUED, SUCCESS, or FAILED.
Pass an idempotencyKey (a UUID) on submit and reuse it if you retry, so a network error can’t send the batch twice.