L’intégration la plus rapide est celle que vous n’avez pas à écrire
L’essentiel d’une intégration est le même à chaque fois : authentification, idempotence, vérification de signature, reprises. Les SDK et une extension de boutique font cette partie, et ils sont construits depuis la même table qui sert les requêtes.
Regardez deux intégrations de paiement quelconques et l’essentiel du code est identique.
L’authentification. Les clés d’idempotence. La vérification de signature. Les reprises avec temporisation. La traduction des erreurs vers quelque chose que votre application comprend.
Rien de cela n’est votre produit. Tout cela doit être juste.
La partie qui est toujours fausse
La vérification de la signature des notifications est l’endroit où les intégrations écrites à la main échouent, et elles échouent en silence.
Erreurs courantes, toutes observées en production : comparer des signatures avec une comparaison de chaînes normale au lieu d’une comparaison à temps constant ; vérifier contre le corps analysé plutôt que contre les octets bruts ; oublier de contrôler l’horodatage, ce qui laisse le rejeu grand ouvert ; contrôler l’horodatage mais ne jamais rejeter dessus.
Chacune de ces erreurs produit une intégration qui fonctionne parfaitement en test et qui est fausse d’une façon qui ne compte que le jour où quelqu’un vous attaque.
Le SDK le fait correctement, une fois.
Généré depuis la même table
Les SDK sont générés depuis la même table d’opérations qui sert les requêtes et produit la documentation.
Un SDK ne peut donc pas décrire un appel que la plateforme n’a pas. Ce n’est pas une surcouche maintenue à la main qui dérive lentement derrière l’API — c’est un autre rendu de la même chose.
Lorsque quelque chose de tout neuf n’a pas encore atteint un SDK, l’appel brut fonctionne toujours. Le SDK est une commodité, jamais un péage.
Aucune dépendance
Le SDK Node n’en a aucune.
Ajouter les paiements à votre projet ne devrait pas ajouter une chaîne d’approvisionnement, une série mensuelle d’avis de sécurité, et une montée de version à planifier. Moins vous installez de choses pour encaisser, moins il y a de choses qui peuvent mal tourner d’une façon que vous n’avez pas choisie.
Pour les boutiques
L’extension WooCommerce est livrée dans le dépôt plutôt que publiée à part : sa version correspond à l’API contre laquelle elle a été construite.
Un commerçant l’installe, saisit une clé, et encaisse. Aucun développeur requis dans le cas courant.
Testez d’abord les échecs
Chaque SDK fonctionne contre le bac à sable, et le bac à sable publie des nombres magiques pour des issues précises — y compris un dépassement de délai qui réussit ensuite.
Écrivez votre gestionnaire contre celui-là d’abord. C’est le cas qui trouvera le défaut dans votre logique de reprise, et il est beaucoup moins coûteux à trouver un mardi après-midi que pendant votre premier week-end chargé.
Ce que cela coûte
Rien. Code ouvert dans le dépôt, pas de licence.
Ce que vous pouvez vérifier
Ce sont 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.
- Les SDK sont générés depuis la même table d’opérations qui sert les requêtes : ils ne peuvent pas décrire un appel que la plateforme n’a pas.
- La vérification de la signature des notifications est implémentée dans le SDK, là où la plupart des intégrations artisanales se trompent.
- L’extension de boutique est livrée dans le dépôt plutôt que distribuée à part : sa version correspond à l’API contre laquelle elle a été construite.
- Le SDK Node n’a aucune dépendance : ajouter les paiements n’ajoute pas une chaîne d’approvisionnement.
Ce que cela coûte
Gratuit. Code ouvert dans le dépôt, et aucune licence pour les utiliser.
Est-ce activé ?
La disponibilité dépend des autorisations en place et de ce que l’administrateur d’un déploiement donné a activé. Cela change, un article non — la réponse vivante est donc sur la page de la fonctionnalité, qui la lit dans la plateforme elle-même : SDK et extensions sur la page des fonctionnalités.
À lire ensuite
- L’API de la passerelle — Trois appels et une notification.
- Notifications signées — Votre logiciel l’apprend avant votre client.
- Page de paiement hébergée — Une page qui ne propose que ce qui marchera.
Frequently asked questions
Suis-je obligé d’utiliser un SDK ?
Non. L’API est du HTTP simple avec du JSON et elle est documentée entièrement. Les SDK existent pour vous épargner d’écrire une nouvelle fois la vérification de signature, pas pour cacher quoi que ce soit.
Quels langages ?
Node, PHP et Python, plus une extension WooCommerce pour les boutiques. Le SDK Node n’a délibérément aucune dépendance.
Le SDK va-t-il prendre du retard sur l’API ?
Il est généré depuis la même table d’opérations que celle qui sert l’API : il ne peut pas décrire un appel qui n’existe pas. Lorsqu’une toute nouvelle capacité n’a pas encore atteint un SDK, l’appel brut fonctionne toujours.
Send with a QR code, add money by card or mobile money, issue a virtual card. Sandbox balances let you explore before any real money moves.
Keep reading
The fastest integration is one you do not have to write
Most of an integration is the same every time: authentication, idempotency, signature verification, retries. SDKs and a shop plugin do that part, and they are built from the same table that serves the requests.
Comment construire pour un switch auquel on n’est pas encore raccordé
Attendre qu’un système publie son profil avant d’écrire la moindre ligne gaspille un an. Écrire contre un contrat interne, avec un simulateur pour les cas pénibles, fait du raccordement un codec plutôt qu’une reconstruction.
Comment un paiement décide par où passer
Un paiement peut généralement voyager par plusieurs chemins, et ils ne sont pas tous aussi bons à deux heures du matin. Router sur le succès mesuré, le coût et la latence — avec un disjoncteur sur les rails défaillants — fait la différence entre la résilience et une mauvaise nuit.