Tests

Ce qui passe sur le fil

• Où cela se situe

  Exactement là où se situera votre appel de production. Vous changez l’identifiant et le numéro de carte; les points de terminaison, les corps de requête et les formes de réponse restent les mêmes.

• Ce que vous envoyez

  Une requête de paiement ordinaire portant une carte test documentée. La référence liste chaque carte, la marque qu’elle imite et le résultat produit, y compris celles qui exigent une étape d’authentification.

• Ce qui revient

  La réponse même que votre intégration verra en production, suivie des mêmes événements de cycle de vie. Affirmez sur l’état et le code typé, pas sur le seul code HTTP.

Quand l’utiliser

• Avant la mise en production

  Chaque chemin de refus, le défi 3-D Secure et au moins un remboursement devraient être parcourus une fois, délibérément, plutôt que découverts par un client.

• En intégration continue

  Les exécutions sandbox rendent la logique de paiement testable en régression et attrapent le changement qui a discrètement cessé de traiter un code.

• Après toute montée de version

  Un SDK, un cadriciel ou un nouvel intergiciel peuvent casser la vérification de signature sans qu’une ligne de votre code de paiement ait bougé.

Mettre en œuvre Tests

Ce qui échoue, et comment vous l’apprenez

• Seul le scénario nominal est couvert

  Une intégration qui n’a jamais vu de refus en livrera un. La carte d’approbation prouve la connectivité; les cartes de refus prouvent que l’application traite vraiment le cas le plus fréquent.

• Des tests qui affirment sur le texte

  Le libellé ne fait pas partie du contrat et changera. Un test qui s’y accroche échoue sur une correction de style et passe sur une vraie régression.

• Des webhooks jamais exercés

  Si les tests n’appellent que l’API et lisent la réponse, le gestionnaire qui traite les commandes reste non testé. Faites passer au moins un test par l’événement, avec une relivraison volontaire.

• Des délais sandbox pris pour la production

  Le règlement est comprimé en sandbox. Un code qui suppose un versement quelques minutes après la capture restera inerte en production, où il suit votre calendrier de dépôt.

Sandbox par rapport à la production

• Le résultat est déterministe

  Aucun émetteur n’est joint. Une carte refusée pour fonds insuffisants l’est à chaque tentative, à toute heure : c’est cette propriété qui rend la logique de paiement affirmable en intégration continue.

• L’authentification est simulée, pas escamotée

  L’étape 3-D Secure s’exécute quand même; ce qui change, c’est qu’une carte test décide du passage sans friction ou du défi. Les deux branches sont donc atteignables sur demande.

• Rien ne se règle réellement

  Dépôts, frais et lots existent en sandbox pour écrire le code de rapprochement, mais ils sont illustratifs. Votre tarif réel et votre calendrier de versement viennent de votre compte.