BitriPay
ONE QR. ONE GATEWAY. EVERY ELIGIBLE RAIL.Pay Local. Fund Global. Settle Your Way.
développeurs

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

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.

construire sur bitripay sdk et extensions
Try it with a free account

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.

Open an account

Keep reading