Passerelle de paiement conviviale pour développeurs, autorisation et capture

REST est la surface supportée avec documentation OpenAPI.

Limites production évoluent avec volume. Sandbox plus bas pour tests.

Échecs relancés avec backoff exponentiel pendant 72 heures.

Publication carte directe exige SAQ D. Champs hébergés réduisent à SAQ A.

Vous joignez une clé unique à la requête. Si le réseau tombe avant que vous ne voyiez la réponse et que votre code reprend avec la même clé, la passerelle renvoie le résultat original au lieu de créer un second débit. La reprise devient sûre, ce qui constitue l'habitude la plus utile dans une intégration de paiement.

Des bibliothèques serveur officielles couvrent Node, Python et PHP, et une collection Postman est offerte aux équipes d'assurance qualité. Aucune n'est obligatoire : la passerelle est une API REST documentée en OpenAPI, donc n'importe quel client HTTP convient. Les SDK vous épargnent surtout l'écriture du code de signature et de traitement des erreurs.

Le sandbox reproduit le comportement réel pour autoriser, encaisser, annuler, rembourser et générer un jeton, y compris la livraison des webhooks : les chemins d'intégration et d'erreur se testent de bout en bout. Les limites de débit y sont plus basses qu'en production, qui suit le volume. Testez-y jusqu'à ce que la reprise et le traitement des refus soient justes, pas seulement le scénario idéal.

Les livraisons échouées sont reprises avec un délai exponentiel pendant 72 heures. Vérifiez la signature HMAC de chaque événement pour qu'un rappel falsifié ne puisse pas modifier l'état de vos commandes, et écrivez des gestionnaires idempotents, car une reprise peut livrer un événement que vous avez déjà traité.