[sixhobbits]

I really hope that this improves the false-positive rate, as mentioned in another comment.

We've been hurt badly as a startup breaking into the US market and getting many of our genuine charges blocked by Radar (and at a "highest risk" level where it is not possible to disable rules).

As a developer, I had the best possible impression of Stripe, as they provide easily the cleanest API and best documentation of any payment provider I've used.

From a business side, it was highly frustrating losing so many of our early US sales. A lot of this was due to US banks blocking the payment, but Stripe did not handle these cases well in our case.

* Error messages presented to the customer are often ambiguous or misleading, and if you're using checkout.js you cannot customize these easily. In some cases, the customer gets a client-side "Card is declined" error, with no communication passed through to the merchant at all, which makes telephone support very difficult.

* Stripe will not provide any kind of telephone or chat support to merchants. By the time a specific blocked payment can be escalated to a "fraud specialist" the customer is usually long gone.

* Stripe will not allow you disable certain Radar rules.

* If a user tries to pay several times (due to their bank blocking the payment as suspicious), and then phones their bank to clear the payment, Stripe will often then block the payment due to "repeated attempted uses of the card". This is highly frustrating as even very determined customers who try several times and then contact their bank to resolve the issue there still get blocked by Stripe, and usually give up at that point.

* We had one payment blocked by Radar due to it being from a "high risk location" (Pakistan if I remember correctly). This represented unacceptable levels of discrimination for us. Machine learning and probability is useful, but ethically it's hugely problematic to deny people service based on their country, race, gender, age, or other attributes that they do not have control over.

My early experiences with PayPal were nothing short of terrible, but BrainTree is looking like a more and more attractive alternative to Stripe, especially with the PayPal integration built in -- if people have issues with their Credit Card they can simply pay with PayPal credit instead.

[freehunter]

>We had one payment blocked by Radar due to it being from a "high risk location"

This, to me, represents the worst that banking fraud protection has to offer. Just yesterday I (from the USA) tried to purchase a software license for a tool I've been using the free version of for a long time. My card was declined, so I used my American Express. About two hours later, I got a call from my bank's fraud department saying they had blocked a transaction to the UK for fraud prevention, and disabled my card to protect me. Apparently the bank (a small US-based bank) block any transaction in the UK as it's a "high risk country"... I'm sorry, but this is the Internet. No one cares where the company is located, and I have no way of knowing beforehand that the payment is processed by Stripe US or Stripe UK. Blocking entire countries for fraud prevention is a really lazy way of doing fraud prevention.

But I've even seen worse at another bank. My area of the US doesn't have Publix grocery stores. Apparently this bank considered shopping at Publix to be unacceptable risk when I was traveling for work, and disabled my debit card because of this. Stopping at Walgreens beforehand and getting dinner the night before wasn't suspicious though.

Bank fraud is a hard problem, and taking lazy solutions doesn't solve that problem. It just hurts customers and hurts businesses.

[bonestamp2]

This reminds me of Bank of America and Air Canada. I used to fly to Canada every week for work and every week my card would be declined by BoA when I tried to book on AirCanada.com.

I had it down to a science, I knew the direct number to their fraud dept and I knew when I should place my call so that I'd usually be connected at just the right time to get the charge authorized with enough time to avoid the website session from timing out, although sometimes I'd have to start over. Eventually, air canada added a timeout popup which helped prevent this.

I tried everything to get BoA to fix this (escalating calls, writing letters, etc). By the end, I gave up and just accepted it when they "put a note" on my account so this "would never happen again". This went on for over 2 years. Thankfully my company switched our cards to another bank and I never had this problem again.

[dwyerm]

Heh. My bank did something right, and my yearly $AUS payment to Fastmail finally went through without getting flagged by the automated systems.

Alas, a human also saw the transaction, failed to read the note or look in the history and locked the card up anyway.

[asclepi]

Fastmail charges you in AUD? Weird, I know it's an Australian company but I paid for service earlier this month and was charged in USD. And I'm not misinterpreting the "$" as a USD-only sign, the invoice literally says "USD".

[nmjenkins]

(I work for FastMail) We charge in USD, but the payment is processed in Australia. For some reason, American banks often block all payments processed outside of the USA; it's like they haven't heard of the concept of the internet and global trade…

We don't see this problem with banks in any other country (not do I ever have the problem in reverse, buying goods and services from foreign websites with my Australian credit card).

[freehunter]

Working in information security, I see this a lot in security practices for US companies. The client says "let's block all traffic from outside the US" because they don't do business outside the US. Then come to find out they have contractors in India... and a partner datacenter in Singapore, and oh yeah their factory in China. And now the CEO is on vacation in Costa Rica and can't get on the VPN. And oh shit, there's the field office at one of their suppliers in the UK.

I say this as an American who has never lived outside the US but who deals with international clients regularly: the US seems uniquely inclined (in my experience) to think that everything they need falls within their borders, and everything outside their borders should be treated with suspicion. I've never had a German client want to block all traffic from South Africa. That's just an observation, I make no judgements as to why that is.

I did have an American university for a client who said "we cannot block or otherwise discriminate traffic from anywhere, since we have students or staff in every country outside of North Korea" which is a refreshing outlook IMO.

[asclepi]

Do you know if this mainly a Visa/Mastercard issue or does this affect American Express as well? The latter isn't a network of banks and seems to be less restrictive towards international payments, but I could be wrong.

FWIW, I paid with AMEX (using Stripe not PayPal) and it went through right away.

[dwyerm]

No, you have it right. They charge me in USD and I pay in USD but, as nmjenkins says, the payment is processed in AUS-the-country, though not AUS-the-currency. Sorry for the confusion.

For what it is worth, Fastmail has been as good as they can be with this issue, but they're at the mercy of my bank as much as I am.

[pluto9]

I had something similar happen a few years ago when I bought a ReSharper license and had to call the bank to reassure them that JetBrains is a reputable company. I found it odd that they blocked the transaction based on location (Czech Republic) alone instead of bothering to do any research whatsoever into individual vendors. It would have taken them all of 30 seconds on Google to realize JetBrains should be whitelisted.

[mlm]

We’re really sorry that you ran into this. There are a couple things we can help you with:

- We give users the ability to disable the default rules and mark transactions as safe if you write in to [e-mail] (so in the example you gave of a user clearing transactions with his or her bank, if Radar incorrectly blocked a subsequent payment because of high card velocity, you could mark it as safe and subsequent payments would be allowed).

- Radar surfaces the primary reason a transaction is believed to be high-risk, but that is never the only reason (so the primary reason might be that the IP is in country X, but that doesn’t mean there’s a blanket ban on X—just that that reason combined with everything else we saw across thousands of signals resulted in our giving the payment a high score). It didn’t quite make it in under the wire for today’s launch, but we’re working on making the explanations more detailed.

We believe that Radar 2.0 (and in particular Radar for Fraud Teams) should also be helpful here:

- With Radar for Fraud Teams, you can customize the threshold at which Radar blocks charges—so if false positives are very costly for your business (because you have large margins, e.g.), you can tune Radar to reflect that; you can also specify lists of trusted payment attributes to “allow” (if you have known good card numbers, e-mail addresses, IPs, etc.)

- Radar 2.0’s custom machine-learning models (for businesses that have enough data with Stripe) should adapt to the unique circumstances/patterns/trends of your business, and

- Radar 2.0’s ML overall has substantially improved performance, which you should see after you’ve upgraded.

[mehrdadn]

> so the primary reason might be that the IP is in country X, but that doesn’t mean there’s a blanket ban on X—just that that reason combined with everything else we saw across thousands of signals resulted in our giving the payment a high score

It might not be that one reason, but could it be something like the following two? Because that would be practically equivalent in terms of unacceptability:

1. Customer IP is in a high risk location, and

2a. Vendor rarely does business successfully with people in that location, OR

2b. Vendors around this region don't usually do business successfully with customers in that region.

("Does business successfully" here was meant to both encompass lack of transactions as well as lots of unsuccessful transactions; I'm asking about both possibilities.)

[mlm]

In short, no.

A little more color: Stripe’s incentives are aligned with those of our users in that we want to let through as many legitimate customers as possible. We keep a very close eye on false positives.

Our machine learning models examine thousands of attributes for each payment and make predictions based on how frequently the observed attributes were associated with fraud in the past. The comparison here is never just on one or two or three attributes (as in your example), and no logic is hard-coded.

[globile]

Agree. We have a non-US Stripe account, so we are heavily penalised when we try to charge the US market.

Large percentage of support calls start with "my bank blocked the transaction because it was international / fraud"

Incorporating in the US is not a feasible option. This is where Stripe's "Global" reach and 150 currencies loses a bit of power.

Would be great if there was a way non-US stripe merchants could bill us customers as if they were in the US. Sure it is more of a regulatory/legal issue than a technical one.

[iagooar]

Got the some exact issues that you mention. Also in the US, not that much in Europe.

Given the kind of company that we are, we lose way more from false-positives than from true-positives. With this system in place, Stripe is punishing legit users and businesses, with no way to change the default behavior.

I enjoy using Stripe as the next guy, but this needs to radically improve. At least provide me as a merchant a button to whitelist / accept a customer and override your rules.

[eeke]

(PM on Radar here.) This button exists! You can mark a transaction as safe directly from the Stripe Dashboard. If you don’t see this feature for whatever reason, just email [e-mail] and we’ll get you access.

[Silhouette]

You can mark a transaction as safe directly from the Stripe Dashboard.

But only manually and retrospectively, no? For an online subscription business with extensive automation, if one of us has to go to the dashboard to fix something like this, that sale was probably already lost anyway. More likely, that failed charge already resulted in cancelling the subscription and all that follows, with a relatively low chance the subscriber will start again later.

From various recent HN discussions, I get the feeling that the team at Stripe totally fail to understand how devastating these false positives are to the growth of an online subscription business. For example, I have one business where it's not unusual for the majority of the entire churn in a month to be due to unexplained card payment failures with Stripe. Based on a back-of-envelope calculation, that business would be around 50-100% bigger today if those charges had worked and everything else followed the usual patterns.

[patio11]

Could you write to us to speak in more detail about the business seeing a majority of churn due to payment failures? That’s surprising to us; we’d love to help you debug it. My address is my HN username at stripe.com. We’re keenly aware of how SaaS math works and are as enthusiastic about your business growing as you are.

It’s possible you’re using our Billing product, which gives subscription logic out of the box. It’s also possible you’re not, and have rolled your own subscriptions.

If you’re using Billing:

We take into account that it’s a repeating charge and special-case that for fraud detection purposes, because it’s highly unlikely that a happy customer decides to become a credit card fraudster N months in. We can also do dunning (automated recovery of subscriptions) via email, so a single charge failure shouldn’t result in you losing the relationship.

If you’re not using Billing: we have a way to mark a charge as safe when you present it via the API, which you could do on e.g. established customers. (On the charge creation request, pass in {"fraud_details" : {"user_report" : "safe"}} or whatever the equivalent is in your language of choice.) You can do this for any charge where your business has prior knowledge regarding the transaction; we'll both a) respect the decision and b) update the fraud model accordingly. Note that your customer's bank is the ultimate authority on whether a charge goes through; they may decide to decline it for a variety of reasons even if you and Stripe believe the charge to likely be good.

You have a business decision to make regarding what you want to happen in the event that all automated systems fail to get a user back to a happily paying state. One option is to automatically cancel the subscription. I recommend you don’t do that in a subscriptions business, unless you have very, very tight margins (e.g. physical product not SaaS). We expose an option in our Billing product to keep the subscription active even if it isn’t being paid; we’d probably recommend you use that option and only cancel subscriptions on an explicit user request. This is a particularly important thing in B2B SaaS, where price points generally give you enough of a budget to get in contact with substantially everyone who churns and where it’s very easy for a single person associated with an account to e.g. ignore a few emails about it accidentally without having the intention to cancel.

[Silhouette]

Thanks. One of us will be in touch.

[neya]

There is also another problem - exactly opposite to what you describe. Stripe can't block fraudulent payments as good as others (Eg. PayPal). I don't know why or why not, but they simply slip it up. And here's the worst part, when there is a chargeback, you can't get hold of anyone to prove your innocence and eventually the case will slide with the customer. If you are selling physical products, this sucks because the scammer now has your product AND your money. Sad.

To be fair, Stripe is excellent for developers. For businesses? Not so much. You're either stuck with a monopoly, with shitty documentation and archaic APIs (PayPal) but works well for businesses or you're stuck with a new age (Startup?) that's really great at everything except helping you make money.

Here's me hoping for a better Stripe alternative. There's really a lot of space in this market.

[ljm]

I didn't really think of it until I read this but it appears to highlight a situation I once had, and I assumed it was just down to a shitty Wordpress plugin implementation. I got 'declined payment' errors twice and, what's worse, the money was still taken from my account on both occasions! In one instance it was refunded five minutes later but the second failure didn't get the same treatment, so Stripe had rejected the payment after taking it, but my bank saw it as fulfilled.

I was lucky that the particular merchant was a friend, so I could personally reach out and see his side of the accounts and submit it as evidence to my bank, but I didn't think for a second that I could trust Stripe to handle that despite their involvement.

[edwinwee]

I work on Stripe support. Chat support's now available through the Dashboard Monday through Friday, 24 hours a day. We're testing phone support, and we're working to roll it out soon. If you do run into any issues, always feel free to email me at [e-mail]

[abcd_f]

> ethically it's hugely problematic to deny people service based on their country

Practically though I worked for a company that saw hundreds of purchases from the Vietnamese IP space of which only two were not fraud. For the rest of the world it was in inverse.

[sandGorgon]

In India, the government mandates 2 factor (usually via text message) verification for all card transactions.

It's a moderate pain in cases like Uber, but usually we have very few chargeback issues .

[ploxiln]

I think this is the one big reason why cryptocurrencies like bitcoin are not useless.

I'm not a big proponent of bitcoin etc, really, there sure are big downsides. But this is the big upside: the credit card system is "good enough" for average Americans and average retail chains, but breaks down all the time with international and/or indie stuff. (See also: random people banned from using Square for life, because the fraud detection algorithm can't handle them.)

[jhca]

Hey, would checkout Bolt. Know the team there well, and they’re very focused on false positive reduction, which they recently published a post on:

https://blog.bolt.com/better-fraud-detection-with-bolt/