Analyses des paiementsVersion bêta publique
Découvrez les facteurs d'acceptation des paiements par carte bancaire, les motifs d'échec ou de refus de paiement, et comment optimiser votre taux de réussite des paiements.
On the Payments analytics page in the Stripe Dashboard, you can analyze your payment success rate, authorization rate, and payments to find out where exactly payments fail, why they fail, and how to use this information to increase your revenue. To view your analytics, go to Payments > Analytics > Acceptance.
Public preview
Payments analytics is in public preview. If you want access to the public preview, we invite you to join the waitlist.
Understand payment attempts
Lorsque vos clients tentent d’effectuer un paiement, Stripe envoie les données du paiement aux réseaux de cartes, comme Visa, Mastercard ou China UnionPay. Ces réseaux de cartes transmettent ensuite les requêtes aux banques émettrices de cartes pertinentes, qui autorisent ou refusent le paiement.
Une tentative de paiement peut échouer à plusieurs étapes, avant même qu’un paiement ne soit envoyé au réseau de cartes. Par exemple, elle peut échouer à l’authentification 3D Secure (3DS) ou être bloquée par Radar. Une fois le paiement envoyé au réseau de cartes, les émetteurs peuvent le refuser pour plusieurs raisons, comme l’insuffisance de fonds sur le compte de la carte ou des informations de carte erronées. Parfois, les émetteurs refusent à tort des paiements légitimes en raison d’une suspicion de fraude.
Les analyses de paiement fournissent les données suivantes pour les paiements par carte bancaire :
- Les taux de réussite des paiements et d’autorisation du réseau, que vous pouvez visualiser sous forme brute ou hors doublons
- Les plans croisés dynamiques pour les éléments courants (également disponibles sous forme de filtres)
- Les motifs des échecs de paiement (problème d’authentification, blocage ou motifs de refus du réseau de cartes)
- La hausse des taux générée par les fonctions d’optimisation des paiements de Stripe
Données disponibles
Data on this page includes attempted and authorized card payments. Authorized volume figures don’t take into account whether the payments were ultimately captured. Learn more about the distinction between authorization and capture.
Les filtres situés en haut de la page de paiement s’appliquent à tous les indicateurs, graphiques et tableaux de la page.
Stripe traite vos données quotidiennement de 12 h 00 UTC à 23 h 59 UTC. Toutes les données affichées sont en UTC.
The Currency
filter is set to your settlement currency by default. To change the currency, click Currency , and select the currency you want from the list.
You can download all of the data used to generate the report. To download these analytics, click Download at the top of each chart.
Downloads provide payments that match the filters at the top of the report. The download dialog is only set to one currency filter (by default, the currency of the business).
Si vous utilisez Sigma, vous pouvez afficher vos données dans Sigma et avoir accès aux requêtes spécifiques utilisées pour générer chaque graphique.
Définitions des indicateurs
Vous pouvez examiner vos analyses à l’aide de deux indicateurs : le taux de réussite des paiements ou le taux d’autorisation.
Taux de réussite des paiements
Le taux de réussite des paiements mesure l’aboutissement de toutes les tentatives de paiement à travers toutes les étapes du processus de paiement : authentification 3D Secure, blocages Stripe ou Radar, et autorisation du réseau de cartes. Il s’agit du nombre de paiements autorisés par le réseau de cartes divisé par le nombre de tentatives de paiement uniques soumises via Stripe. Nous incluons toutes les tentatives de paiement à l’exception des appels à l’API non valides.
Taux d’autorisation
Le taux d’autorisation du réseau mesure l’aboutissement des tentatives de paiement qui parviennent aux réseaux de cartes bancaires. Il s’agit du nombre de paiements autorisés par l’émetteur de la carte divisé par le nombre de tentatives de paiement uniques soumises au réseau de cartes pour autorisation. Les appels à l’API non valides, les paiements qui échouent à l’authentification 3D Secure et les paiements bloqués sont exclus du dénominateur, car ces échecs se produisent avant que Stripe n’envoie la demande d’autorisation à l’émetteur.
Tableau comparatif
Le tableau suivant montre quels types de tentatives de paiement sont pris en compte dans les deux indicateurs.
Taux de réussite des paiements | Taux d’autorisation | |
---|---|---|
Requêtes API non valides | ||
Échec des paiements avec authentification 3D Secure | ||
Paiements bloqués | ||
Refus par l’émetteur | ||
Paiements autorisés |
Exemples de calculs
Voici un exemple de calcul du taux d’autorisation et du taux de réussite des paiements.
Composant de calcul | Valeur du composant |
---|---|
TOTAL DES DEMANDES DE PAIEMENT À STRIPE | 103 000 |
Requêtes API non valides | (3 000) |
Requêtes API non valides | 100 000 |
Échec des tentatives d’authentification | (1 000) |
Tentatives de paiement bloquées | (1 000) |
Nombre total de tentatives de paiement reçues par le réseau de cartes | 98 000 |
Paiements autorisés | 93 000 |
Taux de réussite des paiements | 93 % = (93 000 / 100 000) |
Taux d’autorisation du réseau | 94,9 % = (93 000 / 98 000) |
Taux hors doublon par rapport aux taux bruts
Certaines tentatives de paiement sont des tentatives répétées du même achat unique. Exemple : la première tentative de paiement d’un client est refusée, car il a saisi le mauvais CVC. Il soumet à nouveau le paiement après avoir corrigé son erreur. Nous incluons dans le calcul toutes les tentatives, à l’exception des requêtes API non valides. Le taux brut comptabilise toutes ces tentatives pour effectuer le même achat, tandis que le taux hors doublons regroupe les nouvelles tentatives et calcule le taux d’acceptation sur la base du résultat final.
Les tableaux suivants présentent des exemples de calculs en utilisant le taux hors doublons et le taux brut.
Lorsque vous consultez les taux hors doublons, vous pouvez constater une baisse temporaire de vos taux de réussite ou d’autorisation pour le mois écoulé si toutes les tentatives de paiement n’ont pas encore été effectuées. Par défaut, le rapport est défini sur Hors doublons, car il représente plus précisément le nombre d’achats uniques autorisés. Pour inclure les tentatives répétées, passez en mode Brut.
Vous pouvez également programmer vous-même des tentatives répétées, une pratique connue sous le nom de « relance », qui est courante pour les entreprises ayant des revenus récurrents. Si vous effectuez une relance par le biais de Stripe Billing, Stripe met en évidence la partie concernée du graphique en utilisant vos paramètres de facturation.
Comment Stripe identifie les tentatives répétées
Pour les paiements via Stripe Invoices, nous regroupons les tentatives de paiement sur la même facture. Pour les paiements avec des clients, nous regroupons les tentatives de paiement d’un même montant rapprochées dans le temps effectuées pour le même client. Pour tous les autres paiements, nous regroupons sur un même numéro de carte les tentatives de paiement d’un même montant rapprochées dans le temps.
Rapport sur les indicateurs clés
Ce rapport présente les principales mesures pour les filtres que vous avez choisis, notamment le taux, le nombre de paiements autorisés et le volume de paiements autorisés. La série chronologique compare le taux à une previous_
, que vous pouvez personnaliser. Par défaut, la période de comparaison commence juste avant la période que vous avez choisie et représente la même durée.
Rapport sur les paiements
Le rapport sur les paiements vous permet de visualiser les indicateurs d’acceptation des cartes bancaires en fonction de plusieurs facteurs d’acceptation courants. Chacun des filtres de niveau supérieur est accompagné d’un plan croisé dynamique correspondant. En associant les fonctionnalités de filtrage aux plans croisés dynamiques du tableau des paiements, vous bénéficiez d’une vue qui vous permet de suivre les performances de différents groupes de paiements au fil du temps. Vous pouvez passer d’un onglet à l’autre pour comparer les taux, les ventilations du nombre de paiements (en nombres absolus ou en pourcentage des paiements) et les volumes de paiements.
Utilisez tous ces onglets pour voir comment les changements de taux sont liés aux changements dans le nombre de paiements ou le volume. Vous pouvez approfondir les tendances que vous souhaitez explorer avec Sigma ou utiliser le téléchargement détaillé pour filtrer les attributs de frais disponibles. Par exemple, un test des cartes bancaires peut entraîner une réduction du taux et un pic soudain du nombre de paiements.
Analysez les paiements à travers de nombreuses options, telles que les marques de cartes, les pays ou les méthodes de saisie utilisées par vos clients pour payer.
Type de carte bancaire
En moyenne, les taux de réussite des cartes de crédit sont plus élevés que les taux de réussite des cartes de débit, qui sont eux-mêmes plus élevés que les taux de réussite des cartes prépayées. Cela s’explique généralement par le fait que les paiements effectués avec des cartes de débit et des cartes prépayées sont plus susceptibles d’être refusés en raison d’une insuffisance de fonds pour effectuer les achats.
Pays de la carte bancaire
Le pays de la carte bancaire fait référence au pays de l’émetteur de la carte, plutôt qu’à la localisation physique de votre client au moment du paiement. En moyenne, les taux de réussite des paiements nationaux sont plus élevés que ceux des paiements internationaux (lorsque le pays de la carte et votre entreprise sont situés dans des régions différentes). Ce plan croisé dynamique peut également vous aider à identifier où sont basés vos clients.
Type de transaction
Les réseaux de cartes divisent les paiements par carte en deux types, selon que le client est présent ou non dans le tunnel de paiement : les transactions initiées par le client (CIT) et les transactions initiées par le marchand (MIT). Les émetteurs de cartes attribuent des caractéristiques et des profils de risque différents à ces types de transactions, de sorte que les taux de réussite peuvent varier d’un type à l’autre.
Méthode de saisie
Les portefeuilles électroniques comme Apple Pay et Android Pay ont généralement des taux de réussite plus élevés que les paiements par carte en ligne classiques, car ils sont tokenisés et authentifiés par l’appareil, ce qui renforce la confiance de l’émetteur de la carte.
Si vous utilisez Stripe Terminal, vous pouvez également voir l’option Carte présente comme méthode de saisie, ce qui représente les paiements par TPE. Sur l’ensemble du secteur, les taux de réussite des paiements « carte présente » sont généralement plus élevés que ceux des paiements « carte non présente ». Pour les paiements par TPE, la carte bancaire doit être présente au moment de l’achat, de sorte que ces paiements présentent souvent des profils de risque moins élevés pour les émetteurs de cartes que les paiements en ligne.
État de la carte bancaire enregistrée
Vous pouvez utiliser les informations de carte précédemment enregistrées pour débiter les clients ultérieurement. Cette possibilité est le plus souvent utilisée pour les abonnements. Les cartes bancaires enregistrées sont également appelées « Credential-on-File » (CoF). Les taux de réussite sont généralement plus élevés pour les cartes enregistrées que pour les cartes non enregistrées.
Réponse code postal
Le service de vérification d’adresse (AVS) est un outil de vérification d’identité qui permet aux entreprises de détecter et d’empêcher les paiements potentiellement frauduleux par carte bancaire en comparant l’adresse de facturation fournie par un client avec l’adresse de facturation enregistrée auprès de l’émetteur de la carte du client, afin de confirmer qu’elles correspondent. La prise en charge en charge de la vérification d’adresse est principalement assurée par les émetteurs de cartes aux États-Unis, au Canada et au Royaume-Uni.
Le tableau suivant présente des exemples de valeurs pour l’indicateur réponse code postal.
Valeur | Définition |
---|---|
Non envoyé | Le code postal n’a pas été envoyé aux réseaux de cartes |
Valide | Le code postal a été envoyé aux réseaux de cartes et a été validé |
Échec | Le code postal a été envoyé aux réseaux de cartes et n’a pas été validé |
Non vérifié | Le code postal a été envoyé aux réseaux de cartes, mais aucune validation n’a été effectuée |
Réponse CVC
Le CVC (également appelé CVV) est le numéro de vérification à trois ou quatre chiffres imprimé directement sur une carte bancaire, généralement sur la bande de signature ou au recto de la carte. Lorsqu’un paiement par carte est soumis à un réseau de cartes pour autorisation, Stripe envoie le CVC s’il est fourni. Comme pour AVS, l’émetteur de la carte vérifie le CVC en se basant sur les informations dont il dispose sur le client à titre de vérification supplémentaire. Si les informations fournies ne correspondent pas, la vérification du CVC échoue, ce qui peut entraîner un refus de paiement. L’échec de la vérification du CVC peut indiquer que le paiement est frauduleux. Il convient donc de l’examiner attentivement avant de procéder au traitement de la commande.
Le tableau suivant présente des exemples de valeurs pour l’indicateur réponse CVC.
Valeur | Définition |
---|---|
Non envoyé | Le CVC n’a pas été envoyé aux réseaux de cartes |
Valide | Le CVC a été envoyé aux réseaux de cartes et a été validé |
Échec | Le CVC a été envoyé aux réseaux de cartes et n’a pas été validé |
Non vérifié | Le CVC a été envoyé aux réseaux de cartes, mais aucune validation n’a été effectuée |
Utilisation de tokens de réseau
Un token de réseau est une donnée non sensible, sous la forme d’un numéro à 16 chiffres se substituant au numéro affiché au recto de la carte bancaire (ou numéro PAN). Une fois associé à un cryptogramme, un token de réseau peut être inclus dans le message d’autorisation envoyé au réseau de carte bancaire, en lieu et place du numéro PAN.
Contrairement aux PAN, les tokens de réseau sont des justificatifs de paiement qui peuvent être dynamiquement restreints à des entreprises et à des canaux spécifiques, réduisant ainsi les risques et l’impact des failles de sécurité et des intrusions potentielles. Les entreprises utilisent également les tokens de réseau pour augmenter leur taux d’autorisation. Les réseaux contiennent le dernier mappage entre les tokens de réseau et les PAN, de sorte que Stripe peut continuer à utiliser le même token de réseau même si le PAN sous-jacent change, et éviter les refus liés aux tentatives de paiement légitimes.
Analyser davantage la catégorie « autre »
Pour les dimensions comportant plusieurs options, le plan croisé dynamique comprend une catégorie « autre » de façon à regrouper les points de données de faible volume qui ne sont pas représentés sur le graphique. Par exemple, vous souhaitez peut-être consulter l’ensemble des pays émetteurs de cartes dans vos données. Pour ce faire, vous pouvez consulter les données dans Sigma ou les télécharger.
Échecs de paiement
Utilisez ce tableau pour connaître les motifs d’échec ou de refus de paiement.
Avant que le paiement ne soit envoyé au réseau de cartes
Les sections suivantes décrivent les échecs qui se produisent avant que le paiement ne soit envoyé au réseau de cartes.
Échec d’authentification
You can request payments authentication with 3D Secure (3DS) using the API or with a Radar rule. Stripe might also trigger 3DS to comply with certain regulations, such as Strong Customer Authentication (SCA) requirements in Europe. The failed authentication payment requests represent situations where the customer didn’t finish the steps for authentication or failed the authentication for other reasons. To learn more about authentication failures, see Payment analytics.
Bloquer les paiements par motif
Stripe Radar bloque les paiements à haut risque, tels que ceux dont le CVC ou le code postal ne correspondent pas. Cette solution de prévention de la fraude automatisée évalue chaque paiement, sans qu’aucune action ne soit requise de votre part. Les paiements bloqués représentent ceux qui sont bloqués par Stripe après avoir obtenu l’autorisation de l’émetteur de la carte en amont, sans toutefois débiter la carte. Cette précaution permet d’éviter d’éventuels paiements frauduleux pouvant donner lieu à des litiges. Pour en savoir plus sur les motifs de blocage, consultez Paiements bloqués par motif ci-dessous.
Après l’envoi du paiement au réseau de cartes
Les sections suivantes décrivent les échecs qui se produisent après que le paiement soit envoyé au réseau de cartes.
Refus par l’émetteur
Lorsqu’une demande de paiement est soumise à l’émetteur de la carte, celui-ci utilise des systèmes et modèles automatisés pour déterminer s’il faut l’autoriser. Si l’émetteur refuse un paiement, Stripe vous indique le motif invoqué par l’émetteur. Dans certains cas, l’émetteur indique le motif de son refus à l’aide d’un code de refus. Cependant, de nombreux paiements sont classés dans la catégorie des refus de paiement génériques (dont le motif le plus courant est « Ne pas honorer »). Pour des raisons de confidentialité et de sécurité, les émetteurs de cartes peuvent uniquement en discuter avec leurs titulaires, et non avec vous ou Stripe.
Pour la plupart des entreprises, les motifs les plus courants de refus de paiement par les émetteurs sont généralement les mêmes. Ces principaux motifs de refus des réseaux vous sont expliqués ci-dessous, avec indication des mesures à prendre en réponse. Pour consulter la liste complète des motifs pour lesquels les émetteurs de cartes peuvent refuser un paiement, reportez-vous à la page Codes de refus de paiement.
- Fonds insuffisants : le compte ne dispose pas de fonds suffisants pour couvrir le montant du paiement au moment de l’autorisation. Invitez votre client à utiliser un autre moyen de paiement ou obtenez son autorisation de relancer le paiement ultérieurement.
- Ne pas honorer et autres réponses génériques (comme Refus générique ou Service non autorisé) : l’émetteur a choisi de ne pas révéler le motif de sa décision. Invitez votre client à contacter l’émetteur de sa carte pour en savoir plus ou pour utiliser un autre moyen de paiement. Les nouvelles tentatives de paiement peuvent également aboutir.
- Numéro incorrect, CVC incorrect et autres réponses faisant état d’informations de carte bancaire incorrectes : le client a saisi des informations de carte bancaire incorrectes ou des informations de carte qui ne sont plus valides. Demandez à votre client de saisir à nouveau ses informations de paiement, de contacter l’émetteur de sa carte si le problème persiste ou d’utiliser un autre moyen de paiement.
- Transaction non autorisée : l’émetteur a refusé le paiement sans raison spécifique. Cela peut être dû à la carte ou au paiement lui-même. Si le problème concerne la transaction, il est possible que la carte n’autorise pas la catégorie de dépense du marchand (par exemple, les cartes FSA pour des articles non admissibles). Pour en savoir plus, le client doit contacter l’émetteur de sa carte (les nouvelles tentatives risquent d’échouer jusqu’à ce que l’émetteur soit contacté). Il peut également utiliser un autre moyen de paiement.
- Carte volée : la carte bancaire du client a été déclarée perdue ou volée. Les nouvelles tentatives échoueront et le client doit contacter l’émetteur de sa carte pour en savoir plus. Lorsque vous recevez ces motifs de refus de paiement, vous ne devez pas les communiquer au client, car il se peut que le détenteur légitime de la carte ne soit pas la personne qui tente d’effectuer l’achat.
Tableau des paiements bloqués
Utilisez ce tableau pour savoir pourquoi certains paiements ont été bloqués.
Radar : application d’une règle
Certains paiements sont bloqués en raison d’une règle configurée dans Radar. Les paiements bloqués en raison de leur score de risque ne sont pas inclus dans cette catégorie.
Radar : application d’une règle après autorisation
Certains paiements sont bloqués après que l’émetteur de la carte a autorisé le paiement en raison d’une règle configurée dans Radar. Plus précisément, les règles Radar qui exigent une réponse de l’émetteur de la carte (par exemple, pour s’assurer que le code postal ou le CVC correspondent aux informations figurant dans ses dossiers). Les paiements bloqués en raison de leur score de risque ne sont pas inclus dans cette catégorie.
Radar : risque élevé
Certains paiements sont bloqués par Radar par défaut en raison de leur score de risque, déterminé par apprentissage automatique. Vous pouvez modifier le score correspondant au seuil de blocage par défaut. Certaines règles Radar peuvent bloquer des paiements après leur autorisation.
Stripe
Stripe peut également bloquer un paiement pour des raisons non indiquées ci-dessus. Par exemple, les paiements initiés par des cartes figurant sur des listes de refus et connues pour être frauduleuses, ou les paiements effectués depuis des pays soumis à des sanctions. Par ailleurs, Stripe peut bloquer les paiements potentiellement liés à des tests des cartes bancaires.
Tableau d’optimisation des paiements
Les solutions Stripe visant à optimiser les taux d’autorisation empêchent les refus de paiements légitimes. Ces fonctionnalités incluent Adaptive Acceptance, l’outil de mise à jour de carte et les tokens de réseau.
Adaptive Acceptance
Si Stripe reçoit un refus de l’émetteur, les modèles d’apprentissage automatique évaluent immédiatement si la demande doit être relancée et comment ajuster la demande d’autorisation pour optimiser les chances d’acceptation. Cette demande de nouvelle tentative survient en temps réel avant que Stripe ne vous renvoie une réponse de paiement. La hausse indiquée dans ce rapport provient des paiements relancés par la fonctionnalité Adaptive Acceptance après un premier refus de l’émetteur.
Outil de mise à jour de carte
Puisque les numéros de carte et les dates d’expiration évoluent régulièrement, les informations de carte obsolètes sont une source fréquente de refus de paiement pour les entreprises en ligne. Stripe s’intègre aux principaux réseaux de cartes pour mettre automatiquement à jour les informations de paiement enregistrées afin que vous disposiez des informations de carte les plus récentes. La hausse visible dans ce rapport provient des paiements effectués par des cartes mises à jour dans les 180 jours suivant la date du paiement.
Tokens de réseau
Les tokens de réseau sont des identifiants de paiement sécurisés qui remplacent les numéros de carte bancaire. Ils vous permettent de traiter les paiements avec les identifiants les plus récents, car ils restent à jour même si les données de carte correspondantes changent. Pour optimiser vos taux de réussite des paiements, Stripe a développé des intégrations avec les principaux réseaux de cartes afin de tokeniser vos cartes, ainsi que des modèles d’apprentissage automatique visant à déterminer quand utiliser un token de réseau. La hausse visible dans ce rapport provient des paiements effectués avec des tokens de réseau dont les informations ont été mises à jour dans les 180 jours suivant la date du paiement.