Vue d’ensemble
Un paiement qui a atteintSUCCESS 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
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êteContent-Type — un reçu est un PDF ou une image selon le facturier.
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.totalInterrogation du statut
Atteindre un état final
Obtenir la transaction par ID
Où apparaît
operationId
