curl --request POST \
--url https://api.next.orenda.finance/v1/customers/{customerId}/batch-payments/submit \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"action": "initiate",
"batchId": "3f1c8f9e-1d2b-4a3c-9e5f-6a7b8c9d0e1f",
"payments": [
{
"payer": {
"account": {
"type": "uk",
"sortCode": "010203",
"accountNumber": "12345678"
}
},
"payee": {
"name": "Ada Lovelace",
"account": {
"type": "uk",
"sortCode": "040506",
"accountNumber": "87654321"
}
},
"reference": "Invoice 1024",
"amount": "150.00"
}
]
}
'{
"success": true,
"totalAmount": "350.00",
"currency": "GBP",
"scaChallenge": {
"hash": "9f86d0...",
"nonce": "b1946ac9",
"timestamp": "2026-06-05T10:00:00Z"
}
}Initiate a batch
Get the total and an authentication challenge.
curl --request POST \
--url https://api.next.orenda.finance/v1/customers/{customerId}/batch-payments/submit \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"action": "initiate",
"batchId": "3f1c8f9e-1d2b-4a3c-9e5f-6a7b8c9d0e1f",
"payments": [
{
"payer": {
"account": {
"type": "uk",
"sortCode": "010203",
"accountNumber": "12345678"
}
},
"payee": {
"name": "Ada Lovelace",
"account": {
"type": "uk",
"sortCode": "040506",
"accountNumber": "87654321"
}
},
"reference": "Invoice 1024",
"amount": "150.00"
}
]
}
'{
"success": true,
"totalAmount": "350.00",
"currency": "GBP",
"scaChallenge": {
"hash": "9f86d0...",
"nonce": "b1946ac9",
"timestamp": "2026-06-05T10:00:00Z"
}
}POST /v1/customers/{customerId}/batch-payments/submit with action: "initiate" and the
batchId from verify (pick the initiate example below). You get
back the totalAmount, the currency, and an scaChallenge.
batchId is required here. This route only pays a batch that was verified first, so both
initiate and submit need the id verify returned. Omitting it is a 400. The older
unsuffixed route keeps the previous contract, where it is optional.scaChallenge into submit, along with a 2FA code or a
passkey, to authorise the batch.
initiate issues it, the user authenticates against the amount and payee, submit
presents it back — so both steps are the same privilege and the action field says which
one you’re on. action is required here; "verify" is rejected with 403.Send the same items to initiate and submit. The challenge is bound to the payee
account and amount of every row, in order, so adding, removing, reordering or re-pricing a
row between the two calls invalidates it.403 until yours is
enabled. Until then, send action: "initiate" to
POST /v1/customers/{customerId}/batch-payments — the request and response bodies are
identical. See the overview.Authorizations
The caller's id_token from authentication — the ID token, not the access_token. The program and environment come from the token.
Path Parameters
The customer id.
Body
Required — initiate, passkey-challenge or submit. verify is rejected with 403; it belongs to the /batch-payments/verify route.
initiate, passkey-challenge, submit The payment items. Required for initiate and submit, and must be identical between them or SCA verification fails.
Show child attributes
Show child attributes
The strong-customer-authentication challenge from initiate. Pass it back on submit.
Show child attributes
Show child attributes
Step-up confirmation (for submit). Set method to passkey, totp, or pin and include that method's fields. pin is a program capability — see Program capabilities.
- Passkey
- 2FA code
- PIN
Show child attributes
Show child attributes
Optional UUID. Reuse the same key to make submit safe to retry — batch and item IDs are then derived deterministically, so a retry cannot double-pay.
Required. The draft returned by verify. This route only pays a batch that was verified first, so initiate and submit both need it. It is checked for expiry and ownership and cannot be paid twice.
Response
Result for the requested step — initiate → totalAmount/currency/scaChallenge; passkey-challenge → passkeySession/fido2options; submit → batchId/status/counts.
The response is of type object.