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.
Stripe got their start by building goodwill in the developer community, optimizing the simple use cases that frustrated developers, and providing great, responsive support as they grew.
It seems very clear that an executive decision has been made to "grow past" that phase and chase up market opportunities at the expense of the people that got them to where they are today. They're quite literally letting their reputation with developers go up in flames to enjoy some cost-savings in their customer support department. And from all signals around here, they believe that having a few "(name) from Stripe here, email me about your problem" comments is sufficiently responsive to put out the PR dumpster fire. It's gotten to the point where it's pissing people off to see that more than it's curing any problem.
I am hopeful that someone at Stripe checks out the multiple negative posts about their company on the HN front page today and finally agrees that there is a deeper problem here that needs to be addressed head-on. If it was my company, I'd be in emergency mode after seeing HN today.
If the process was good, the tickets would be handled properly but perhaps with delays - that would be a growing pain. They can solve issues but slowly.
Support being clueless and unable to solve problems means thst the process is bad.
This seems to be the norm among modern tech companies (and maybe others). I think that a good deal of "value" (market cap) has been created over the past 15+ years around preventing customers from getting help, and therefore increasing retention and lowering headcount. There are even large help desk firms that basically specialize in software to prevent people from getting help from a real person. If we took this away and asked companies to actually support their customers, I think we'd quickly see that many businesses would no longer be viable
Even if they are viable, it would eat into profit significantly. It's a trade-off between customer happiness and profit. The reality is that even when a large number of customers are occasionally unhappy, they may still not leave the company/product for various reasons. Companies then choose to accept that custom unhappiness since it does not impact their revenue enough practically. Arguably, they have an obligation to make that choice. It's the "best" thing for the company, at least in the shorter term.
I think we need more competitors. I use Braintree, and their support response times are about two weeks, and the first response is rarely helpful enough to solve the problem. Well if my customer has a problem paying me, I can't expect them to hang around for two to six weeks while I "talk" to my payment processor.
Things seem to be universally bad, except some companies (Stripe specifically) seem to have really good PR.
Except this is Stripe we're talking about, so it should read “Neglect: Maybe if we starve the customer to death they'll stop bugging us.” They are the “food”, the connection to incoming nutrition in the form of revenue.
FWIW, while limited to a subset of technical issues and not for the majority of "support cases" their developer support on Discord has been excellent as I've used it several times. Someone immediately takes a look at your issue, if they have to leave they handoff to someone else and they are very thorough.
A customer once told me… “no one grew up hoping to one day be a customer service agent.” That is the reality and I’d add no one in an engineering or product roll is excited to work on or help solve the really boring hard problems… so we are left with the reality of either a product and the processes to support it are easy enough to understand and the number of potential gotchas are low enough that the need to have human interaction at scale need not be necessary.
There's two types of documentation. In one, the semantics of a method allow more than one reasonable implementation. For example, if a "sqrt" function receives a negative number, it would be reasonable for it to return NaN, to throw an exception, to return a maybe monad, etc. The user has a question about the implementation, and goes to the manual to figure it out.
In the other type of documentation, nothing exists to indicate that the user should refer to the manual for more details. If I call a function "int increment_by_two(int x)", there's nothing that would indicate a special value. If the manual states "Calling 'increment_by_two' will add three to the argument.", that would certainly be unexpected. Nothing in the function description leads a user to expect that they need to read the manual for more details.
I've only been on HN since around ~2009 or something like that (11 years), but most people I've met in real-life who are also on HN have been recommended to visit the site first time from fellow hackers, rather than via other websites.
I was a reader of Paul Graham's essays and website, which I believe is where I heard about it. Or it might have been reddit (which I'm sure I heard about via PG). I joined Reddit on January 25, 2006 and HN on February 21, 2007.
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.
In a high-value, low-margin business, reducing chargeback losses to almost zero might be worth the cost of a double-digit conversion drop. In other circumstances, the same numbers can be catastrophic.
It should be a choice a business can make based on their circumstances. Instead, the EU legislates conversion loss for everyone.
If you think about it, when was the last time you entered even a CVV2/CVC on Amazon? Compare that to most regular sites which require you to enter CVV. Some allow you to enter the card holder name and address, while others don't and just sent the shipping address you've entered.
And it's not like this is a surefire way to make things better anyway. Like was mentioned before, it makes people that know about these things queasy when a random site redirects you to your bank and wants you to log in. What better way to scrape bank login info than a fake login screen for your bank? It's like when banks introduced TAN numbers. Then indexed TAN, SMS TAN etc. What regular user that fell for the "Please enter 3 TAN numbers to verify your account" will figure out whether a shady site is scraping their logins?
In Norway after the redirect to the payment page from a bank to approve the transaction the only thing one typically types is the phone number and the birthday. The rest happens on the mobile.
A bank in Spain implemented this even better as one does not enter anything on the site. Rather one has to go to the bank app on the phone and approve the purchase there. The latter is very frictionless especially with biometric authentication.
> A bank in Spain implemented this even better as one does not enter anything on the site. Rather one has to go to the bank app on the phone and approve the purchase there. The latter is very frictionless especially with biometric authentication
Same here in France at my two main banks, LCL and Boursorama, the payment screen tells you to open the app and confirm the payment.
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...
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.
Edwin from Stripe here. Postmates started using Stripe as an SME, when they were probably smaller than your company. We’ve been scaling alongside them for the past decade, and the auth optimization features mentioned in the post weren’t built for them—they’re built for and used by businesses of all sizes. In fact, Radar’s ML was designed to become better as the network grows—the more card transactions it sees, the more effective it becomes (imagine the fraud data we learn from every Postmates transaction can be applied to your transactions too!). This is one of the principles of Stripe—and it’s our goal to help scale your company’s growth, just like Postmate’s.
That said, could you email me at edwin@stripe.com and we can take another look at the issues you mentioned? (For example, we honor rates for their negotiated term.)
The card issuers do their individual basic fraud detection (e.g. security code) but we built our own on top after users asked for something more advanced. Imagine Stripe seeing data across all the card networks, compound that with customer info (like email or IP, which card networks don’t always collect) across all businesses on Stripe, then that’s fed into our ML network that’s constantly tuned by Stripe engineers. And then businesses have the opportunity to customize all that with Radar.
True, but the big networks process far more transactions than stripe does, have access to more data (where else has this card been used lately, has the bill been paid, has this customer used the card in a shop abroad, etc), and seem in a better position overall to combat fraud.
The network also has access to the account holders phone number so can actually call to validate risky transactions.
Lower fraud rates would also make issuing banks more likely to choose visa over MasterCard, so be a competitive advantage.
> If you have a European Stripe account, billing US customers will not provide the same acceptance rates as if you use a US account.
Is this due to Stripe or due to the credit card providers blocking transactions? I ask because I have a card that routinely declines charges if I am not near my home. (I can temporarily expand "home" by adding travel plans in their app, but it's inconvenient.)
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?
Yes I feel roughly the same. Our experience as an EU stripe merchant with charging US cards is pretty great though. 97%+ acceptance if I recall... Brazil however is a very sore point. We hope to localize to Spanish and reach Latam though so we’re a bit worried. We heard it’s better than Brazil.
We’re still a tiny B2C though, so we definitely feel the complicated marriage side of things. Not to mention PayPal. The missing elephant in the room.
Brazilian dev with some experience in developing systems used across LatAm.
Honestly, it is a mess...
There are specific payment methods that are common in a single country where people prefer to use that instead of credit cards, as a result sometimes we have to integrate a bunch of different payment processors, a couple of them with non-existent or terrible documentation which result in a ton of emails and calls to clarify stuff.
Stripe is in Beta in Brazil for a while but I never developed something with it for the local market, there is a countrywide processor here that have great documentation and support everything that Brazilian customers are used to and the fees are in the same ballpark, so there's no need to use it.
> We heard it’s better than Brazil.
Which is funny for me, integrating payment processors in Brazil isn't a big deal and I had a lot of trouble with a few LatAm processors, but if I had to guess the reason I would say that a lot of old cards and cards for people with low income used to be national only, they couldn't pay anything in other currencies, nowadays the card situation is a bit better and most issued cards can purchase international goods but since stripe apparently is coming to Brazil, if you could process your payments through it it should work flawlessly.
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.
Might as well ignore the whole signal, and more now that anonymous and prepaid are gaining share.