Vous perdez des clients avant même le paiement

Quelque part dans vos analytics en ce moment, il y a un chiffre auquel vous faites confiance. Il est peut-être intitulé « taux de conversion », « taux de finalisation du paiement », ou simplement le ratio entre visiteurs et clients payants. Vous y avez consacré du temps. Vous avez testé des titres, des couleurs de boutons, des pages de tarification, des parcours de paiement. Vous avez lu les blogs sur le CRO. Vous connaissez votre chiffre, et vous savez à peu près ce qui le fait bouger.

Ce que ce chiffre ne vous montre pas, ce sont les clients qui ont tenté de payer, ont échoué, et sont partis sans laisser de trace.

Il ne s'agit pas de clients qui ont abandonné leur panier. Ni de clients qui ont eu un dernier moment d'hésitation. Il s'agit de clients qui ont saisi leur carte, entré leurs informations, cliqué sur confirmer, et reçu un refus silencieux qu'ni vous ni eux ne pouvez véritablement expliquer. Vos analytics ont enregistré une session qui s'est terminée. Votre taux de conversion a absorbé cet échec. Aucune alerte n'a été déclenchée. Aucun e-mail n'a été envoyé. Le client est passé à autre chose. Vous aussi.

Cela s'appelle un échec d'autorisation. Et selon la localisation de vos clients, cela peut affecter une part bien plus importante de votre chiffre d'affaires que tout ce que votre optimisation du checkout a jamais touché.

La décision qui se joue en deux secondes

Lorsqu'un client clique sur payer, un processus démarre que la plupart des marchands n'ont jamais vu décrit. La demande de paiement voyage de votre checkout vers votre PSP, qui l'achemine via le réseau Visa ou Mastercard jusqu'à la banque émettrice du client, celle qui lui a délivré sa carte. Cette banque prend alors une décision.

La décision ne se limite pas à « ce client a-t-il des fonds ? ». Il s'agit d'une évaluation du risque. Visa transmet à la banque émettrice un score entre 0 et 99, calculé en temps réel à partir de multiples variables : le type de carte, le montant de la transaction, le pays du client, le Merchant Category Code associé à votre entreprise, et le profil de risque de la banque acquéreuse que votre PSP utilise pour traiter les paiements en votre nom. Un score plus élevé constitue une recommandation plus forte de refus. La banque émettrice prend la décision finale. L'ensemble de ce processus prend environ deux secondes.

Si la transaction est refusée, votre client voit un message d'erreur générique. « Paiement non abouti. » « Essayez une autre carte. » Parfois, rien du tout. Il ne sait pas pourquoi. Vous ne recevez aucun code de motif dans les tableaux de bord que vous consultez au quotidien. Votre plateforme d'analytics enregistre simplement la fin de la session.

Le refus est invisible pour les deux parties.

Pourquoi la géographie est la variable cachée

Les taux d'autorisation, c'est-à-dire le pourcentage de tentatives de paiement approuvées, ne sont pas uniformes. Ils varient considérablement selon un facteur sur lequel la plupart des marchands n'ont aucun contrôle direct : la relation entre le pays de la banque de leur PSP et le pays de la banque de leur client.

Lorsque ces deux pays correspondent, la transaction est traitée comme nationale. Les modèles de risque de la banque du client sont calibrés pour les transactions nationales. Les taux d'approbation sont élevés, généralement supérieurs à 90 %, atteignant souvent 95 % ou plus pour les types de cartes standard.

Lorsque ces deux pays ne correspondent pas, la transaction est classée comme transfrontalière. Le score de risque que Visa envoie à la banque du client (banque émettrice) est calculé différemment. La banque émettrice applique des seuils plus conservateurs. Et dans les marchés où la banque du PSP n'a pas de présence locale établie, Asie du Sud-Est, Amérique latine, certaines régions d'Afrique, Moyen-Orient, les taux d'autorisation peuvent chuter drastiquement. Pour les marchands de certaines catégories ou zones géographiques, ces taux peuvent tomber dans les faibles dizaines de pourcentage. Cela signifie que moins d'un client sur cinq essayant de payer parvient effectivement à finaliser la transaction.

Les quatre autres voient une erreur. Vous voyez une session abandonnée.

Les clients que vous essayez de récupérer avec des publicités de retargeting, des séquences d'e-mails et des flux de panier abandonné sont, dans une proportion significative des cas, des clients qui n'ont jamais rien abandonné. Leur paiement a simplement été refusé avant qu'ils n'aient eu la possibilité de finaliser leur achat.

Ce que cela signifie dans vos chiffres

Prenons l'exemple d'une entreprise traitant 2 000 tentatives de paiement international par mois avec un panier moyen de 60 €. À un taux d'autorisation de 90 %, standard pour le traitement national, 1 800 transactions aboutissent. À un taux d'autorisation de 65 %, courant pour le traitement transfrontalier dans certains marchés, 1 300 transactions aboutissent. La différence est de 500 transactions. 30 000 € par mois de revenus qui n'apparaissent pas dans votre tableau de bord PSP, qui n'apparaissent pas dans votre Google Analytics, et qui n'apparaissent dans aucun rapport que vous consultez.

Cela n'apparaît nulle part, car du point de vue de tous les outils que vous utilisez, ces 500 transactions n'ont jamais été tentées. Les clients sont simplement partis.

La conséquence pratique est que vous optimisez un taux de conversion mesuré par rapport aux tentatives de paiement réussies, et non au total des tentatives de paiement. Votre taux de conversion réel, de l'intention à l'achat, est inférieur à ce que vous pensez. Et cet écart ne peut pas être comblé par un meilleur copywriting ou un checkout simplifié. Il ne peut être comblé qu'en changeant l'infrastructure qui traite le paiement.

Pourquoi votre PSP actuel ne peut pas résoudre ce problème

Stripe, Adyen, Mollie et pratiquement tous les PSP grand public sont construits autour d'une seule banque, ou d'un petit nombre de banques, généralement basées aux États-Unis ou en Europe. Lorsqu'un client en Thaïlande, au Brésil ou au Canada paie via l'un de ces PSP, sa transaction est acheminée par une banque qui n'a aucune relation bancaire locale sur ce marché. La transaction est transfrontalière par défaut. Le score de risque est élevé. Le taux d'autorisation chute.

Ce n'est pas un échec produit. C'est une conséquence architecturale. Ces PSP ont été conçus pour des marchands vendant à des clients situés dans la même région que leur banque. Tant que vos clients correspondent globalement à cette géographie, les taux d'autorisation sont élevés et le problème reste invisible. Dès que votre base de clients s'étend au-delà de ce marché local, l'écart se creuse, et il s'élargit à chaque nouveau marché que vous abordez.

La seule solution structurelle aux faibles taux d'autorisation sur un marché donné est le local banking, c'est-à-dire avoir un contrat avec la banque d'un PSP dans le même pays ou la même région que votre client. Lorsque la banque de votre PSP qui vous permet de traiter les paiements et la banque du client opèrent sur le même marché, la transaction est domestique. Le profil de risque change. Le score change. Le taux d'autorisation se rétablit.

Le local banking des PSP, fait de manière conventionnelle, nécessite une entité juridique dans chaque marché, la négociation d'un contrat avec un partenaire bancaire local, la gestion des taxes locales, puis le rapatriement des fonds vers votre marché principal tout en gérant les fluctuations de change, et enfin un processus de conformité qui se répète indéfiniment à mesure que vous vous développez. Pour une entreprise ayant des clients dans dix pays, cela représente dix projets juridiques et opérationnels parallèles. Pour la plupart des entreprises en croissance, ce n'est pas une voie réaliste.

L'infrastructure qui rend l'acquisition locale accessible

Ce qui change la donne, c'est une infrastructure bancaire par carte qui n'est pas ancrée à une seule zone géographique. Lorsqu'un PSP peut acheminer les transactions via des relations bancaires locales par carte sur plusieurs marchés, sans exiger du marchand qu'il établisse des entités locales, le problème du taux d'autorisation devient résoluble à grande échelle.

C'est l'architecture autour de laquelle Inflowpay a été conçu. Grâce à une couche de règlement basée sur des actifs numériques, Inflowpay collecte les paiements localement sur le marché de chaque client, via carte, Open Banking ou moyens de paiement locaux, puis règle le compte marchand. La transaction est traitée localement dans le pays du client. Le profil de risque est celui d'une transaction domestique. Les taux d'autorisation reflètent l'acquisition locale, et non les frictions transfrontalières.

Le résultat n'est pas une amélioration marginale du taux de conversion au paiement. C'est une correction structurelle d'un manque à gagner que la plupart des marchands n'ont jamais pu mesurer, car l'infrastructure sur laquelle ils s'appuient ne le leur montre pas.

Si vous vendez à des clients dans plusieurs pays et que vous n'avez jamais audité vos taux d'autorisation par zone géographique, le chiffre que vous optimisez n'est pas celui qui compte réellement. Les clients que vous perdez ne se trouvent pas dans votre tunnel de conversion. Ils se trouvent dans une couche de votre infrastructure de paiement que vous n'aviez jamais eu de raison d'examiner, jusqu'à présent.

Vous pouvez découvrir à quoi ressemblent réellement vos taux d'autorisation avec Inflowpay sur inflowpay.com.