Skip to main content

Vue d’ensemble

Un paiement qui a atteint SUCCESS laisse deux preuves : operationId, la référence propre du facturier pour la transaction, et le fichier du reçu. Ensemble, ils tranchent n’importe quel litige qu’un client soulèvera des mois plus tard. Cette étape couvre le téléchargement et le stockage des deux, ainsi qu’une routine quotidienne qui prouve que votre comptabilité et la nôtre concordent.

Ce qu’un succès vous donne

receiptUrl exige votre en-tête X-Access-Token. Ce n’est pas un lien que vous pouvez envoyer par e-mail à un client ou intégrer dans une page. Téléchargez les octets et servez-les depuis votre propre système.

Télécharger le reçu

Récupérez-le dans la même étape que celle qui enregistre le succès, et déduisez l’extension du fichier de l’en-tête Content-Type — un reçu est un PDF ou une image selon le facturier.
Un reçu n’existe que pour une transaction SUCCESS. Tout le reste — encore en cours, FAILED, REFUNDED, ou appartenant à un autre partenaire — répond 404 NOT_FOUND dans l’enveloppe JSON habituelle.

Le stocker

1

Télécharger une seule fois, au moment du règlement

Récupérez le reçu dans la même étape que celle qui marque votre commande comme payée. Réessayer plus tard est acceptable, mais n’attendez pas qu’un client le demande.
2

Stocker les octets, pas l'URL

Placez le fichier dans votre propre stockage d’objets, indexé par l’identifiant de votre commande. L’URL de l’API exige votre clé et n’est utile à personne d’autre.
3

Stocker operationId à côté

Le reçu est le document ; operationId est la référence. Conservez les deux dans l’enregistrement de la commande.
4

Le servir derrière votre propre authentification

Votre client le télécharge chez vous, pas chez nous.

Rapprocher une journée

GET /v3/bills/transactions avec from et to vous donne tout ce qui s’est passé dans une fenêtre. Bornez la fenêtre — une liste non bornée grandit avec votre activité, et une liste bornée ne peut pas se décaler sous vos pieds pendant que vous paginez.

Ce que signifie chaque écart

Ne rapprochez que sur SUCCESS et REFUNDED. Une transaction FAILED n’a jamais déplacé d’argent, et une découverte PENDING ou READY n’a jamais rien débité.

Une routine quotidienne

1

Exécuter une fois par jour, pour la veille

Bornez la fenêtre avec from et to. La veille est complète ; aujourd’hui bouge encore.
2

Faire correspondre sur ref

Votre ref est la clé de jointure entre nos transactions et vos commandes. C’est à cela qu’il sert.
3

Additionner SUCCESS et REFUNDED séparément

Le mouvement net vaut les totaux SUCCESS moins les totaux REFUNDED. Les deux doivent figurer dans votre grand livre.
4

Reporter les transactions ouvertes

Tout ce qui est encore PENDING, PROCESSING ou UNKNOWN reste sur la liste jusqu’à sa résolution.
5

Alerter sur le moindre écart

Un rapprochement qui ne trouve rien doit rester silencieux. Un rapprochement qui trouve quelque chose doit alerter quelqu’un.

Bonnes pratiques

Conserver les deux preuves

operationId et le fichier du reçu. L’un sans l’autre n’est qu’une demi-réponse à un litige.

Rapprocher chaque jour, pas chaque mois

Une fenêtre d’une journée est assez petite pour être examinée à la main. Un mois ne l’est pas.

Ne jamais clôturer une transaction ouverte

UNKNOWN et PROCESSING se résolvent d’eux-mêmes. Reportez-les au lieu de les passer en perte.

Servir les reçus vous-même

Derrière votre propre authentification, depuis votre propre stockage. Ne partagez jamais l’URL de l’API.

Étape suivante

Étape 6 : Tests en sandbox

Reproduisez chaque résultat à la demande, puis passez en production en toute confiance

Pages associées

Télécharger le reçu

La référence de l’endpoint

Lister les transactions

Filtres, pagination et meta.total

Interrogation du statut

Atteindre un état final

Obtenir la transaction par ID

Où apparaît operationId