> We actually have an ongoing project to reduce the occurrence of these mistaken rejections by 90% by the end of this year. I think we’ll succeed at it. (They’re already down 50% since earlier this year.)
More important than that is provide a way for people to get this revolved without having to make the front page of HN.
One particularly frustrating aspect of fraud prevention is that fraudsters are better than the rest of us at getting human support staff to do what they want. They have way more practice, and they learn techniques that work from other fraudsters.
I'll say the same thing about fraudsters I tell clients about hackers, ransomware gangs, etc. What they do is their jobs and some of them are quite good at those jobs. Don't think of them as the stereotype angry teen that might have come to mind 30 years ago - these days it's more likely that they look just like your IT department working from home - or like technical employees in a Russian government office in Moscow.
> One particularly frustrating aspect of fraud prevention is that fraudsters are better than the rest of us at getting human support staff to do what they want. They have way more practice, and they learn techniques that work from other fraudsters.
Then put a flag on that account. Repetitive issues will make it clear what's happening.
Fraudster also doesn't have the same needs as most customers, they don't need to keep the same account... at best the same account will barely give them more credibility, but that would no longer be true if a flag has been raised previously.
There's plenty of ways to verify identities, use that when a flag has been raised previously. Again, something that sure a fraudster can do but lower odds than an actual customers.
It's never that simple. You're implicitly assuming that a fraudster wants the account long term, which is rarely true.
And identity is a VERY complex area, and nothing like as simple as "plenty of ways to verify identities". Particularly noting that fraud is often carried out by leveraging many partial opportunities: I use the (false/stolen) identity from over there to carry out of the fraud over here.
> You're implicitly assuming that a fraudster wants the account long term, which is rarely true.
Wait what?
Here my comment:
> Fraudster also doesn't have the same needs as most customers, they don't need to keep the same account...
How does I assume fraudster wants the account? I'm arguing the reverse, that they don't want it, thus give more credibility over anyone doing effort to get his account back. I don't understands that part, feel free to clarify it.
> And identity is a VERY complex area, and nothing like as simple as "plenty of ways to verify identities".
I was arguing that opening up customer service for theses instances won't be a huge risk if you keep a flag on the account as they fraudster don't need the account long term (as you seems to agree).
Doing others verification is to reduce that risk further, risk that I already consider minimal. No one said that it would be 100% effective, nothing is perfect, sure some will be able to bypass, but as I said, they don't need to.
> Particularly noting that fraud is often carried out by leveraging many partial opportunities: I use the (false/stolen) identity from over there to carry out of the fraud over here.
Yup, thus why getting more proof of the user identity will allow to confirm he is actually who he is claiming to be. Here in Canada we can do that at Canada Post office. It's not something Stripe ask for, thus if someone with a flagged account ask to get it back, doing a local verification will most probably be harder for him.
I know it’s not an ideal support mechanism, but I think this is one of the services HN provides to the community (informally). It can provide backdoor/informal channels through engineers and founders to some rather large companies. Especially when other avenues fail. But for the community, in this case, not only Stripe gets to learn about the issue, but we can all take something from this about automated systems and needs for manual overrides/reviews. This type of “case-study” can help many other companies avoid similar problems.
But we also get some of the back story from Stripe about why their systems are designed this way. What challenges they face that made these engineering choices make sense.
I’m sorry that this happened to the OP. But at least this channel of communication exists. And I think we can all benefit from it.
It only exists as long as the post gains enough attention to get to the front page. Which doesn't happen for every post - not even most posts - which makes it an exceptionally poor avenue of support.
> I know it’s not an ideal support mechanism, but I think this is one of the services HN provides to the community (informally).
I would like to know where and why Stripe's customer support failed in this case. Or even if it failed at all. Those are the only relevant details.
It's immaterial to the discussion whether any other web forum was used as an alternative to Stripe's customer support. I'm sure HN didn't signed up to be any company's customer support channel, or if it's reasonable to get it involved in this ordeal.
If I have a problem with Stripe, I want my business to be dealt with Stripe directly, and in the process not get a web forum involved. I would hate to be in a position where escalating an issue so that it becomes a PR issue as well is seen as the first step in a problem-solving workflow.
Maintaining the magic abuse detector requires secrecy around the heuristics, which means not always giving the clearest error codes/any error codes to the user re: what's wrong with their account/transaction.
Only a few HN posts can make it to the front page. Only if you are lucky then you will be able to raise your voice through here. So I assume there would be many users out there affected like this and their issues were never resolved.
More important than that is provide a way for people to get this revolved without having to make the front page of HN.