• curl
  • Node.js
  • TypeScript
  • Python
  • PHP
  • Ruby
  • Go
  • Java
  • C#
  • Rust
Tableau de bord
Tableau de bord

Bac à sable

Cartes de test

Des numéros de carte qui réussissent, sont refusés, demandent le 3-D Secure ou répondent tard sur la page de paiement simulée du mode test.

Ouvrir en Markdown

En mode test, la page de paiement par carte est une simulation marquée TEST. Elle accepte les numéros ci-dessous et rien d’autre : tout autre numéro est refusé avec « utilisez une carte de test », et n’est jamais enregistré. Une vraie carte ne marche jamais en mode test.

Tapez un numéro sur la page, ou touchez-le dans la liste de la page. Si la page demande une date d’expiration ou un code de sécurité, mettez n’importe quelle date future et trois chiffres quelconques. Pour payer sans navigateur, envoyez le même numéro à l’assistant de test complete.

Les numéros

Numéro de carteExpirationtoute date futureCVC3 chiffres quelconquesScénarioRésultat
4242 4242 4242 4242Expiration12/34CVC123Succès

Réussit tout de suite.

4000 0000 0000 3220Expiration12/34CVC1233-D Secure

Une page 3-D Secure simulée s’ouvre. Approuver : réussit. Échouer : refusé, authentication_failed.

4000 0000 0000 0002Expiration12/34CVC123Refusée

Refusé, card_declined.

4000 0000 0000 9995Expiration12/34CVC123Fonds insuffisants

Refusé, card_declined avec le code de refus insufficient_funds.

4000 0000 0000 0069Expiration12/34CVC123Carte expirée

Refusé, expired_card.

4000 0000 0000 0119Expiration12/34CVC123Erreur de traitement

Échoue, processing_error.

4000 0000 0000 0077Expiration12/34CVC123Confirmation lente

Réussit après 60 secondes ; jusque-là, le paiement n’est pas confirmé.

4000 0000 0000 0085Expiration12/34CVC123Notifications répétées, dans le désordre

Réussit une seule fois, bien que la confirmation parvienne à AdProMaxPay plusieurs fois et dans le désordre.

4000 0000 0000 0093Expiration12/34CVC123Confirmation perdue

Aucune confirmation n’arrive jamais : le paiement ne réussit pas, et la tentative expire au bout d’environ 30 minutes.

Après un refus, l’intention de paiement revient à requires_payment_method, avec la raison dans last_payment_error, et vous recevez payment_intent.payment_failed. Votre client peut essayer une autre carte sur la même page.

Ce que chaque scénario enseigne

  • Succès et Refusée : votre page pour une commande payée et votre page pour une commande échouée.
  • 3-D Secure : l’étape en plus qu’une banque peut demander. Votre code ne fait rien de particulier ; la page hébergée s’en charge.
  • Confirmation lente : votre client est de retour sur votre success_url avant que le paiement ne soit confirmé. Affichez « Nous confirmons votre paiement », et livrez sur le webhook, pas sur le retour.
  • Notifications répétées : vous recevez quand même un seul événement payment_intent.succeeded, même si une livraison de webhook peut elle-même arriver deux fois : voir la déduplication.
  • Confirmation perdue : un paiement peut finir sans argent même après le passage de votre client sur la page de paiement. Ne livrez jamais avant succeeded.

Le tableau complet des statuts est dans Le fonctionnement des paiements. Ce qui diffère encore de la production est dans Bac à sable et production : les différences.