Submit a payment batch
POST/api/v1/payment_batches/:id/submit
Hands an approved hosted_consent batch to its channel and answers 202 with the batch. A 202 never means the money moved: poll GET /payment_batches/{id} and its instructions. submission_status says what became of the handover - awaiting_consent while the payer's consent is open, unknown when the channel's answer was lost, refused with the batch failed - and none of those is a cancellation. The consent URL is never returned here: POST /payment_batches/{id}/consent_session publishes it. expected_version is required. A sepa_file batch is handed over by POST /payment_batches/{id}/sepa_export instead. Submitting a batch already accepted by its channel changes nothing and answers 202 again.
Request
Responses
- 202
- 403
- 404
- 409
- 422
The batch, handed over. Read submission_status: a 202 never means the money moved.
The token lacks the write scope.
No payment batch with this id is reachable by the token's grants.
stale_version: the batch changed since the expected_version you sent. NOTHING WAS SENT; details carries the current version and batch. idempotency_key_reuse, idempotency_request_in_progress and idempotency_key_consumed also answer 409, with no details.
batch_not_submittable: the batch is not approved, already carries a handover attempt, is still being submitted by another request, or is a sepa_file batch. validation_failed: the Idempotency-Key header or expected_version is missing, expected_version is not an integer, an instruction's invoice can no longer be reserved, or Scribee refused the batch before anything was sent - an incomplete batch the channel would not build, or a local configuration or request error on the payment channel. That last refusal leaves the batch failed with submission_refused_by: "local"; details.instructions carries a message saying so, plus the violations for an incomplete batch. Nothing was sent, and no bank outcome is recorded.