Vous perdez des clients avant la commande

Quelque part dans vos analyses, en ce moment même, il y a un chiffre auquel vous faites confiance. Il peut s'agir du « taux de conversion », du « taux de finalisation de commande », ou simplement du rapport entre les visiteurs et les clients payants. Vous y avez consacré du temps. Vous avez testé des titres, des couleurs de boutons, des pages de tarifs, des parcours de commande. Vous avez lu les blogs sur l'optimisation des conversions (CRO). Vous connaissez votre chiffre, et vous savez à peu près ce qui l'influence.

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.

Pas les clients qui ont abandonné leur panier. Pas les clients qui ont eu des doutes à la dernière seconde. Des clients qui ont sorti leur carte, saisi leurs informations, cliqué sur confirmer, et ont reçu un refus silencieux que ni vous ni eux ne peuvent entièrement expliquer. Vos analyses ont enregistré une session 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.

C'est ce qu'on appelle un échec d'autorisation. Et selon l'endroit où se trouvent vos clients, cela pourrait affecter une part bien plus importante de vos revenus que tout ce que votre optimisation de la commande a pu améliorer.

La décision qui se prend en deux secondes

Lorsqu'un client clique sur « payer », un processus se met en marche que la plupart des marchands n'ont jamais vu décrit. La demande de paiement transite de votre page de commande vers votre PSP, qui l'achemine via le réseau Visa ou Mastercard jusqu'à la banque émettrice du client, la banque qui lui a fourni sa carte. Cette banque prend alors une décision.

La décision n'est pas simplement « ce client a-t-il des fonds ? » C'est une évaluation des risques. Visa envoie à 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 code de catégorie de commerçant (MCC) 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é est 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 une erreur générique. « Paiement non effectué. » « Essayez une autre carte. » Parfois, rien du tout. Ils ne savent pas pourquoi. Vous ne recevez pas de code de motif dans les tableaux de bord que vous utilisez quotidiennement. Votre plateforme d'analyse enregistre la session comme terminée.

Le refus est invisible pour les deux parties.

Pourquoi la géographie est la variable cachée

Les taux d'autorisation, le pourcentage de tentatives de paiement approuvées, ne sont pas uniformes. Ils varient considérablement en fonction d'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 domestique. Les modèles de risque de la banque du client sont calibrés pour les transactions domestiques. 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 sur les marchés où la banque du PSP n'a pas de présence locale établie, comme l'Asie du Sud-Est, l'Amérique latine, certaines parties de l'Afrique, le Moyen-Orient, les taux d'autorisation peuvent chuter de manière spectaculaire. Pour les marchands dans certaines catégories ou zones géographiques, ces taux peuvent tomber à des chiffres à deux chiffres faibles. Cela signifie que moins d'un client sur cinq qui tente de payer réussit à 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 reciblage, des séquences d'e-mails et des flux de paniers abandonnés sont, dans un pourcentage significatif de cas, des clients qui n'ont jamais rien abandonné. Leur paiement a simplement été refusé avant qu'ils n'aient eu la chance de le finaliser.

Ce que cela représente dans vos chiffres

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

Cela n'apparaît nulle part, car du point de vue de chaque outil 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 par rapport au nombre total de tentatives de paiement. Votre taux de conversion réel, de l'intention d'achat à l'achat, est plus bas que vous ne le pensez. Et cet écart n'est pas récupérable par une meilleure rédaction ou une commande simplifiée. Il n'est récupérable qu'en modifiant 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 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 via une banque qui n'a pas de 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 de produit. C'est une conséquence architecturale. Ces PSP ont été conçus pour les marchands vendant à des clients situés dans la même région que leur banque. Tant que vos clients correspondent largement à cette géographie, les taux d'autorisation sont élevés et le problème est 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 la banque locale, 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.

La banque locale d'un PSP, effectuée de manière conventionnelle, exige 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 monétaires, 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 l'équation, c'est une infrastructure bancaire de cartes qui n'est pas ancrée à une seule géographie. Lorsqu'un PSP peut acheminer les transactions via des relations bancaires locales de cartes sur plusieurs marchés sans exiger du marchand qu'il établisse des entités locales, le problème du taux d'autorisation devient soluble à grande échelle.

C'est l'architecture autour de laquelle Inflowpay a été construit. Grâce à une couche de règlement basée sur les actifs numériques, Inflowpay collecte les paiements localement sur le marché de chaque client, via carte, Open Banking ou méthodes de paiement locales, et les règle sur le compte du marchand. La transaction est traitée au niveau national 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 la friction transfrontalière.

Le résultat n'est pas une amélioration marginale de la conversion à la commande. 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 plus d'un 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. Les clients que vous perdez ne sont pas dans votre entonnoir de vente. Ils se trouvent dans une couche de votre infrastructure de paiement que vous n'avez jamais eu de raison d'examiner, jusqu'à présent.

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