Refus de paiement par carte bancaire
En savoir plus sur les refus de carte et comment réduire votre taux de refus.
Les paiements par carte bancaire bancaire peuvent échouer pour diverses raisons, dont voici les plus fréquentes :
Fonds du client insuffisants : si les fonds ou le crédit d’un client sont insuffisants, l’émetteur de la carte refuse la transaction. Pour limiter les refus de paiement dus à des fonds insuffisants, envisagez d’ajouter une option de paiement différé.
Données de carte bancaire erronées : si un client saisit un numéro de carte bancaire, un CVV ou une date d’expiration incorrects, l’émetteur de la carte peut refuser la transaction. Dans ce cas, demandez à votre client de saisir à nouveau les informations de sa carte bancaire.
Activité frauduleuse : lorsqu’un émetteur de carte soupçonne une activité frauduleuse, qui peut être déclenchée par des achats importants ou un volume important de transactions sur une courte période, il peut refuser les paiements. Votre client doit résoudre ce problème en communiquant avec sa banque émettrice et en confirmant son identité.
Stripe Sigma
Utilisez Stripe Sigma pour analyser votre taux de refus de paiement. Notre environnement de reporting SQL interactif propose des requêtes préconfigurées à cet effet. Pour analyser les refus en dehors de Sigma, utilisez les empreintes d’identification de l’objet Card
plutôt que les ID de paiement, de façon à exclure les tentatives répétées.
Refus de paiement par carte bancaire
Lorsque l’émetteur de la carte de votre client reçoit un paiement, ses systèmes et modèles automatisés décident de l’autoriser ou non. Ces outils analysent des indicateurs tels que les habitudes d’achat, le solde du compte et les données des cartes, notamment la date d’expiration, l’adresse et le CVC.
Si l’émetteur de la carte refuse un paiement, nous vous communiquons certaines des informations que nous recevons concernant ce refus. Ces informations sont disponibles dans le Dashboard et via l’API. Parfois, les émetteurs fournissent des explications précises, comme un numéro de carte erroné ou une insuffisance de fonds. Ces explications apparaissent sous forme de codes de refus de paiement.
Les émetteurs de cartes considèrent la plupart des refus comme génériques (generic_decline), ce qui ne permet pas de connaître clairement le motif du refus. Si les informations de la carte sont correctes, demandez à votre client de contacter l’émetteur de sa carte pour comprendre pourquoi une transaction a été refusée. Pour des raisons de confidentialité et de sécurité, les émetteurs de cartes dévoilent uniquement les détails d’un refus à leurs titulaires de carte.
Diminuer les refus de paiements
Vous pouvez généralement résoudre les refus de paiement causés par des informations de carte erronées (un numéro de carte ou une date d’expiration incorrects, par exemple) en demandant à vos clients de corriger l’erreur ou d’utiliser une autre carte ou un autre moyen de paiement. Par exemple, Checkout fournit des commentaires au client lorsqu’une carte bancaire est refusée, ce qui lui permet de réessayer.
Pour éviter les refus dus à une suspicion d’activité frauduleuse, demandez à vos clients de fournir leur CVC et leur code postal au moment du paiement. L’impact des autres données que vous collectez, telles que l’adresse de facturation complète, peut varier selon la marque de carte et le pays. Si vous continuez à observer des taux de refus élevés, Stripe vous recommande de recueillir des informations supplémentaires sur vos clients. Vous pouvez également implémenter 3D Secure pour authentifier les paiements, ce qui peut réduire les taux de refus dans les pays prenant ce protocole en charge.
Pour savoir clairement pourquoi l’émetteur de la carte a refusé la carte lors d’un refus de paiement générique ou do_not_honor, examinez les données associées. Par exemple, si les vérifications du CVC ou du service de vérification d’adresse (AVS) échouent lorsque votre client ajoute une carte, demandez à votre client de vérifier ces deux informations avant d’initier un autre paiement.
Si vous remarquez qu’un client utilise une carte émise dans un pays donné tout en opérant à partir d’une adresse IP dans un autre pays, il peut s’agir d’un refus légitime lié à une éventuelle utilisation non autorisée de la carte. Cependant, des exceptions peuvent s’appliquer, en particulier lorsque les clients voyagent à l’étranger et utilisent leurs cartes depuis différents lieux.
Restrictions par type de carte bancaire
Certaines des cartes de vos clients comportent des restrictions concernant le type d’achat qu’elles autorisent. Les cartes FSA ou HSA sont souvent limitées à certains types de fournisseurs (par exemple, aux prestataires de soins de santé). Les émetteurs de cartes refusent alors tout autre type d’achat. Par ailleurs, certains émetteurs de cartes n’autorisent pas les achats dans certains pays, ou ne permettent aucun achat à l’international. Dans tous les cas, votre client doit contacter l’émetteur de sa carte pour savoir si elle comporte des restrictions et, le cas échéant, connaître la nature de ces restrictions.
Incidences de la localisation géographique
Si vos clients utilisent des cartes émises dans d’autres pays que celui dans lequel votre compte Stripe est inscrit, ils peuvent faire l’objet d’un taux de refus de paiement plus élevé. La meilleure façon de résoudre ce problème est d’inviter vos clients à contacter leur banque émettrice pour autoriser le paiement. Si vos clients sont concentrés dans certaines régions du monde, il peut également être judicieux de configurer des comptes Stripe dans vos marchés les plus importants, ou dans les pays où votre taux de refus de paiement est le plus important, afin de pouvoir traiter ces paiements localement.
Relances de cartes refusées
Lorsqu’un paiement est refusé, Stripe explique le motif du refus et suggère brièvement une solution.
Paiement refusé en raison de fonds insuffisants
Si vous utilisez Stripe Billing, vous pouvez créer un calendrier de relance personnalisé pour les abonnements. Si vous passez à Billing Scale, utilisez l’outil de relance intelligente Smart Retries pour relancer les paiements ayant échoué au moment le plus opportun. Nous recommandons un maximum de quatre relances pour les paiements autorisant les relances. Les émetteurs de carte peuvent considérer la création de nouvelles tentatives comme une fraude potentielle, ce qui peut entraîner une augmentation des refus de paiement légitimes.
Gérer les refus de paiement de manière programmatique
Il existe plusieurs manières de gérer les refus de paiement de manière programmatique :
- Récupérez la propriété last_payment_error.decline_code depuis l’objet PaymentIntent pour découvrir pourquoi l’émetteur de cartes a refusé la tentative de paiement.
- Exécutez à nouveau les tentatives de paiement du PaymentIntent et examinez le message d’erreur.
- Utilisez des webhooks pour suivre les mises à jour de l’état des PaymentIntents. Par exemple, l’événement
payment_
se déclenche lorsqu’une tentative de paiement échoue.intent. payment_ failed
Vous devrez peut-être également gérer d’autres situations d’échec de paiement, par exemple lorsque votre client est présent (pendant une session) ou absent (hors session) pendant votre processus de paiement. Lors du développement de votre intégration, Stripe vous conseille de traiter toutes les exceptions d’API possibles, y compris les erreurs inattendues.
Note
Stripe Billing est capable de gérer de nombreux scénarios d’échec de paiement grâce à des fonctionnalités comme l’encaissement automatique et les factures hébergées.
Refus de paiement pendant une session
Si votre client est présent sur votre site Web ou dans le tunnel de paiement de votre application, invitez-le à essayer de nouveau son moyen de paiement ou à en utiliser un autre.
Refus de paiement hors session
Si votre client n’est pas disponible pour effectuer un paiement ou modifier un moyen de paiement, invitez-le (par e-mail ou via une notification d’application, par exemple) à se rendre sur votre site Web ou dans votre application pour le faire. Si votre entreprise est concernée par des réglementations comme l’authentification forte du client, les tentatives de paiement peuvent également nécessiter une authentification et échouer avec le code de refus de paiement authentication_required. Pour en savoir plus sur la gestion de ce type de scénario, consultez notre documentation relative aux paiements hors session avec des cartes enregistrées.