L’API de la passerelle
Une API de paiement dont la documentation est produite à partir de la même table qui sert les requêtes : la référence ne peut donc jamais décrire un point de terminaison que la plateforme n’a pas.
Développeurs qui intègrent le paiement dans une boutique, un système de facturation, une place de marché, une plateforme scolaire ou le logiciel d’une institution.
Fait partie de la plateforme elle-même : présent partout où BitriPay tourne.
Le problème
Intégrer un paiement, c’est d’habitude lire une documentation vraie le trimestre dernier, découvrir le comportement réel dans les messages d’erreur, et écrire une logique de reprise parce que l’idée que le prestataire se fait de l’idempotence est une suggestion.
Comment cela fonctionne
- Créez une intention de paiement avec un montant, une devise et votre référence.
- Envoyez le client vers son adresse de paiement, ou affichez son contenu QR.
- Agissez sur la notification signée quand le paiement réussit ou se règle.
- Rapprochez avec le relevé ; chaque objet porte la référence que vous lui avez donnée.
Ce que vous pouvez vérifier
Des faits sur la plateforme en fonctionnement, pas des adjectifs. Chacun est visible dans le produit, dans la référence de l’API ou dans le grand livre.
- Le document OpenAPI et la référence lisible sont produits à partir d’une seule table d’opérations : ils ne peuvent pas se contredire.
- Chaque POST qui déplace de l’argent exige une clé d’idempotence : un rejeu renvoie l’objet d’origine, et la même clé avec un corps différent est refusée.
- Les notifications sont signées deux fois — HMAC-SHA256 sur le corps horodaté, et une signature Ed25519 de la plateforme — et réessayées selon un calendrier publié sur 24 heures.
- Les erreurs portent un code descriptif et une famille numérique stable : un logiciel peut brancher sur la famille sans analyser de l’anglais.
- Un bac à sable avec des numéros magiques documentés pilote la vraie machine d’états, échecs compris, sans toucher à un opérateur.
Ce que cela coûte
L’API ne coûte rien. Vous payez les paiements qu’elle déplace, au tarif de votre compte.
Questions
Comment tester un échec ?
Le bac à sable publie des numéros magiques qui produisent des issues précises — succès, solde insuffisant, délai dépassé puis succès — à travers la même machine de tentatives qu’en production. Vous testez les chemins malheureux sans opérateur et sans faire semblant.
Que se passe-t-il si mon serveur réessaie un paiement ?
Envoyez la même clé d’idempotence et vous récupérez l’objet d’origine au lieu d’un second paiement. La même clé avec un corps différent est refusée nettement, ce qui transforme un bug dangereux en une erreur lisible.
Comment savoir qu’une notification vient bien de vous ?
Chaque livraison porte un HMAC horodaté sur le corps exact avec le secret de votre point de terminaison, plus une signature Ed25519 de la clé de plateforme que vous pouvez récupérer dans le registre. Vérifiez l’une ou les deux, et rejetez tout ce qui a plus de cinq minutes.
À lire ensuite
Notifications signées
Des livraisons que vous pouvez vérifier de deux façons indépendantes, rejouer vous-même depuis le tableau de bord, et recevoir sur une boîte intégrée si vous n’avez encore nulle part où héberger un point de terminaison.
Comptes connectés
Créez les comptes marchands de vos clients par API, encaissez pour eux avec votre propre clé, gardez votre commission — et transmettez le compte dès qu’ils sont prêts, clés et historique intacts.
Page de paiement hébergée
Une page de paiement qui ne propose au payeur que les rails capables de conclure réellement son paiement, décidés au moment où il arrive plutôt qu’énumérés avec optimisme sur une page.