Connaissez vraiment les différences entre Stripe et Redsys et leurs dangers

Je tiens à préciser que de nos jours, Stripe et Redsys sont identiques à bien des égards, y compris la possibilité de payer directement depuis le checkout sans quitter le site, comme vous pouvez le tester sur ma boutique d’exemple via InSite. Bien que beaucoup de gens affirment continuellement que Stripe est meilleur pour les paiements car il y a un taux de finalisation plus élevé, ce n’est pas vrai. En fait, c’est vrai si l’on parle sans connaître réellement le fonctionnement de Redsys (en réalité la PSD2) et de Stripe, car avec Redsys, nous pouvons égaler le même faible taux d’abandon qui existe sur Stripe lors du paiement (qui est très réduit) et même le réduire (oui, le réduire), il suffit de connaître la possibilité et ce que cela signifie pour le commerce. Et non, cela n’a rien à voir avec la “technologie supérieure” de Stripe, comme beaucoup de gens le répètent constamment comme un mantra.

Mais pour comprendre tout cela, il faut commencer par le début. À la fin de 2018, la nouvelle réglementation PSD2 a commencé à être appliquée progressivement. En septembre 2019, elle est entrée en vigueur et ceux qui le demandaient pouvaient commencer à l’utiliser sur leurs terminaux, et le 31 décembre 2020, elle est devenue obligatoire, bien que dans certains cas, le flux PSD2 ait été activé tout au long de 2021 sur les terminaux à la demande d’entreprises qui n’avaient “pas eu le temps” d’adapter leur code. Je mets cela entre guillemets car ils avaient presque 3 ans pour le faire, donc plus que de ne pas avoir eu le temps, cela a été de la négligence (selon ma façon de voir). J’ai adapté mon plugin premium de Redsys pendant 4 mois, sans trop de précipitation, réussissant à libérer une version bêta offrant déjà un support pour la PSD2 en septembre 2020 afin d’obtenir des retours d’utilisateurs avant qu’elle ne devienne obligatoire 4 mois avant son utilisation obligatoire. En fait, à ce moment-là, j’ai aidé de nombreuses entreprises à adapter le code de leurs sites sur mesure à la PSD2 et j’ai conseillé plusieurs entreprises de développement bien connues, car la vérité est que ce n’est pas simple et qu’il était plus facile de faire appel à quelqu’un qui avait déjà été “en train de se battre” pour appliquer la nouvelle réglementation, plutôt que de commencer de zéro en cherchant des informations.

En quoi consiste exactement la PSD2 ? C’est essentiellement une double authentification d’achat. Jusqu’à la mise en œuvre de la PSD2, l’authentification consistait en le CVV/CVC et dans certains cas, en l’envoi d’un SMS si vous demandiez à la banque de l’activer (certaines banques l’activaient même sans que vous le demandiez), beaucoup de gens ne le savaient pas ou ne voulaient pas l’activer “par commodité”. Après l’entrée en vigueur de la PSD2, cette seconde authentification, qui consiste généralement à autoriser l’opération via l’application de la banque, est devenue obligatoire en Europe. Cela a considérablement augmenté la sécurité, mais aussi la complexité du paiement pour de nombreuses personnes, au point que certains, encore aujourd’hui, ne finalisent pas leur paiement car ils ne savent pas comment faire, ou par exemple parce qu’ils n’ont pas leur téléphone à portée de main.

Et c’est ici que commence le point important, alors grave-le dans ta mémoire pour que tu en prennes bien compte. Cette sécurité est bidirectionnelle. Que veut dire cela ? Cela signifie qu’elle offre une sécurité tant au client qui achète dans un commerce avec sa carte, qu’au commerce, en garantissant que celui qui achète est réellement le propriétaire de la carte, et cela est garanti par le système bancaire. En d’autres termes, l’acheteur a la sécurité que, grâce à la double authentification, le commerce ne pourra pas utiliser sa carte pour effectuer des prélèvements indus, et le commerce sait que s’il a été payé pour la commande, il va être payé car le système bancaire lui a garanti que la personne qui a acheté est bien la propriétaire de la carte. Ainsi, en cas de vol de carte (par exemple), vous serez payé même si cette opération a été authentifiée.

Commences-tu à voir un peu où cela nous mène ? C’est là essentiellement la différence entre Stripe et Redsys. Stripe demande beaucoup moins d’authentifications (en pratique presque nulles) et Redsys demande par défaut d’authentifier pratiquement toutes les opérations. Cela provoque qu’il y ait beaucoup plus de finalisations de paiement sur Stripe que sur Redsys. Mais comment cela peut-il être si la PSD2 oblige l’authentification ? Et que se passe-t-il avec toutes ces opérations non authentifiées sur Stripe ? Je suppose que tu t’es posé ces deux questions, et si tu ne te les es pas posées, tu devrais le faire avec tout ce que je t’ai expliqué jusqu’à présent.

Dans la directive PSD2, il existe des exemptions, connues sous le nom de SCA (Strong Consumer Authentication ou authentification renforcée des consommateurs). Il y a plusieurs SCA, mais trois en particulier sont importantes dans ce domaine. Une est le MIT, qui ne s’applique pas dans ce cas car il est exclusif aux abonnements. Ceux que nous devons connaître et prendre en compte sont le LWV et le TRA.

Le LWV est un SCA qui s’applique lorsque la commande est de faible coût. C’est-à-dire que lorsque le montant est inférieur à 30€, il peut être envoyé dans la demande de paiement et l’authentification ne sera pas demandée. Stripe l’applique directement si la commande entre dans la fourchette de prix, et chez Redsys, il faut le demander pour qu’ils l’activent et envoyer le SCA au moment du paiement d’une commande si nécessaire. Transposé au monde hors ligne, c’est lorsque vous payez dans un commerce physique avec la carte, et pour le montant de l’achat, il ne vous demande pas le code PIN pour payer. Évidemment, cela ne se remarque plus autant si vous payez avec un mobile via NFC, car cela demande toujours une empreinte pour des raisons de sécurité d’accès au mode de paiement, au minimum avec l’application que j’utilise (CaixaBank).

Le TAR, qui est le “dangereux”, est comme le LWV, mais avec la différence qu’il s’applique à des montants beaucoup plus élevés. TRA signifie (Transaction Risk Analysis). L’application maximale du SCA TRA dépend généralement de la banque dans le cas de Redsys, mais en règle générale, ils sont très réticents à l’activer/accepter pour des montants supérieurs à 250€. Si le TRA est activé chez Redsys, vous pourrez demander qu’il soit appliqué et Redsys effectuera une évaluation pour savoir s’il l’envoie ou non à l’émetteur, mais sachez que le risque sera à votre charge (comme je l’expliquerai un peu plus tard). Stripe l’a activé directement et pour des montants allant jusqu’à 500€. Ce que fera Stripe, c’est réaliser une analyse de risque, et s’il ne voit rien de significatif, il enverra le TRA à l’émetteur de la carte pour la demande de paiement, ce qui signifie qu’il n’y aura pas d’authentification (si l’émetteur du client l’accepte). Dans le tableau suivant que vous pouvez trouver ici, vous pouvez voir comment ils appliquent l’analyse de risque pour envoyer ou non le TRA.

Ce qui précède peut sembler très intéressant et amener quelqu’un à penser, “Ah, fantastique, j’envoie toujours le TRA !” C’est une pensée qui peut venir très rapidement à l’esprit, n’est-ce pas ? Moins de demandes d’authentification, plus de conversions, plus de ventes, fantastique ! “Maintenant je comprends pourquoi avec Stripe il y a moins d’abandon lors du paiement, car très peu de personnes doivent s’authentifier”.

Oui, vous auriez raison de dire que la raison est celle-ci, envoyez LWV ou TRA dans presque la totalité des transactions, et cela fait qu’il n’y a pratiquement aucune demande d’authentification, si l’émetteur/la banque du client l’accepte, car il se peut que l’émetteur/la banque n’accepte pas le TRA pour une raison quelconque et demande une authentification. Et comme je l’ai mentionné précédemment, vous pouvez demander à Redsys de l’activer. Le LWV serait pratiquement immédiat, et le TRA pourrait prendre un peu plus de temps. Mais attention, ils vous informeront des conséquences de l’activation de ces SCA et peut-être que vous ne le verrez plus comme une bonne idée, car la connaissance est un pouvoir, surtout en matière de décision.

Si nous approfondissons davantage les SCA, l’entité qui envoie le SCA (que ce soit le commerce ou la banque), qu’il s’agisse de LWV ou de TRA, doit prendre en charge en cas de fraude/vol. Si nous approfondissons la PSD2/SCA, nous pouvons voir que celui qui doit prendre en charge en cas de fraude doit être celui qui envoie la conformité du TRA (dans cet article d’Adyen, ils expliquent très bien tout cela). Nous pouvons voir qu’à la fin, cela dit :

2. Transactions à faible risque – TRA (Transaction Risk Analysis)

Les banques émettrices peuvent considérer certaines transactions comme à faible risque. Pour cela, elles se basent sur les niveaux de fraude moyens de l’émetteur, de l’acquéreur ou des deux en même temps. Dans ces cas, l’exemption peut être demandée à la fois par le commerce et par la banque émettrice.

La responsabilité en cas de rétrofacturation incombera à l’émetteur si c’est lui qui a demandé l’exemption ou au commerce si c’est lui qui l’a demandée.

Le plus important est le dernier paragraphe. Vous avez donc déjà un indice sur ce que votre banque va vous dire. Ils peuvent activer LWV ou TRA sur le terminal pour demander de ne pas authentifier l’opération, mais si cette carte a été volée (par exemple) et que la banque émettrice accepte le TRA, vous allez vous retrouver sans le produit (si vous l’avez déjà envoyé) et sans l’argent, car vous allez devoir le rembourser. S’il y a authentification, même si la personne s’est fait voler sa carte et son téléphone et a acheté sur votre site, personne ne pourra vous réclamer quoi que ce soit. Vous continuez à avoir l’argent car c’est un problème du propriétaire de la carte et de la banque émettrice, ils s’arrangeront entre eux pour savoir qui est responsable de ce prélèvement, la banque pour ne pas avoir annulé rapidement la carte à temps, ou le propriétaire de la carte pour ne pas avoir signalé immédiatement le vol. Mais vous, vous n’êtes certainement pas responsable.

Et maintenant, vous pensez peut-être, “Ah, c’est Stripe qui envoie le TRA, qu’il se réveille !” Et ce serait logique dans ce cas, car il l’envoie sans que vous le sachiez, mais c’est la seule partie délicate de tout cela. Eh bien non, il envoie le TRA en votre nom sans que vous en ayez connaissance et sans connaître les conséquences que cela a pour des commandes allant jusqu’à 500€, et en cas de fraude, le problème vous sera transféré en ouvrant un litige, c’est-à-dire qu’il fait en sorte que les gens ne s’authentifient pas sans expliquer les conséquences de cela aux commerçants, mais si un problème survient, c’est le commerce qui en subira les conséquences sans avoir demandé à assumer ce risque. C’est pourquoi je dis que c’est la partie délicate de tout cela. En d’autres termes, si vous avez la malchance qu’une mafia de vol/clonage de cartes passe par votre site et achète des produits pour une valeur par exemple de 10 000€, ne vous inquiétez pas avec Stripe, car il aura envoyé le TRA, ils ne se seront pas authentifiés, et vous aurez le problème par le biais d’un litige lorsque toutes les plaintes apparaîtront indiquant que les cartes avaient été volées ou clonées et que les achats n’avaient pas été authentifiés. Mais vous ne devrez pas seulement rembourser l’argent, des frais seront également appliqués pour ce qu’on appelle une rétrofacturation, c’est-à-dire que vous ne vous retrouverez pas seulement sans l’argent et le produit, vous devrez également payer pour cela. Dans le cas de Stripe, pour chaque litige que vous perdez, cela sera aujourd’hui 15€ (pensez qu’il peut y avoir des centaines de commandes différentes dans ces 10 000€) + 20€ pour chaque retour d’argent (de même, cela peut être des centaines de clients/commandes), et je ne sais pas s’il y a un % de la valeur de sanction. Mais rien qu’avec les 15€ + les 20€ par transaction/client, faites le calcul. Vous pourriez payer plus avec tous ces frais que les 10 000€ qui vous ont déjà été volés, sans compter la perte de marchandises/produits.

Tout cela est-il un plaidoyer contre Stripe ? Non, je ne fais que vous raconter ce qu’ils ne disent pas, pour que vous n’ayez pas un jour une très mauvaise surprise. Maintenant, au moins, vous savez comment est le tableau de jeu, et vous pouvez décider avec toutes les données en main.

Stripe a des avantages par rapport à Redsys, comme la facilité de souscription, le tableau de bord de gestion des transactions, la facturation, etc. Cela peut être une valeur ajoutée qui vous incite à l’utiliser. Mais en contrepartie, Redsys offre beaucoup de sécurité et des frais très bas.

En ce moment, vous pensez peut-être, “Cela ne m’est jamais arrivé”, jusqu’à ce qu’un jour cela puisse arriver et que vous vous retrouviez dans une situation semblable à celle-ci. Mais maintenant, vous ne pourrez plus dire que vous ne vous y attendiez pas ou que vous ne le connaissiez pas. Mais si vous êtes tout de même prêt à accepter le risque de TRA et dans une bien moindre mesure LWV, chez Redsys, vous pouvez l’avoir aussi et avec des commissions beaucoup plus basses que celles appliquées par Stripe (et encore plus après l’augmentation qu’ils ont réalisée), et grâce à mon plugin Redsys pour WooCommerce, vous pourrez demander LWV et TRA (si vous êtes prêt à assumer le risque) à Redsys (s’ils vous les ont activés sur le terminal) et également avoir le formulaire de carte de crédit dans le checkout sans quitter le site, ce qui est également possible avec Redsys, comme vous pourrez le vérifier sur ma boutique d’exemple.

Il peut être très intéressant d’activer le LWV sur le terminal pour que tous les paiements inférieurs à 30€ ne soient pas authentifiés, mais il faut faire attention au TRA. Sans aucun doute, l’envoi de TRA, que comme je l’ai mentionné, vous pouvez également le faire avec Redsys, augmentera presque certainement vos ventes en ne demandant pas autant d’authentification, mais cela augmentera également considérablement la possibilité d’être victime d’une fraude.

Vous avez maintenant vraiment toutes les informations sur le fonctionnement de la PSD2. Je pense que vous ne trouverez pas beaucoup d’articles aussi clairs que celui-ci concernant le fonctionnement et les risques associés aux SCA. À ce stade, sachant tout ce que vous savez après avoir lu l’article, vous pouvez vraiment prendre une décision sur ce que vous voulez pour atteindre un objectif en tenant compte des conséquences. Maintenant, vous pouvez évaluer comment vous allez aborder votre méthode de paiement, plus d’authentifications en n’utilisant aucun type de SCA pour vivre tranquillement, appliquer LWV en ayant un équilibre entre sécurité et faible risque en raison de montants réduits, ou utiliser TRA en maximisant les ventes en réduisant les authentifications tout en maximisant les risques.

Comme vous pouvez le voir, avec Redsys, vous pouvez également réduire au minimum les authentifications et maximiser les ventes en évitant l’abandon de paiement comme avec Stripe, grâce à la demande et à l’activation des SCA LWV et TRA, mais la décision d’accepter le risque chez Redsys vous appartient, et chez Stripe, elle est imposée avec l’ignorance de la plupart des commerçants sur les risques qu’ils assument. Et le pire, c’est que la plupart des gens interprètent cela comme si avec Stripe, il y avait plus de ventes parce qu’il a une meilleure technologie.

Veuillez laisser ce champ vide

¡No te pierdas las novedades!

Acepto apuntarme a la lista de correo para estar al día de todas las novedades.

¡No hacemos spam! y te puedes dar de baja cuando quieras

Revisa tu bandeja de entrada o la carpeta de spam para confirmar tu suscripción.