SDK et extensions
Des SDK dans trois langages et une extension de boutique générés depuis la même table d’opérations que l’API, pour qu’un SDK ne puisse pas décrire un appel que la plateforme n’a pas.
Développeurs qui préfèrent livrer cette semaine, et commerçants qui veulent une page de paiement sans embaucher.
Fait partie de la plateforme elle-même : présent partout où BitriPay tourne.
Le problème
Chaque intégration réimplémente la même plomberie, et chaque réimplémentation est une nouvelle occasion de se tromper subtilement sur la vérification des notifications, d’une façon que personne ne remarque avant que cela ne compte.
Comment cela fonctionne
- Installez le SDK de votre langage, ou l’extension de votre boutique.
- L’authentification, l’idempotence et la vérification de signature sont prises en charge pour vous.
- Créez une intention et traitez la notification avec des objets typés plutôt que du JSON brut.
- Testez contre le bac à sable avec les nombres magiques documentés avant d’approcher un vrai paiement.
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.
- 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.
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.
À lire ensuite
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.
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.
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.