Paiement fournisseur (supplier_payment)
Représente un décaissement fournisseur piloté par Ormuz ou un mouvement inverse rattaché à ce décaissement, sans confondre l’instruction créée par le processus avec l’exécution réellement observée sur le rail de paiement.
Rôle
supplier_payment appartient au contexte Accounts Payable : il décrit un mouvement entre le marchand et un fournisseur. Il est distinct de payment, qui représente du cash entrant côté client, et de psp_payment, qui porte une exécution via un PSP côté encaissement.
type vaut payment pour un décaissement fournisseur et refund pour le mouvement inverse reçu d’un fournisseur. Le montant reste toujours positif ; le sens est porté par le type et la relation au mouvement d’origine.Instruction et exécution sont deux faits différents
Ormuz peut créer l’instruction en pending ou scheduled. L’état executed ou failed correspond au résultat du rail de paiement ; cancelled reste une fin explicite avant exécution réussie.
La création de l’objet exprime l’intention de décaissement. Pour un type=payment, l’API n’autorise la création qu’enpending ou scheduled. Le passage à executed ou failed intervient ensuite lorsque l’exécution est connue.
executed pour signifier « à payer ». Utilisez l’état d’instruction, puis laissez l’intégration de paiement ou l’opération habilitée constater l’exécution réelle.Cycle de vie
| Statut | Signification | Suite habituelle |
|---|---|---|
pending | Instruction créée, pas encore planifiée ou exécutée. | Contrôles, approbation, envoi au rail de paiement. |
scheduled | Exécution prévue pour une date ou une fenêtre future. | Attendre l’exécution ou annuler si elle reste annulable. |
executed | Le décaissement est considéré exécuté. | Créer les allocations AP et rapprocher le mouvement avec les documents concernés. |
failed | L’exécution n’a pas abouti. | Traiter l’incident, corriger la cause, éventuellement créer une nouvelle instruction. |
cancelled | L’instruction a été annulée avant sa complétion normale. | Ne pas poursuivre les étapes qui supposent un cash effectivement sorti. |
Le payment_date est la date métier prévue ; value_date est renseignée lorsque la date de valeur d’exécution est connue.provider_reference conserve la référence attribuée par le rail externe.
Mouvements inverses fournisseur
Un supplier_payment de type=refund représente un retour de fonds lié à un paiement fournisseur d’origine. Il référence obligatoirement ce mouvement via source_supplier_payment_id. Le remboursement est créé comme executed, car ce type représente un mouvement inverse déjà constaté plutôt qu’une nouvelle instruction à exécuter.
Ormuz suit le cumul remboursé sur le paiement parent et refuse qu’un ensemble de remboursements exécutés dépasse le montant d’origine. Cela préserve une relation explicite entre le cash sorti et les retours de fonds ultérieurs.
Champs clés
| Champ | Rôle |
|---|---|
supplier_id | Fournisseur destinataire du décaissement. |
type | payment ou refund ; porte le sens économique du mouvement. |
source_supplier_payment_id | Paiement fournisseur d’origine pour un mouvement inverse. |
amount | Montant positif en unité mineure de la devise. |
payment_method | transfer, direct_debit, card ou manual. |
reference | Référence métier lisible du paiement. |
end_to_end_reference | Référence de bout en bout transmise sur les rails qui la supportent. |
source_reference | Identité stable dans le système source, utilisée pour la corrélation/idempotence. |
API et processus
Le node Core create_supplier_payment crée une instruction de paiement fournisseur depuis un processus. Les extensions de paiement peuvent ensuite matérialiser ou constater l’exécution selon leurs capacités.
POST /v1/supplier-payments
{
"merchant_id": "mer_0123456789abcdef0123456789abcdef",
"type": "payment",
"supplier_id": "cmp_0123456789abcdef0123456789abcdef",
"amount": 125000,
"currency": "EUR",
"payment_method": "transfer",
"status": "scheduled",
"payment_date": "2026-09-30",
"reference": "Supplier invoice SINV-2048"
}GET /v1/supplier-payments/{id}
GET /v1/supplier-payments?supplier_id=cmp_...&status=scheduled
POST /v1/supplier-payments/{id}/execute
POST /v1/supplier-payments/{id}/fail
POST /v1/supplier-payments/{id}/cancel
POST /v1/supplier-payments/{id}/refundÉvénements
Les transitions importantes sont observables comme événements plateforme :
supplier_payment.createdsupplier_payment.scheduledsupplier_payment.executedsupplier_payment.failedsupplier_payment.cancelled
Lorsque l’exécution doit réduire une dette fournisseur, utilisez une payment_allocation avec source_type=supplier_payment afin que le rapprochement reste explicite et réversible.