Approves payment requests and raises their payments into a batch.

It answers with the payments it created. The decision is recorded, the batch is settled and
one payment per payee is raised before the response is written, so a payment named in results
is a payment that exists.

One payment per payee, not per request. Several requests approved for one payee are one
deposit and come back sharing a paymentId, which is why createdCount counts requests and
createdPaymentCount counts payments. Reading the first and calling it a number of payments
overstates what happened.

A 200 does not mean every request was paid. Two paths finish outside the call — a failure
worth retrying, and an approval that outran its budget — and those rows answer with
reservedPaymentId and no paymentId. For them the payment is genuinely only coming.

Approving twice converges. An already-approved request is accepted here, including one whose
payment is in flight or was refused: the reserved id makes the second call land on the same
payment rather than raise another. A repeated call does not pay twice.

The batch is all-or-nothing. A 4xx for the batch means no payment was raised for any request
in the call.

Errors

• 400 INVALID_REQUEST_IDS: requestIds is missing, empty, over 50, or holds duplicates
• 400 INVALID_LEDGER_ACCOUNT: ledgerAccount is missing or blank
• 400 INVALID_BATCH: batch names both an existing batch and a new one, or neither
• 400 INVALID_AMOUNT_OVERRIDE: amountOverride is not money, or arrived without fundingCurrencyCode
• 400 INVALID_SEND_IMMEDIATELY: sendImmediately is not a boolean
• 400 BATCH_CREATION_FAILED: the batch could not be created
• 404: the batch named does not exist
• 423 NOT_EDITABLE: the batch is archived, or a request named is in a state no payment can be raised from