Refus de paiement par carte bancaire

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é.

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.

Codes de réseau

En cas de refus, l’émetteur de la carte fournit deux types de codes de réseau :

• Code d’avis du réseau : la banque émettrice de la carte fournit ce code à 2 ou 4 chiffres. Lorsque Stripe ne reçoit pas de code de réponse du réseau de cartes dans le cadre d’un paiement refusé, le champ network_decline_code est nul. La signification d’un code diffère selon le réseau de cartes. Par conséquent, tenez compte de la marque de la carte bancaire lorsque vous interpréterez le code.

• Code d’avis du réseau : la banque émettrice de la carte fournit ce code à 2 ou 4 chiffres, qui fait office de conseil sur la gestion d’un refus de paiement. Lorsque Stripe ne reçoit pas de code de réponse du réseau de cartes dans le cadre d’un paiement refusé, le champ network_advice_code est nul. La signification d’un code diffère selon le réseau de cartes. Par conséquent, tenez compte de la marque de la carte bancaire lorsque vous interpréterez le code. Pour Mastercard, les codes d’avis du réseau sont appelés codes MAC (Marchand Advice Code).

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. Utilisez Smart Retries pour relancer les paiements ayant échoué au moment le plus opportun. Sachez que les réseaux de cartes limitent le nombre de tentatives autorisées pour un même paiement. Nous recommandons un maximum de huit relances pour les paiements autorisant les relances. Les émetteurs de cartes 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égitime.

Dans l’API, le motif du résultat utilise des codes de refus de paiement pour vous indiquer pourquoi l’émetteur de la carte a refusé l’autorisation. Le code advice_code dans l’attribut outcome vous indique ensuite la marche à suivre.

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_intent.payment_failed se déclenche lorsqu’une tentative de paiement échoue.

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.

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.