Skip to main content

Lots de paiement

Les lots de paiement fournisseurs : les factures payées ensemble depuis un même compte débité et par un même canal. Un brouillon se crée et se modifie sur cette API, puis y est aussi envoyé pour approbation, approuvé ou refusé, et un lot approuvé y est également remis : submit pour un lot hosted_consent, sepa_export pour un lot sepa_file. Le state d'un lot et le status de ses instructions sont les seules preuves que l'argent a circulé - une remise au canal ne signifie jamais qu'il l'a fait.

📄️Submit a payment batch

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.

📄️Resume a payment batch's consent

Resumes the hosted consent of a `hosted_consent` batch that `submit` already handed over, and answers 200: nothing is created. Every call asks the payment provider again - an open consent gets a fresh `consent_url`, and a consent the provider has since accepted, timed out or refused moves the batch accordingly. It never sends the batch a second time. A batch whose consent is already resolved is answered from its current state without asking the provider. The body carries a bearer capability, so it is sent with `Cache-Control: no-store`, and this endpoint takes no `Idempotency-Key`: one that is sent is ignored, and nothing is stored or replayed.

📄️Confirm a settlement suggestion

Asserts that the bank operation settled the instruction. The pair is re-checked under lock with the suggestion controls (the batch's debit account, an outgoing operation, the same currency and exact amount, an operation no other instruction takes and no other invoice was reconciled against). The instruction's invoice is paid through the bank reconciliation - an existing reconciliation of that operation with that invoice is reused, never duplicated; an instruction paying no invoice is linked only. The instruction reads `settled` and the batch settles when every instruction did. Confirming the pair already confirmed answers the same 200.

📄️Confirm the bank operation that settled an instruction

Asserts that the bank operation settled the instruction. The pair is re-checked under lock with the suggestion controls (the batch's debit account, an outgoing operation, the same currency and exact amount, an operation no other instruction takes and no other invoice was reconciled against). The instruction's invoice is paid through the bank reconciliation - an existing reconciliation of that operation with that invoice is reused, never duplicated; an instruction paying no invoice is linked only. The instruction reads `settled` and the batch settles when every instruction did. Confirming the pair already confirmed answers the same 200. Use it for a result of `GET /payment_batches/{id}/settlement/candidates`, whatever its date.

📄️Undo an instruction's settlement reconciliation

Removes the link between the instruction and its bank operation, and only what the confirmation derived from it: the invoice payment it recorded is reversed (an exported accounting entry is corrected by a new entry, never rewritten). The payment at the bank is never cancelled and the bank's status reports are kept. Without a bank settlement report (ACSC) the instruction returns to `pending` - execution to confirm - keeps its invoice reserved and is never resubmitted, and a settled batch returns to `submitted`. Undoing an instruction that is not linked answers the same 200.

📄️Declare an instruction not executed

Declares that the payment of an instruction whose execution is to be confirmed (`execution_to_confirm_at` is set) was never executed, for a batch handed over as a SEPA file. The instruction reads `rejected`, carries the declaration, and its invoice is no longer reserved: a new batch may pay it. Nothing is resubmitted and the bank's status reports are kept. A batch paid through a bank consent is refused: only the bank's rejection or a confirmed bank operation resolves its instructions. Repeating the same declaration answers the same 200.

📄️Generate a payment batch's SEPA file

Generates the pain.001 file of an `approved` `sepa_file` batch through the same approval, reservation and single-attempt controls as the payment centre, and returns the export resource. **A 202 never means a payment was executed** - the batch reads `submitted` once the file is handed over, and only its instructions' `status` report what the bank did. A batch whose export was already requested is never generated again: the call answers the existing export, whatever `expected_version` it carries. The optional `expected_version` is the payment centre's version control: a batch that changed since you read it is refused rather than generated.

📄️Retrieve or download a payment batch's SEPA file

Returns the export resource as JSON. With `Accept: application/xml` and `state: available`, returns the file itself; before that, the JSON resource is returned instead. **Never generates a file**, and downloading one never means a payment was executed. Requires `write`, not `read`, because the file carries full beneficiary IBANs. Every download of the file, here or from the Scribee payment centre, is recorded and published as `served_count`, `first_served` and `last_served`; reading the JSON resource is not. Served means the bytes were sent in an HTTP response to that actor: it proves neither receipt, nor handover to the bank, nor bank execution.