I hate to see this honestly. Stripe is already notoriously vulnerable to credit card fraud and this is likely not helping their cause.
I'd love to know how long you should expect for an ACH payment to clear and into your bank account. The two day period for credit cards is so small. Who checks their statements every single day? This is obviously the benefit of using Stripe if you're the merchant, but it leaves you vulnerable.
We can only pray that Stripe accepts some responsibility for verifying these ACH transfers.
Fraud on Stripe is a two-fold problem. They've got fraudsters signing up for Stripe accounts and running cards through them. They've also got fraudsters making purchases on Stripe-based sites. Obviously, Stripe prefers that the charges are made to legitimate users. That way they're not out all the money.
Edit: It appears it could take "up to 5 days" for the payments to be processed. This is entirely on the bank's side of the equation. I guess from there you'll only need to wait your 2 days (7 days for some users) to receive the ACH into your bank account. I see massive fraud coming in here.
Plaid co-founder here. When users connect their accounts via the Plaid instant verification process, we actually allow developers to get a greater understanding of the user. Via Plaid, you can do things like validate the available balance and check the account owner's identity -- which can significantly reduce the likelihood of ACH fraud.
As someone who recently started integrating with Plaid in my app, I can verify that the extra information they give you access to is extraordinarily beneficial to better understanding your user. Also, asking for account and routing numbers is a massive inconvenience to users.
Unfortunately, that will only stop people who run around taking photos of other people's checks.
Does Plaid provide information about the location the checking account was initially opened or the general location of the account owner's residence? The biggest problem with Stripe is they provide ZERO checks on IP location + billing/shipping zip code, checking the email against known fraudulent email addresses, or shipping location against known drop locations.
I have just taken a look at your documentation! It seems very good. I definitely underestimated how advanced you are currently. It'll be interested to see how this plays out. You'll be tested by very smart people.
Right off the bat one thing you should really try to change is the lack of MFA by Wells Fargo. You should beg and plead to have them do something. They're by far the most available and cheapest accounts sold online.
I'm hoping "validating available balance" for a dev means "sufficient funds to cover this transaction" (which might not factor in any overdraft facility), and certainly not:
How does validating the balance and checking the owner's identity help? When someone's identity and bank credentials are sold (~$15-$300) it's usually very inclusive. MMN, DOB, SSN, previous residences, balances, cards attached to the account, security questions... It's not like people are just selling numbers from a check they found on the sidewalk.
No. Plaid instant verification uses your bank login info to get the ACH numbers along with current balance, etc. You can't get that just with account and routing number.
I mean, these are fintech companies we're talking about here. If you're signing up for these services your generally already deciding to trust the company with personal data. Plus, you still have to login to your online banking with Plaid, it's not like developers have unlimited, unauthorized access to you r account balance and transaction information.
There's a difference between - "I am paying you with ACH routing and account information" and "The payment platform exposes, to the app, my account balances". A huge difference.
Do users have to verify using Plaid for every transaction if there are recurring payments? Those seem the riskiest if someone has insufficient funds on a tokenized bank account
For credit card processing, automated fraud prevention does in fact come standard on all Stripe accounts and takes into account a great number of signals including some that you brought up below, like whether the location of the IP address used matches the location of the billing address.
For ACH, we've built even more stringent verification--as well as any other signals we might take into account, purchasers have to demonstrate, through microdeposits or Plaid, that they have direct access to the bank account in question.
It's impossible to prevent all fraud, but we take it very seriously and are investing heavily in continually improving and expanding what we do there. It sounds like you may have had some specific bad experiences, and we'd love to hear your feedback and suggestions for improvement. Please do reach out--I'm mlm@stripe.com.
Your description does not match Stripe's documentation. Specifically, there's no mention of matching geo-IP to billing address.
The problem I see with Stripe's fraud prevention is that it appears to be "all or none", with no visibility or control on our end.
The only control knob appears to be whether to allow Stripe to automatically decline things it thinks are fraud. It doesn't appear to provide any detail on why it thought something was fraud.
So it seems to leave two choices:
- Allow stripe to decline things, and try to address false positives manually. There is no "go ahead and charge this button", by the way...you would have to contact the customer.
- Set stripe not to decline things, but lose even the limited visibility to "stripe would have declined this".
The real problem, in my mind, is that fraud risk for both the banks and providers like Stripe is really small. You risk very little.
The vast majority of the cost goes back the individual merchants/sellers, who have the least visibility into what the risk of an individual transaction is.
Thus, there's very little incentive for the banks, or stripe, to provide decent tools. A shame, because your ability to see the bigger pictures means your tools would always be better than anything we can use.
We've been thinking about (and working on) a lot of these issues--we're definitely aware that users would like (totally reasonably!) more visibility and control. If you have any more feedback, I'd love to hear it!
Appreciate the response. I suppose the most simple change would be visibility to "would have declined" if the "automatically decline detected fraud" buttons are set to off.
That would allow the flexibility for merchants to make their own decisions without the hassle of manually dealing with false positives. The trouble with the false positives is that you have to talk the customer into entering all their data again, without having anything specific to tell them, like "Er, you were declined, but I have no idea why...can you try again?".
Adyen does a good job providing a developer-centric platform with robust controls around fraud rules and other elements. I'd encourage you to benchmark them. You and your colleagues can also drop me an email anytime to discuss: ben.brown@firstannapolis.com.
We've been using Stripe ACH's payments for a couple months now (coming from Balanced), and the whole process, from charge to bank, takes around 7 business days, and the statement shows up on day 1.
I consider this a long time, so long, that I'm actually considering on working directly with a bank myself and plugging into ACH network directly (The way we operate, its faster for some clients to just be paid through PayPal and cashout through PayPal).
As far as fraud goes, ACH charges can be reversed with no questions asked for 60 days if it turns out the charge was unauthorized (with no recourse, except asking the customer). On the other side, if a fraudster has your bank credentials, and can confirm with micro deposits, this is no different than them going to PayPal or Venmo with that same information.
Sift Science (http://siftscience.com) CEO here. We focus on helping online businesses like Airbnb, Match.com, and OpenTable automate away their fraud problems with realtime machine learning. Many of our customers use us an additional layer of protection in addition to what Stripe or any other payment gateway offers. I'm happy to answer any questions about fraud.
What products are you selling? If you sell something high value and easily resellable then you should count your blessings. It's become a bit harder to identify a Stripe-based site without investigating.
Even with zip code verification you have minimal protection. There are no geo-location checks for IP + billing/shipping zip code or other protections. Stripe should bundle with a service like MaxMind IMO.
Some companies layer external fraud protection on top of stripe. Have you tried any of those, or do you know if other payment processors (braintree, adyen, etc) have better built-in fraud protection?
I like Braintree's model a bit more, the provide the API consumer with the raw AVS and decline codes from the card processor (while Stripe just says "card_declined"). Braintree also allows you to do finer grain controls such as "Decline charges that fail a zip code check for charges over $500" or "Decline if the bank doesn't support zip code checks."
And with about 2 lines of code you can add more advanced things like device fingerprinting and geolocation through Kount.
*Disclaimer: while I don't work for Braintree yet, I start there in June (though my experience with Stripe is very strong).
> "Decline if the bank doesn't support zip code checks."
Being able to turn that on & off would be incredibly useful. As far as I know most non-US banks don't support zip code verification, so enabling it effectively blocks international transactions. It's frustrating trying to explain to a small non-technical business the difference between "zip code check not supported" and "zip code check failed".
I am the Product Manager for risk/fraud at Adyen and I can speak to our capabilities briefly.
In short, we provide an in-house risk framework that has features ranging from device fingerprinting, network-based transacation linking, Dynamic 3D Secure, velocity/consistency/referral checking, behavioral analytics, and more. We feature both standard velocity-based rules and a lot of unique whitebox ML-based logic that is very open to tweaking and customization.
We are in a fortunate position (being payment platform). This enables us to have access to a lot of the data necessary to identify fraud (raw issuer responses, full visibility on the auth flow, etc.), so we've been able to build a considerable tool-set.
That's what I've heard in the circles. I'm inclined to believe it. Security over mobile is lagging behind desktop. The tools to spoof geolocation and device identity are light years ahead.
I'm the Security Lead at Braintree. I am not sure what you're hearing in these circles. If someone could send details to security@braintreepayments.com we'd be happy to take a look.
The micro-deposit requirement or Plaid (logging into the bank account) should ideally minimize fraud. But for consumers ACH fraud is sadly way more difficult to deal with than credit card fraud.
It is quite easy to get access to high value checking accounts for less than 50 USD. They could be personal or business. For between 25-75 USD you could get access to all the login information you need to access Wells Fargo/SunTrust/BoA accounts. You could see both Plaid micro-deposits. Even PayPal has faced this issue and they're solution was to be a huge pain in the fucking ass to users.
Balancing convenience with security for ACH is not an easy task. That's why ACH is so damn hard to do online.
I'd love to know how long you should expect for an ACH payment to clear and into your bank account. The two day period for credit cards is so small. Who checks their statements every single day? This is obviously the benefit of using Stripe if you're the merchant, but it leaves you vulnerable.
We can only pray that Stripe accepts some responsibility for verifying these ACH transfers.
Fraud on Stripe is a two-fold problem. They've got fraudsters signing up for Stripe accounts and running cards through them. They've also got fraudsters making purchases on Stripe-based sites. Obviously, Stripe prefers that the charges are made to legitimate users. That way they're not out all the money.
Edit: It appears it could take "up to 5 days" for the payments to be processed. This is entirely on the bank's side of the equation. I guess from there you'll only need to wait your 2 days (7 days for some users) to receive the ACH into your bank account. I see massive fraud coming in here.