Aller au contenu principal

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.

📄️Soumettre un lot de paiement

Remet un lot `hosted_consent` `approved` à son canal et répond 202 avec le lot. **Un 202 ne signifie jamais que l'argent a circulé** : interrogez `GET /payment_batches/{id}` et ses instructions. `submission_status` dit ce qu'il est advenu de la remise - `awaiting_consent` tant que le consentement du payeur est ouvert, `unknown` lorsque la réponse du canal a été perdue, `refused` avec le lot `failed` - et aucun de ces états n'est une annulation. L'URL de consentement n'est jamais retournée ici : `POST /payment_batches/{id}/consent_session` la publie. `expected_version` est obligatoire. Un lot `sepa_file` se remet plutôt par `POST /payment_batches/{id}/sepa_export`. Soumettre un lot déjà accepté par son canal ne change rien et répond de nouveau 202.

📄️Reprendre le consentement d'un lot de paiement

Reprend le consentement hébergé d'un lot `hosted_consent` que `submit` a déjà remis, et répond 200 : rien n'est créé. Chaque appel interroge de nouveau le prestataire de paiement - un consentement ouvert reçoit une nouvelle `consent_url`, et un consentement que le prestataire a depuis accepté, laissé expirer ou refusé fait évoluer le lot en conséquence. Le lot n'est jamais envoyé une seconde fois. Un lot dont le consentement est déjà résolu est répondu depuis son état courant, sans interroger le prestataire. Le corps porte une capacité au porteur : il est envoyé avec `Cache-Control: no-store`, et cet endpoint ne prend pas d'`Idempotency-Key` : une clé envoyée est ignorée, et rien n'est enregistré ni rejoué.

📄️Lire les suggestions de règlement d'un lot de paiement

Retourne une ligne par instruction du lot, par `payment_instruction_id` croissant, sans pagination. Chaque ligne liste les opérations bancaires qui ressemblent au règlement de l'instruction : même compte, sortantes, même devise, montant exact, comptabilisées de 5 jours avant à 10 jours après la date d'exécution prévue (à défaut, la date de remise). Ce sont des SUGGESTIONS à examiner - aucune ne marque une instruction ou une facture comme payée.

📄️Chercher les opérations bancaires qui ont pu régler une instruction

Une recherche manuelle sur une plage de dates de votre choix, hors de la fenêtre d'examen s'il le faut, avec les mêmes contrôles que les suggestions de règlement : le compte débité par le lot, une opération sortante, la même devise, le montant exact, et une opération qu'aucune autre instruction ni aucune facture n'a prise. Les résultats sont triés par date d'opération, sans pagination, et jamais enregistrés : rien n'est suggéré, et rien n'est marqué payé.

📄️Confirmer une suggestion de règlement

Affirme que l'opération bancaire a réglé l'instruction. La paire est contrôlée de nouveau sous verrou avec les contrôles des suggestions (le compte débité par le lot, une opération sortante, la même devise et le montant exact, une opération qu'aucune autre instruction ne prend et qu'aucune autre facture n'a rapprochée). La facture de l'instruction est payée par le rapprochement bancaire - un rapprochement existant de cette opération avec cette facture est repris, jamais dupliqué ; une instruction qui ne règle aucune facture est seulement rapprochée. L'instruction se lit `settled` et le lot est réglé quand chaque instruction l'est. Confirmer la paire déjà confirmée répond le même 200.

📄️Confirmer l'opération bancaire qui a réglé une instruction

Affirme que l'opération bancaire a réglé l'instruction. La paire est contrôlée de nouveau sous verrou avec les contrôles des suggestions (le compte débité par le lot, une opération sortante, la même devise et le montant exact, une opération qu'aucune autre instruction ne prend et qu'aucune autre facture n'a rapprochée). La facture de l'instruction est payée par le rapprochement bancaire - un rapprochement existant de cette opération avec cette facture est repris, jamais dupliqué ; une instruction qui ne règle aucune facture est seulement rapprochée. L'instruction se lit `settled` et le lot est réglé quand chaque instruction l'est. Confirmer la paire déjà confirmée répond le même 200. Utilisez-la pour un résultat de `GET /payment_batches/{id}/settlement/candidates`, quelle que soit sa date.

📄️Annuler le rapprochement de règlement d'une instruction

Retire le lien entre l'instruction et son opération bancaire, et seulement ce que la confirmation en avait tiré : le paiement de facture qu'elle a enregistré est annulé (une écriture comptable exportée est corrigée par une nouvelle écriture, jamais réécrite). Le paiement n'est jamais annulé à la banque et les comptes rendus de statut de la banque sont conservés. Sans compte rendu d'exécution de la banque (ACSC), l'instruction revient à `pending` - exécution à confirmer -, garde sa facture réservée et n'est jamais remise de nouveau, et un lot réglé revient à `submitted`. Annuler une instruction qui n'est pas rapprochée répond le même 200.

📄️Déclarer une instruction non exécutée

Déclare que le paiement d'une instruction dont l'exécution est à confirmer (`execution_to_confirm_at` est renseigné) n'a jamais été exécuté, pour un lot remis sous forme de fichier SEPA. L'instruction passe à `rejected`, porte la déclaration, et sa facture n'est plus réservée : un nouveau lot peut la régler. Rien n'est remis de nouveau et les comptes rendus de statut de la banque sont conservés. Un lot payé par consentement bancaire est refusé : seuls le rejet de la banque ou une opération bancaire confirmée résolvent ses instructions. Répéter la même déclaration répond le même 200.

📄️Générer le fichier SEPA d'un lot de paiement

Génère le fichier pain.001 d'un lot `sepa_file` `approved` au travers des mêmes contrôles d'approbation, de réservation et de tentative unique que le centre de paiement, et retourne la ressource d'export. **Un 202 ne signifie jamais qu'un paiement a été exécuté** - le lot passe à `submitted` une fois le fichier remis, et seul le `status` de ses instructions rend compte de ce que la banque a fait. Un lot dont l'export a déjà été demandé n'est jamais généré une seconde fois : l'appel répond avec l'export existant, quelle que soit l'`expected_version` qu'il porte. L'`expected_version` facultative est le contrôle de version du centre de paiement : un lot qui a changé depuis votre lecture est refusé au lieu d'être généré.

📄️Lire ou télécharger le fichier SEPA d'un lot de paiement

Retourne la ressource d'export en JSON. Avec `Accept: application/xml` et `state: available`, retourne le fichier lui-même ; avant cela, c'est la ressource JSON qui est retournée. **Ne génère jamais de fichier**, et télécharger un fichier ne signifie jamais qu'un paiement a été exécuté. Exige `write`, et non `read`, parce que le fichier porte les IBAN complets des bénéficiaires. Chaque téléchargement du fichier, ici ou depuis le centre de paiement Scribee, est enregistré et publié dans `served_count`, `first_served` et `last_served` ; la lecture de la ressource JSON ne l'est pas. Servi signifie que les octets ont été envoyés dans une réponse HTTP à cet acteur : cela ne prouve ni leur réception, ni leur remise à la banque, ni l'exécution par la banque.