Les prestataires de paiement entretiennent leur propre petit catalogue de cartes de test Stripe, et la raison est pratique plutôt que généreuse : un bac à sable incapable de produire un refus ne peut pas tester le chemin de code qui en gère un. De véritables identifiants de paiement ne peuvent jamais servir à cela, à la fois parce que c’est dangereux et parce que les résultats seraient imprévisibles, si bien que les prestataires publient des numéros dont le comportement est défini à l’avance par leurs propres systèmes.
Cet article explique ce que sont ces numéros, pourquoi un prestataire les publierait tout court, comment les refus et l’authentification sont simulés, et où commencent les limites d’une liste fournie par un prestataire.
Ce qu’est une carte de test de prestataire
Une carte de test est un numéro qu’un bac à sable de prestataire de paiement reconnaît. Lorsqu’il apparaît dans une demande de paiement, le bac à sable ne contacte aucune banque. Il recherche le numéro dans une table, décide quel doit être le résultat de la demande, et renvoie ce résultat — un succès, un motif de refus précis, ou une demande d’authentification supplémentaire.
Cette recherche est tout le mécanisme. Le numéro n’a pas besoin d’appartenir à quiconque, la date d’expiration n’a pas besoin d’être réelle tant qu’elle est dans le futur, et le code de sécurité n’est vérifié que par rapport aux formes que le bac à sable attend. Parce que le comportement est scénarisé plutôt que résolu, deux développeurs utilisant la même carte de test dans leurs propres comptes de bac à sable obtiennent le même résultat, ce qui rend reproductibles les rapports de bug sur les flux de paiement.
Pourquoi les prestataires de paiement publient-ils leurs propres numéros de test ?
Chaque passerelle met en œuvre sa propre interprétation des réponses des réseaux de cartes. Les codes de refus, les étapes d’authentification et le comportement de réessai diffèrent d’un prestataire à l’autre, et ces différences sont exactement ce qu’un test d’intégration doit exercer. Un numéro synthétique générique peut prouver qu’un formulaire accepte seize chiffres ; seul un numéro reconnu par le prestataire peut prouver que votre application gère la manière particulière dont ce prestataire dit que la carte a été refusée.
Il existe aussi un argument de sécurité. Les éditeurs veulent que les développeurs utilisent des numéros dont il est certain qu’ils ne résoudront vers aucun compte réel, dans n’importe quel environnement, sous n’importe quelle configuration. Une liste sélectionnée est la façon dont le prestataire garantit qu’un test en bac à sable ne peut pas devenir accidentellement une vraie transaction.
Le catalogue évolue à mesure que les prestataires ajoutent des fonctionnalités, donc la liste de référence est toujours la documentation du prestataire lui-même. Lisez-la là plutôt que de faire confiance à une version recopiée dans un article de blog ou un dépôt, y compris celui-ci.
L’unique carte de test que presque tous les développeurs utilisent
Parmi les numéros que Stripe documente, un est devenu le choix par défaut de fait : une valeur à seize chiffres qui commence par quatre et qui est formée en répétant le même court motif de quatre chiffres, un quatre suivi d’un deux, répété jusqu’à atteindre seize chiffres. Présenté avec n’importe quelle date d’expiration future et n’importe quel code de sécurité à trois chiffres, il produit un débit réussi dans le bac à sable.
Sa popularité est facile à comprendre. Il est mémorisable, il satisfait les règles de format qu’une vraie carte respecterait, et il permet à un développeur de parcourir tout un flux de paiement en quelques minutes après avoir commencé. C’est aussi la raison pour laquelle tant d’intégrations de paiement sont à peine testées, car un unique cas de succès ne dit rien de ce qui se passe lorsqu’un paiement est refusé.
Deux mises en garde méritent d’être énoncées clairement. Premièrement, ce numéro n’a de sens qu’à l’intérieur d’un bac à sable de prestataire ; le diriger vers une passerelle en production produit une autorisation échouée et une entrée dans les journaux de fraude de quelqu’un. Deuxièmement, un débit réussi en bac à sable est un résultat simulé, pas la preuve que la carte est réelle ou que le compte derrière elle existe — le bac à sable n’a jamais posé la question.
Comment simuler un refus ?
Les refus sont généralement pilotés par des numéros que le prestataire réserve à des résultats particuliers, et la liste couvre typiquement les cas sur lesquels le code d’intégration doit réellement bifurquer :
- Un refus générique, utilisé pour vérifier que le formulaire affiche une erreur récupérable plutôt qu’un plantage.
- Un refus qui indique que l’émetteur souhaite que le client le contacte, ce qui est une impasse pour le flux de paiement.
- Des fonds insuffisants, le seul refus qu’un utilisateur peut plausiblement corriger en utilisant une autre carte.
- Une réponse de carte expirée, qui teste si la validation de date de votre formulaire et la passerelle sont d’accord.
- Une erreur de traitement, qui devrait généralement être réessayée plutôt que présentée au client comme une réponse définitive.
- Un blocage de type fraude, qui devrait arrêter le flux plutôt que pousser l’utilisateur vers un réessai.
Chacun de ces cas mérite un chemin délibéré dans votre application : un message différent, une politique de réessai différente, et un enregistrement différent dans votre propre base de données. Utiliser un seul numéro de refus pour tous les cas masque les différences jusqu’à ce qu’un client en rencontre une.
Tester l’authentification et les flux 3-D Secure
Les paiements par carte modernes incluent souvent une étape où le client est redirigé, ou voit s’afficher un défi intégré, pour confirmer le paiement auprès de sa banque. Les bacs à sable simulent cela avec des numéros dédiés : certains déclenchent un défi toujours réussi, d’autres un défi toujours échoué, et d’autres encore un flux qui se termine sans aucun défi.
Les cas qui méritent d’être couverts portent rarement sur le chemin heureux. Que se passe-t-il lorsque le client abandonne le défi à mi-parcours et revient sur votre site ? Votre commande reste-t-elle indéfiniment dans un état en attente, ou se résout-elle vers un résultat définitif ? Une tentative répétée crée-t-elle une seconde commande ? L’authentification introduit une étape où votre système perd le contrôle de l’utilisateur pendant quelques secondes, et chaque intégration a au moins un bug dans cette fenêtre.
Pour les développeurs : des listes de scénarios valent mieux qu’un seul numéro magique
L’habitude à acquérir est de planifier la couverture de test comme une liste de résultats plutôt qu’une liste de numéros. Écrivez les états dans lesquels votre flux de paiement peut se terminer — autorisé, refusé de façon réessayable, refusé définitivement, authentification requise, authentification échouée, abandonné, expiré — puis trouvez une entrée de bac à sable pour chacun.
Conservez cette correspondance dans le dépôt à côté des tests, avec une note indiquant de quelle version de la documentation du prestataire elle provient, et révisez-la lorsque le prestataire met à jour son catalogue. Lorsqu’un incident de paiement est analysé plus tard, la correspondance est ce qui vous permet de dire quels états ont été exercés et lesquels n’ont jamais été couverts.
Quelques points plus mineurs font gagner du temps réel. Stockez les identifiants du bac à sable uniquement dans l’environnement de test, et vérifiez la configuration avant de lancer quoi que ce soit, car une carte de test contre une clé de production est exactement l’accident que toute cette pratique cherche à prévenir. Vérifiez le résultat que votre système a enregistré, pas seulement la réponse de la passerelle, car les bugs intéressants vivent entre les deux. Et décidez tôt comment vous distinguerez une transaction de bac à sable d’une transaction réelle dans vos propres tables, afin qu’un futur audit n’ait pas à deviner.
Générer des cartes sans compte de prestataire
Les catalogues de prestataires sont le bon outil lorsque vous avez besoin d’un résultat scénarisé, et le mauvais outil lorsque vous avez besoin de volume. Un formulaire qui doit accepter une centaine de cartes différentes, une démonstration qui devrait montrer une variété de réseaux, ou un jeu de fixtures qui couvre des longueurs et des préfixes sont mieux servis par des données générées.
Le générateur de numéros de carte de ce site produit des numéros pour un réseau choisi ou un mélange aléatoire, avec des dates d’expiration et des codes de sécurité fictifs, et aucun d’eux n’est lié à un compte. Chaque valeur est structurellement valide et n’a jamais été émise, donc elle sera acceptée par un contrôle de format et refusée par n’importe quelle vraie passerelle.
Utilisez les deux types de données pour des tâches différentes : les numéros de test du prestataire pour les résultats scénarisés de la passerelle, les numéros générés pour tout ce que la passerelle ne voit jamais. La comparaison des réseaux est utile lorsque vous avez besoin d’une carte de chaque marque, et la liste de contrôle du formulaire de paiement recense les flux dans lesquels ces cartes devraient apparaître.
Étapes suivantes
Rédigez la liste des résultats pour votre propre flux de paiement, associez chaque élément à une entrée de bac à sable issue de la documentation actuelle de votre prestataire, et ajoutez celles que vous ne pouvez pas encore produire à un arriéré visible. Générez ensuite un lot distinct de cartes synthétiques pour les tests au niveau du formulaire, afin que les deux types de données de test ne soient jamais confondus.