Using Stripe To Sell Internationally? Lower Your False-Decline Ratio by up to 15%
This is an exposé/rant on how to substantially lower your international credit/debit card processing false decline ratio when you don’t want to deal with multi platform integrations, smart-routing or piggy-backing.
Substantially in our case means 15%, but in yours it could be more.
The Problem
At the risk of dumbing down the aspect of payment conversions, most merchants that sign up for an account with a payment processor expect that charges to cards with money/credit will go through and those without, won’t.
It is obviously much more complicated than this, especially when dealing internationally. There are aspects such as card types, bank gateway agreements, card issuers, “fund latency” and of course, the most important one of them, fraud.
This is more commonly known as the False Declines problem. i.e. A charge that in theory should go through because the customer has valid funds and account status, receives a declined signal from some point of the processing chain that joins customers with merchants with banks/issuers.
False declines affect all types of processing traffic, but have a much bigger impact on international traffic.
One would expect that there wouldn’t be much difference charging a US customer with a UK payment processor, or a Mexican Customer with a Spanish acquirer.
Truth is, the difference can be big:
Conversion rates for out-of-original country charges can fail as much as 50% with regards to local traffic.
This will vary worldwide, but it definitely will have an impact on your business if you’re global.
The Expensive Alternative
If you’ve got resources, you should definitely charge locally where possible. Local integrations will give you an edge and reduce false declines, but this is not a viable scenario for medium sized merchants.
The Solution
There is an easier alternative that consists of 2 distinct actions you can take.
They will automatically improve your conversion, and as a bonus reduce your dispute rate (if that’s an issue for you).
In fact, the reason I said “rant” at the beginning of this article is because one actually wonders why this is not standard strategy embedded in payment processors logic. (If it is, it’s not working, but again, I’m oversimplifying things!)
TL;DR;
Run a“Passive 3DS Attempt” before a regular charge, and a “Full 3DS Charge Piggy-back Attempt” if you get a decline.
The Long Version
I won’t go into detail of what 3D Secure or 3DS is since most merchants will have had experience by now, especially those with EU contact and all the talk about SCA compliance, but to overly simply it, 3DS:
- “Forces” the customer to authenticate with a 2nd factor such as an SMS code, a token or an auth code.
- Protects the merchant from fraud-related DISPUTES and CHARGEBACKs by shifting liability to the bank. (The theory is that it was the banks fault, not yours, for letting this payment through)
- Adds checkout FRICTION and is a conversion KILLER.
If you don’t sell high-value merchandise or risky products, you might not have a need for 3DS, and might think your conversion rate cannot improve.
But if you’re getting a bunch of “do not honor” or “transaction not allowed” response codes, you might want to think again.
Action 1:
Implement “Non Authorization Required — 3DS” or “Passive 3DS”.
The 1st way to improve your conversion is to attempt 3DS BEFORE you try to charge a customer the “normal” way.
“Wait!”, you might say. “If I do this, I will force my customers through 3DS hell and conversion will drop!”
The idea here is that you will attempt NO AUTHORIZATION REQUIRED 3DS, transparently. The operative words here being “no authorization required”.
Depending on your payment gateway this can be tested at the charge object creation level. It basically comes down to:
- If the card supports 3DS and the bank provides a URL for redirect/authorization, the customer will probably be forced to authenticate. We don’t want this case, so if it is so, we ignore it, and proceed with a regular NON 3DS charge attempt.
- If the card supports 3DS but the bank cannot or does not want to perform authorization (due to voluntary assessment or technical incapacity), it may “pseudo authenticate” the customer. This is our desired scenario. We will attempt to charge as a 3DS charge, and the bank will NOT require the customer to authenticate. We will however still have all the benefits of a 3DS charge.
The result:
A reduced decline ratio, an increase in liability-shifted charges and an unaffected customer UX flow
On average, you might be able to apply Passive 3DS successfully to over 25–30% of your current traffic. That is a lot of traffic! Not only will your customers NOT notice the difference, but you will be protecting yourself an extra 25–30% from fraud related disputes given the charges are all valid 3DS.
Action 2:
Implement full 3DS charge attempt after regular charge attempt decline.
So, if action 1 succeeds, and you charged a customer with no additional friction via NON AUTH 3DS, great! Better conversion, and less chance of losing a fraud related dispute. You’re done.
But, if the 3DS object creation response would have in effect lead us to have to authenticate, then we’d rather try a regular charge first.
If we’ve determined that this is a low risk transaction, and then attempt a regular charge which is subsequently declined, our only option is to go for a full 3DS charge attempt.
One might think that if the charge was declined via a regular non 3DS attempt, chances of charging it successfully via full 3DS would not be much higher, right?
In practice, 10-15% of international regular declined charges with “do not honor” or “transaction not allowed” will succeed via full 3DS!
Of course, the customer still needs to properly authenticate and your mileage might vary depending on country, type of product, your merchant category code, etc.
Conclusion
If you have a broad and diverse inflow of international traffic and don’t have the patience, resources or time to develop local payment processor relationships, and you only work with one big payment processor, apply a PRE and POST regular charge 3DS strategy.
In 3 basic steps:
- Always start with a NON AUTH 3DS charge attempt. (Action 1)
- If that fails, attempt a regular charge.
- If that fails, attempt a FULL 3DS charge attempt. (Action 2)
Of course, this only applied to declines that are non descript and fall out of the “card expired”, “incorrect ccv”, etc.
Every scenario will be different, but if you do have international traffic using a single point payment processor, you have nothing to lose by trying this approach.
Caveats and a Final Word:
This works for us given our global footprint and the need to find the right balance between frictionless payments and a strong fraud barrier, but results will vary depending on your product and customer composition.
This strategy works with Stripe, but can easily be applied with other common payment platforms.
Update: We recently got word from Stripe that for customers on custom pricing, starting June 2020, Stripe will charge €0.03 per 3D Secure attempt.
It is not clear to me (nor to Stripe support yet) what is the exact definition of a 3DS secure attempt, so I’m not sure what impact this could have on this strategy. Is it the attempt to check if the card requires/supports/redirects/authenticates to 3DS? Or is the creation of the 3DS window regardless of outcome? 🤷♂We’ll see.
In any case, they say:
“This fee is to cover the additional cost charged by card networks and banks for use of the 3D Secure service”
😱😱😱😱😱… but this will be the subject of another post.
