SDK

Ce qui passe sur le fil

• Où il se situe

  Entre votre application et l’interface REST. Il construit la requête, attache l’identifiant et la version d’API, applique la politique de relance et transforme la réponse en objet typé vérifiable par votre compilateur.

• Ce que vous configurez

  Une clé secrète propre à l’environnement, la version d’API à fixer et un délai d’attente. Le reste a une valeur par défaut documentée. La référence de votre langage donne les options et les noms de méthode exacts.

• Ce qu’il vous rend

  Un modèle typé de la ressource en cas de succès, une erreur typée portant le même code que l’API brute en cas d’échec. Votre logique reste identique; le SDK vous épargne l’analyse.

Quand l’utiliser

• Intégration côté serveur

  Les modèles typés attrapent les erreurs de schéma à la compilation plutôt qu’en production, surtout sur les corps de requête écrits une fois et jamais relus.

• Acceptation mobile

  Les SDK mobiles gèrent la saisie de carte et la tokenisation sans que les données de carte touchent votre code : c’est ce qui garde une application hors du périmètre PCI.

• Équipes sans spécialiste des paiements

  Les utilitaires de relance et de signature encodent des décisions faciles à rater subtilement et coûteuses à rater en silence.

Mettre en œuvre SDK

Ce qui échoue, et comment vous l’apprenez

• Une version de SDK flottante

  Une dépendance non fixée peut changer la version d’API visée et donc la forme des réponses, sans aucun changement chez vous. Fixez le paquet et la version d’API séparément.

• Une relance par-dessus la relance

  Une couche externe qui ne porte pas la clé d’idempotence transforme une relance sécuritaire en deux débits indépendants. Une seule couche doit posséder les relances.

• Un corps analysé avant l’utilitaire de signature

  L’utilitaire a besoin des octets bruts. Un cadriciel qui a déjà désérialisé la requête fera échouer chaque vérification, et le SDK ne peut pas vous en avertir.

• Une erreur typée captée trop largement

  Capter globalement et journaliser le message jette le code dont dépend le reste de votre traitement. Captez l’erreur typée, aiguillez sur le code, puis journalisez.

Sandbox par rapport à la production

• Un client, deux configurations

  Le même SDK parle aux deux environnements; seul l’identifiant change. Construire le client à partir de la configuration plutôt qu’en dur rend la bascule un changement de déploiement, pas de code.

• Le comportement de relance est observable

  Provoquer un échec relançable en sandbox est le seul moyen pratique de voir l’utilitaire relancer et de confirmer que vos journaux consignent une seule opération logique.

• Les SDK mobiles utilisent la clé publiable sandbox

  Une version mobile pointée sur le sandbox tokenise des cartes test. La livrer ainsi produit des jetons que la production ne peut pas facturer : la clé appartient à la configuration de build.