Numéros de Carte de Test 2026 — Braintree, Stripe, PayPal, Square
Numéros de carte de crédit de test (dummy) à jour pour Braintree, Stripe, PayPal et Square. Classés par marque et scénario succès/échec, avec copie en un clic pour des tests rapides.
| Service | [[ labels.col_number ]] | [[ labels.col_brand ]] | [[ labels.col_behavior ]] | |
|---|---|---|---|---|
| [[ card.service ]] | [[ formatNumber(card.number) ]] | [[ card.brand ]] [[ labels['subtype_' + card.subtype] ]] | [[ behaviorLabel(card.behavior) ]] |
Que sont les numéros de carte de test ?
Lorsque vous développez une fonctionnalité de paiement, vous devez pouvoir reproduire des résultats comme « réussi », « fonds insuffisants » ou « carte volée » sans utiliser de carte réelle. Pour cela, chaque prestataire de paiement publie un ensemble de numéros de carte fixes, associés côté serveur à des résultats précis. Cette page rassemble les numéros de test actuels de Stripe, PayPal, Square et Braintree, classés par marque et par résultat, afin que vous puissiez filtrer ce dont vous avez besoin et le copier en un clic.
Ces numéros n'ont de sens que dans un environnement sandbox. Tant que vous les associez à une clé API de test, aucun débit réel n'est jamais généré ; en revanche, si vous les associez à une clé de production, la transaction est simplement refusée, car les systèmes en production ne reconnaissent jamais ces numéros comme de vraies cartes. Changez toujours de clé et de numéro ensemble, et gardez à l'esprit que les prestataires mettent parfois à jour leurs numéros de test — si un comportement diffère de ce qui est décrit ici, consultez la documentation officielle du prestataire.
Comment utiliser cette liste
- Choisissez l'onglet du service de paiement Sélectionnez le prestataire que vous intégrez (Stripe, PayPal, Square ou Braintree) pour n'afficher que ses numéros dans le tableau.
- Filtrez selon le résultat recherché Utilisez les filtres Succès, Échec ou 3D Secure pour isoler le scénario que vous testez, par exemple un chemin de gestion d'erreur.
- Copiez le numéro de carte Cliquez sur Copier à côté d'une ligne pour placer ce numéro dans le presse-papiers, prêt à coller directement dans un formulaire de paiement.
- Renseignez le CVC et la date d'expiration N'importe quel chiffre convient pour le CVC (4 chiffres pour Amex) et n'importe quelle date future convient pour l'expiration : aucune valeur exacte n'est requise.
Astuces pour en tirer le meilleur parti
- En mode test de Stripe, n'importe quel CVC à 3 chiffres (4 pour Amex), toute date d'expiration future et tout code postal à 5 chiffres seront acceptés. Aucun débit réel n'est effectué tant que vous utilisez des clés de test.
- Tous les numéros de carte de test sont conçus pour passer la vérification de Luhn (algorithme de validation des numéros de carte) et ne seront donc pas rejetés par la validation côté client.
- Pour tester le 3D Secure (3DS), utilisez des cartes dédiées.
4000002500003155déclenche le dialogue d'authentification, et4000000000003220est utilisé pour le flux 3DS 2. - L'utilisation de numéros de carte de test en production entraînera un refus de transaction. Utilisez toujours des clés de test avec des cartes de test. Chez Stripe, les clés de test commencent par
sk_test_.
Cas d'usage courants
Vérifier une nouvelle intégration de paiement
Juste après avoir branché un formulaire de paiement, tester un numéro qui réussit confirme que vos clés et la structure de la requête sont correctes avant d'aller plus loin.
Construire la gestion des erreurs
Les numéros associés aux fonds insuffisants, aux cartes expirées ou aux erreurs de CVC permettent de vérifier que chaque échec affiche le bon message au client.
Tester les parcours 3D Secure
Les numéros dédiés au 3DS permettent de suivre le dialogue d'authentification jusqu'à la redirection vers votre application, une étape souvent négligée lors de l'implémentation.
Documenter des plans de tests QA
Coller directement la correspondance entre numéro et résultat dans un script de test évite aux testeurs de devoir chercher les numéros à chaque exécution.
Générer des fixtures pour des suites de tests automatisées
Les mêmes numéros fixes peuvent être intégrés comme fixtures dans l'intégration continue afin que les parcours de paiement soient vérifiés de manière cohérente à chaque build.
Glossaire des tests de paiement
- Clé de test
- Une clé API valable uniquement dans un environnement sandbox. Les clés de test Stripe commencent par
sk_test_; leur utilisation garantit qu'aucun argent réel n'est déplacé. - Sandbox
- Un environnement entièrement séparé de la production, où vous pouvez reproduire librement des succès et des échecs sans toucher à de vrais fonds.
- Vérification de Luhn
- Une formule de somme de contrôle qui vérifie si les chiffres d'un numéro de carte forment une séquence valide. Elle détecte les fautes de frappe mais ne peut pas confirmer qu'une carte existe réellement.
- BIN / IIN
- Les six à huit premiers chiffres d'un numéro de carte, qui identifient la banque émettrice et le réseau de la carte avant même que le reste du numéro soit vérifié.
- CVC / CVV
- Le code de sécurité à 3 chiffres (4 pour Amex) imprimé sur la carte. Les environnements sandbox acceptent n'importe quel chiffre à sa place.
- 3D Secure
- Une étape supplémentaire de vérification d'identité affichée pendant le paiement. Des numéros de test dédiés déclenchent ce dialogue afin que vous puissiez tester le parcours complet.
- Autorisation
- Un blocage temporaire sur une carte permettant de confirmer que des fonds sont disponibles. Le débit réel n'est finalisé que lors d'une étape ultérieure, la capture.
Questions fréquentes
sk_test_), aucun débit réel ne sera effectué. Si vous utilisez accidentellement une clé de production, la transaction sera tentée même avec des numéros de test — veillez donc à ne pas les confondre.
Anecdote — L'algorithme de Luhn — Le gardien des numéros de carte depuis 1954
Le « chiffre de contrôle » à la fin d'un numéro de carte de crédit est validé par un algorithme créé en 1954 par l'ingénieur d'IBM Hans Peter Luhn. Un chiffre sur deux en partant de la droite est doublé, tous les chiffres sont additionnés, et le résultat doit être divisible par 10. Cet algorithme simple est encore utilisé par les grandes marques telles que Visa, Mastercard et Amex, et détecte la grande majorité des erreurs de frappe.
Cependant, la vérification de Luhn sert uniquement à détecter les erreurs de chiffres — elle ne vérifie pas si la carte existe réellement. L'utiliser dans la validation côté client est uniquement une amélioration de l'expérience utilisateur (retour d'erreur immédiat) et ne prévient pas la fraude. L'autorisation réelle doit toujours être effectuée côté serveur via une passerelle de paiement.
Les numéros de carte de test sont des numéros fixes que chaque service de paiement a délibérément conçus pour passer la vérification de Luhn. Par exemple, le 4242424242424242 de Stripe est facile à retenir et passe la validation de Luhn. Le numéro lui-même n'a aucune signification propre — il est simplement associé à un comportement (comme « succès » ou « échec ») dans le système de Stripe.