Know the Differences Between Stripe and Redsys and Their Dangers

I want to make it very clear that today Stripe and Redsys are identical in many aspects, including the ability to pay directly from the checkout without leaving the site as you can try in my example store using InSite, and although many people continuously claim that Stripe is better for payments since there is a higher payment completion rate, that is not true. Well, let’s clarify, it is true if we speak from the real ignorance of how Redsys (actually the PSD2) and Stripe work, since with Redsys we can match the same low abandonment rate that exists in Stripe during payment (which is very low) and even reduce it (yes, reduce it), it’s just that you need to know the possibility and what this means for commerce. And no, it has nothing to do with Stripe’s “superior technology,” as many people constantly repeat as if it were a mantra.

But to understand all this, we need to start from the beginning. At the end of 2018, the new PSD2 regulation began to be applied progressively. In September 2019, it came into force, and those who requested it could start using it on their terminals, and by December 31, 2020, it was mandatory, although in some cases they were activating the PSD2 flow on terminals throughout 2021 due to requests from companies that had not “had time” to adapt their code. I put that in quotes because they had almost 3 years to do it, so more than not having time, it was negligence (in my view). I spent 4 months adapting my premium Redsys plugin, without much rush, managing to release a beta version already supporting PSD2 in September 2020 to get user feedback before it became mandatory 4 months before it was put into mandatory use. In fact, at that time I helped many companies adapt the code of their custom sites to PSD2 and advised several well-known development companies, as the truth is that it is not easy, and it was easier to go to someone who had already been “fighting” to apply the new regulation than to start from scratch looking for information.

What exactly does PSD2 consist of? It is basically a double authentication for purchases. Until the implementation of PSD2, authentication consisted of the CVV/CVC and in some cases sending an SMS if you requested the bank to activate it (some banks would activate it even if you didn’t request it), many people didn’t know this or didn’t want to activate it “for convenience.” After the PSD2 came into force, that second authentication, which generally consists of authorizing the operation through the bank’s app, became mandatory in Europe. This greatly increased security, but also complicated payment for many people, to the point that some still today do not complete it because they do not know how to do it, or for example because they do not have their mobile phone at hand.

And here begins the important point, so engrave it in your mind so that you keep it in mind and clear. This security is bidirectional. What does it mean? It provides security both to the customer who buys in a store with their card, and to the store that the buyer is really the owner of the card and is guaranteed by the banking system, meaning that the buyer has security that with double authentication the store will not be able to use their card to make unauthorized charges, and the store knows that if they have been paid for the order, they will collect it because the banking system has guaranteed that the person who bought is the owner of the card, so in the case of card theft (for example), you will still collect if that operation has been authenticated.

Are you starting to see a bit where this is going? There lies basically the difference between Stripe and Redsys. Stripe requests far fewer authentications (in practice almost none) and Redsys requests authentication by default for practically all operations. This is what causes there to be many more payment completions in Stripe than in Redsys. But how can this be if PSD2 mandates authentication? And what happens with all those unauthenticated operations in Stripe? I suppose you have asked yourself these two questions, and if you haven’t, you should have with everything I have explained up to this point.

Within the PSD2 directive, there are exemptions known as SCA (Strong Consumer Authentication). There are several SCAs, but there are three particularly important ones in this area. One is MIT, which does not apply in this case as it is exclusive to subscriptions. The ones we need to know and take into account are LWV and TRA.

The LWV is an SCA that applies when the order is of low cost. That is, when the amount is less than €30, it can be sent in the payment request and authentication will not be requested. Stripe applies it directly if the order falls within the price range, and in Redsys you have to request it to be activated and send the SCA at the time of charging an order if applicable. Translated to the offline world, it is when you pay in a physical store with the card, and for the value of the purchase, it does not ask for the pin to pay; obviously, this is not as noticeable if you pay with a mobile phone via NFC, because it always requests the fingerprint for security access to the payment method, at least with the application I use (CaixaBank).

The TAR, which is the “dangerous” one, is like the LWV, but with the difference that it is for much higher amounts. TRA stands for (Transaction Risk Analysis). The maximum application of the SCA TRA usually depends on the bank in the case of Redsys, but generally, they are very reluctant to activate/accept it for amounts over €250. If they activate TRA in Redsys, you can request that it be applied, and Redsys will assess whether to send it to the issuer or not, but keep in mind that you will assume the risk (as I will explain a bit later). Stripe has it active directly and for amounts up to €500. What Stripe will do is perform a risk analysis, and if it does not see anything significant, it will send TRA to the card issuer for the payment request, which means that authentication will not be performed (if the customer’s issuer accepts it). In the screenshot of the next table that you can find here, you can see how they apply the risk analysis to send or not TRA.

The above may seem very interesting and make one think, “Ah, fantastic, I always send TRA!” It’s a thought that can come to mind very quickly, right? Less request for authentications, more conversions, more sales, fantastic! “Now I understand why there is not so much abandonment in payment with Stripe, because very few must authenticate.”

Yes, you would be right that the reason is that, it sends LWV or TRA in almost all transactions, and that means that authentication is not requested in practically any case, if the issuer/bank of the customer accepts it, because maybe the issuer/bank does not accept the TRA for any reason and requests authentication. And as I mentioned earlier, you can request Redsys to activate it for you. The LWV would be practically immediate, and the TRA might take a little longer. But be careful, they will inform you of what consequences it has to activate these SCAs, and maybe you will no longer see it as a good idea because knowledge is power, especially in decision-making.

If we delve deeper into the SCAs, the entity that sends the SCA (whether the store or the bank), whether LWV or TRA, must take responsibility in case of fraud/theft. If we delve into PSD2/SCA, we can see that the one who must take responsibility in case of fraud must be the one who sends the TRA compliance (in this Adyen entry they explain everything very well). We can see that almost at the end, it states this:

2. Low-risk transactions – TRA (Transaction Risk Analysis)

Issuing banks may consider certain transactions as low risk. To do this, they rely on the average fraud levels of the issuer, the acquirer, or both at the same time. In these cases, the exemption can be requested by both the store and the issuing bank.

The responsibility in case of chargeback will fall on the issuer if it was they who requested the exemption or on the store if it was the one who requested it.

The most important thing is the last paragraph. So now you have a clue about what your bank is going to tell you. They can activate LWV or TRA on the terminal to request not to authenticate the operation, but if that card has been stolen (for example) and the issuing bank accepts the TRA, you will be left without the product (if you have already sent it) and without the money, because you will have to return it. If there is authentication, even if the person has had their card and mobile stolen and has purchased on your site, no one will be able to claim anything from you. You continue with the money because it is a problem of the card owner and the issuing bank; they will sort out who is responsible for that charge, the bank for not quickly canceling the card in time, or the card owner for not having reported the theft immediately. But surely you are not responsible.

And now you might be thinking, “Ah, well, it’s Stripe that sends TRA, let them wake up!” And that would be logical in this case because it is sending it without you knowing, but this is the only murky part of all this. No, it is sending TRA on your behalf without you being aware of it and without knowing the consequences it has on orders of up to €500, and in case of fraud, it will pass the problem to you by opening a dispute, meaning it is making people not authenticate without explaining the consequences of this to merchants, but if there is any problem, let the store bear it without having requested to assume that risk. That’s why I say it’s the murky part of all this. That is, if you are unfortunate enough that a card theft/cloning mafia passes through your website and buys products worth, for example, €10,000, that nothing happens to you with Stripe, because it will have sent TRA, they will not have authenticated, and you will be passed the mess through a dispute when all the reports appear that the cards had been stolen or cloned and that the purchases had not been authenticated. But not only will you have to return the money, but a fee will also be applied for what is called chargeback, meaning that you will not only be left without the money and the product, but you will also have to pay for it. In the case of Stripe, for each dispute you lose, it will be €15 today (consider that within those €10,000 there may be hundreds of different orders) + €20 for each refund (the same, there can be hundreds of customers/orders), and I don’t know if there is a % of the penalty value. But just with the €15 + €20 per transaction/customer, do the math. You might end up paying more with all these charges than the €10,000 that you were already defrauded, not counting the loss of goods/products.

Is all this a plea against Stripe? No, I’m just telling you what they don’t tell you, so that one day you don’t have a very unpleasant surprise. Now at least you know how the game board is, and you can decide with all the data in hand.

Stripe has good things compared to Redsys, such as ease of contracting, transaction management panel, billing, etc. That can be an added value that inclines you to use it. But on the other hand, Redsys has a lot of security and very low fees.

At this moment you might be thinking, “Nothing like this has ever happened to me,” until one fine day it can happen, and you find yourself in a situation similar to the previous one. But now you can no longer say that you didn’t expect it or didn’t know, but if you are still willing to accept the risk of TRA and to a much lesser extent LWV, you can have it in Redsys too and with much lower commissions than those applied by Stripe (and even more after the increase they made), and through my Redsys plugin for WooCommerce you can request LWV and TRA (if you are willing to assume the risk) from Redsys (if they have activated them on the terminal) and also have the credit card form at checkout without leaving the site, which can also be done with Redsys as you can check in my example store.

Activating LWV on the terminal for all payments under €30 not to authenticate can be very interesting, but you have to be careful with TRA. Without a doubt, sending TRA, which as I mentioned you can also do with Redsys, will almost certainly increase your sales by not requesting authentication so much, but it will also greatly increase the possibility of being defrauded.

You now truly have all the information on how PSD2 works. I believe you will not find many entries as clear as this regarding the functioning and risks that exist with SCAs. At this point, knowing everything you know after reading the entry, you can truly make a decision about what you want to achieve considering the consequences. Now you can evaluate how you will approach your payment method, more authentications by not using any type of SCA to live peacefully, apply LWV having a balance between security and low risk due to being low amounts, or you will use TRA maximizing sales by reducing authentications but also maximizing risks.

As you can see, with Redsys you can also minimize authentications and maximize sales by preventing payment abandonment like in Stripe by requesting and activating the SCA LWV and TRA, but the decision to accept the risk in Redsys is yours, and in Stripe it is imposed and with the ignorance of most merchants of the risks they are assuming. And the worst part is that most interpret it as if Stripe has more sales because it has better technology.

Please leave this field empty

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