This is the big problem with Stripe's positioning in the payments food chain ladder.
Block every single fraudulent or suspicious transaction, and you're leaving obscene amounts of money on the table.
The amount of credit card fraud that goes unclaimed or is eaten by liability shift is huge, so if Stripe makes a product like Radar ACTUALLY WORK, they would be missing out big time.
I am confident Stripe's radar's shortcomings are deliberate and not simple bugs or design problems.
It appears they have no incentive for the product to be 100% effective and that would explain why Stripe Radar is billed per screened transaction, regardless of outcome.
We benchmark Stripe Radar against other pure play fraud fingerprinting solutions, and the difference is abysmal. The fact that Stripe claims to have seen 80% of any card before it gets to your store make this fact even worse.
So, like parent says, you are going to see radar scores of 90 and 95 for certain charges (clearly fraudulent carding attempts), followed by scores of 15 or 20 for the same card, IP, fingerprint with absolutely no warning.
I've grown tired of escalating this to Support. They just give me the ML model answer. Basically: "It's a black box!"
You can definitely add a rule to start blocking charges from X places, or with Y velocity, or always enforce 3DS, but then you're taking the model into your own hands, and that has some important consequences.
Your acceptance rate goes down. You're heavily interfering with the model and relying (and trusting) it less, and you realise you really don't need Radar to do that for you.
If you're serious about fraud, you must use a pure player solution that is 100% aligned with your interests.
From what we've seen with Stripe Radar in the past, that doesn't seem to be the case.
I'm a big fan of Stripe in may ways, but I really have a love/hate relationship with this side of their business...
Stripe support is broken. I recall patio11 writing about how Stripe is all about putting in the correct "process".
Well, the process for support fails.
We handle a decent volume and have been a merchant for over 8 years. We can't even get an account manager to handle specific issues.
90% of requests are met with a subtle RTFM!
If you ask specific questions, these are avoided.
An open ticket is bounced from person to person. No two people seem to touch the same issue.
If you try specific chat support, and you ask technical questions, you'd expect some knowledge. Instead, most agents put you on hold and go over documentation, only to come back and say they've escalated this to a ticket.
Then the ticket comes back with more links to documentation, never answering the question.
The only way to make progress, answers and some human treatment is by jumping from connection to connection on Linkedin, trying to get an intro to someone inside.
It quickly gets complicated. There are many more variables to take into account.
- SCA exemptions
- Prepaid Cards (with no built in 2FA support)
- Banks in less developed markets (No 3DS)
- "We encountered a 3DS processing error" is a common nondescript message which occurs with international payments
For regular merchants, the decrease in conversion (double digit) is VERY far away from any improvements in chargebacks. Bear in mind that most merchants need to stay below 0.75-1% chargeback regardless of conversion/decline ratios.
We developed an internal 3DS attempt strategy to try to remedy this [0], but it is not ideal.
Basically, try 3DS (with no authentication), then try regular charge (NON 3DS), then if all else fails try a full 3DS charge. You'd be surprised by the disparity, especially internationally, and we do recoup some charges at the expense of triggering some unintended blockage.
When asking our provider (Stripe in our case) about the best strategy for this, it always comes down to , "Let SCA (Strong Customer Auth) rules and logic handle everything", but this simply doesn't work well.
I really wish the likes of Adyen, Stripe, etc...would help out with better decline ratio strategies.
I think we are all plagued by "do_not_honor" and "transaction_not_allowed" codes that do little to move us in any direction...
I might be oversimplifying but when you pay with a US card at a European Stripe Merchant, the acquirer they use locally will show up at your US Bank as "foreign", and this will trigger all sorts of things at the fraud/compliance level.
Stripe offers Atlas so you can "easily" open a US Stripe account and serve your US customers from there, but wouldn't it be great if Stripe did that for you automatically?
It is pretty clear by now Stripe has big guns pointed at enterprise customers. What others like Checkout.com, Adyen thought was a relatively safe moat, has now clearly disappeared.
However, I'm sorry to always be the sour grapes guy when it comes to talking about Stripe neglecting us SMEs.
I'm pretty sure a lot of these things mentioned in the article are being passed down to "regular" customers, but to be honest, it lately hasn't felt like that.
Last year there were a few price spikes, Radar fees that were initially negotiated where reinstated, same for refund fees.
Radar works great when it does, but has a lot of wonky stuff like not catching heavy carders which defeats the purpose of using rules.
Acceptance rates internationally are still lacking. If you have a European Stripe account, billing US customers will not provide the same acceptance rates as if you use a US account.
In some Latam countries the difference can be important.
Stripe is vital to our growth, but it is a complicated marriage.
I really hope they don't forget about us, the regular merchants.
Worth mentioning Shopify uses Stripe. A few months back they introduced their Shopify Payment Module (at least in Europe) which runs on Stripe, which then overrides and disables the standalone legacy Stripe module. You can't have both, and they don't straight up tell you this when you try their module.
They now absorb the commission into their pricing. Once you disable your standalone Stripe integration, it disappears and they only way to get it back is to cry to support.
Absolutely. Remember the "2014 Obama Unlocking Law" [1] ? It was supposed to not only not make it ilegal to carrier unlock a phone, but also forced all carriers to adopt a specific code of conduct to assist users with unlocking.
Fast forward 6 years, and it is much harder to unlock a phone than it was then. The whole thing backfired for consumers. It was actually easier to unlock a phone in a "non-legal" way before the law than it was right after.
This whole new code of conduct for carriers actually made them convert their SIMlock departments to be more like a customer retention lifecycle.
This mainly applies to US carriers (in the US and Latam), and there certainly are exceptions in Europe where EVERY cell phone is unlocked from day one, regardless of your contractual status.
Phone unlocking doesn't get much attention, but it is an integral part that no one wants to address or get their hands dirty with.
There are many more locked phones in drawers or acting as mere paperweights than people actually care to disclose.
Several years back we ran a poll to understand lifetime recycling habits.
People aren't proud of dropping a phone and shattering the screen, but they are less proud of having thrown a phone into a drawer because they couldn't be bothered to run the obstacle course set up by their telco to keep them in check.
Phone right-to-repair should be EXPLICITLY INCLUSIVE of unlocking, otherwise it is only solving a part of the problem.
Oh yes! To Grandfather or not to Grandfather! That dilemma!
I understand they are still using the same functionality they had at signup time, and are still on the same API version, so not taking advantage of new direct functionality.
Yes, of course there is a bunch of indirect functionality or magic behind the scenes, but from a company lifetime perspective, when you enter into an agreement with a service provider, you would expect a relatively constant delivery of services, at the agreed prices, especially if your needs have not changed.
There are many companies that upon adding new functionality or services, decide to grandfather. New direct functionality comes at new prices, even if you are inherently benefitting from the new stuff.
Three I can think of, Zendesk, Customer.io and Geckoboard grandfathered our plans.
When it is easy to switch providers, grandfathering is not that important, but if you're tightly integrated, which pretty much everyone doing volume on stripe is, then you're screwed. You can't leave.
Even if you negotiate custom pricing, there is a knock on the door one day saying, "new pricing in place. Take it or leave"
Same thing has happened for Radar for example. We set up our whole infrastructure with their beta 3DS and Radar products, and then one day (a few months back), it is $ 0.07 per txn in Radar as well as no returned fees on refunds.
Stuck with nowhere to go.
Not against improving margins, but customers that have walked hand in hand with Stripe for so long and seen them thru their early growing pains should definitely be grandfathered.
We have the opposite problem. People with 50 carding attempts and radar scores of 30 or so. There is no value in Radar if so many of these cases pop up because you can’t really tell the truth from the false.
We use Sift as a backup, and that makes it easier at the same time it as really showing how poorly Radar does in some cases.
Truth be told, it is really good with heavy “dumb” carders, but not when it gets complex. Hope this gets addressed at some point.
"I'm going to quickly shift from my terminal to this chrome tab to check this documentation but while it loads I'll get a dopamine hit from X."
Blur the screen and help me get back on track...