Stripe now supports ACH payments | Hacker News Reader

Stripe now supports ACH payments

stripe.com

424 pointscraigkerstiens192 comments

When I last worked on a billing system about three years ago, we looked so hard to find an ACH provider. There was just nothing out there. This is an enormous advance.

The problem we had was that we issued moderately large invoices monthly - they could be from $1k to $50k. We wanted to be paid quickly, so we tried to convince our customers to pay by credit card (through Stripe) and enable automatic payments, but we had trouble when customers would bump up against credit card limits.

So, for our bigger clients, we were relegated to asking for checks to be sent by mail. This meant we couldn't automatically charge customers every month, and instead needed to badger them to send their check - all of a sudden, we needed an accounts receivable team. We couldn't just ignore the problem since these were our biggest accounts, too.

Stripe's pricing is almost comically friendly here - credit card transactions are usually in the ballpark of 2.7% + $0.30, so even when card limits weren't an issue, we'd be paying out the nose on the transaction - 2.7% of $10k is $270. The new ACH payments would cost just $5.

Anyways, this is a serious accomplishment. The underlying banking regulations and technologies around ACH are thorny. Good job, Stripe!

It's insane how expensive financial transactions are in the United States. In the UK, the equivalent of an ACH transaction would be a BACS payment, which costs roughly 30p ($0.45) for a small business per transaction, although some banks will do them for free. Many smaller businesses however would just use Faster Payments Service for payments under £10K, which is like wire transfers in America, except they rarely cost more than 25p ($0.35) and once again, many banks will process FPS payments for free for small businesses.

Bank transfers don't really cost $5. The typical price for an ACH transfer is more like $0.05, down to $0.01 at scale. Stripe is making a nice profit on these because it's really hard to get an FI to do this for you if you are a startup.

The infrastructure is there. The government operates a realtime gross settlement system with ~$1/transaction cost to banks (FedWire). It even has the very nice security property of being push-based rather than pull. The problem is that banks all seem to have agreed to charge $25/transaction for it.

The problem is that banks all seem to have agreed to charge $25/transaction for it.

I believe in America this is called a "free market".

I mean, there is also a free market in the UK, yet Faster Payments Service transaction cost a fraction of what wire transfers cost in America, so what's the difference?

To explain the joke, the US system is cartelised, while the UK one is under a bit more political and regulatory pressure to treat customers fairly.

(Not that we haven't had a problem with BS fees or the payment protection insurance scandal!)

It's because of all the fraud on the backend they have to fight. I'm sure banks would like nothing more than to have a simple system where they only charge half as much but net 2x the transactions. Lots of overhead with fraud.

It's not. It's because the largest banks are all stakeholders in the Automated Clearing House system, they make far higher margins on faster out of band methods (wire transfers), therefore it doesn't behoove them to improve.

There is some progress being made though, slowly and painfully.

http://www.npr.org/sections/money/2013/10/04/229224964/episo...

I should also note that there is powerful Fed-chartered initiative, called the Faster Payments Task Force, going on right now. It combines +300 of the nation's payment stakeholders (including big banks, networks, retailers, etc). We've made a ton of meaningful progress on speed, standards, and more.

Big news coming in the next few weeks...

(learn more at https://fedpaymentsimprovement.org/)

Thanks for the effort, and for posting this.

I had no idea about this. Thanks for posting this and make sure to post an update on your "big news".

This is interesting, would like to see how it might help Kiva some day more efficiently transfer money in the U.S.

Thanks for your contributions to the FPTF, Jordan!

Same Day ACH has been in the works for a while; however, a payments expert I spoke with said all the big banks are opposing it since (a) they make more on wires, as mentioned, and (b) most of them have in-house same day transfers, so it's an argument for opening multiple accounts with them vs at different institutions.

https://www.nacha.org/content/same-day-ach

The electronic financial system in the US is an embarrassment, to be honest. Instant transfers have existed in other countries for years. The only platforms that allow instant payments require (a) holding money in their bank account (e.g. your Venmo balance) and (b) the companies to comply with incredibly stringent money transmitter laws.

From what I've heard, Stripe doesn't make much from CC transactions (hence why almost all providers are at the same pricing). ACH costs fractions of a penny, so even if they only make $5 it's nearly 100% profit.

[Note: I'm not a payments expert so would love if someone who is could (in)validate all the above.]

Large banks aren't opposing faster payments anymore. It's my understanding that the NACHA membership voted to approve Same Day ACH and it will be phased in over the course of 2016-2018. In addition, the largest FIs are creating an actual real-time ACH system through The Clearing House, which has licensed technology from VocaLink (the developer/operator of the UK's Faster Payments system) and FIS to do so.

there's also the problem that it's a bit vague as to who can actually enforce faster payments. The effort is currently led by the FED, but they technically don't have enforcement power, the CFPB could do something but that'd be a bit of a stretch.

Additionally, the large banks are trying to influence the rules and requirements; for example, clearXchange + early warning system merging under a (large) bank consortium

All of the above is correct.

I believe they also like the float on the slower methods.

That doesn't explain anything. The UK has a similar level of fraud, and banks are just as required to pick up the bill as in the US.

Banks DO NOT pick up the bill for fraud in the US. The end merchant/seller does.

Edit: Downvote all you like. It's the truth. When the chargeback comes, you pay Stripe/Paypal/Etc a fee, and they yank the funds out of your account. Whatever item you shipped is gone.

Edit 2: The liability shift referred to below doesn't apply to online transactions. Card not present fraud is almost 100% on the seller/merchant. And given that the context is Stripe, well..

I don't understand why this is being downvoted - it's correct.

It is the case that banks pick up the tab for transactions where the card is present, hence the move to EMV chips. However, merchants have liability for transactions where the card is not present, i.e. every Stripe transaction.

I upvoted, we had ecommerse store and we used authorize.net (it was like 10 years ago), every time we got a chargeback because of fraud - authorize.net deducted money from our bank account.

Online transactions using Visa's 3DSecure/Verified by Visa or MasterCard SecureCode will shift liability to consumer though.

I think 3DS may work better in Europe, but here in the U.S., it just doesn't.

It requires the use of a password, and adds additional steps to the checkout process. You can't really make it mandatory on your store, as conversions/sales would crumble. So, you make it optional.

If it's optional, only the most security conscious customers end up using it. Those are the customers with the lowest risk of having their card info stolen, and the most likely to report it quickly if the info is stolen.

So it adds more protection around a tiny fraction of your sales...the sales that were already very unlikely to be fraudulent.

It doesn't make any notable change to "the cost of online fraud in the US is 100% on the merchant/seller".

Why would 3D-Secure work better in Europe than in the United States? I fail to understand that from reading your comment.

Yes, it requires extra authentication (My issuing bank has chosen password as the auth - some others use the bank code boxes for One Time Tokens). All online stores that I routinely buy from in Sweden and in Europe have 3D-Secure turned on. The only exception I've encountered is an airline.

The customers don't get to choose - it's not optional for customers. It's optional for merchants/shops. If they however disable 3D-Secure: They're liable though.

Are you sure about that? The Verified by Visa site says that the liability shift is to the card issuer, not to the consumer:

https://usa.visa.com/run-your-business/small-business-tools/...

Ah yeah, but many issuers push it down to the consumer, basically the same case as when you've given the card PIN away.

I don't think this is true. So many shops these days sell fulls (inc SSN, DOB) at reasonable prices, some including even VBV/MSC passwords; you can filter by non-VBV/MSC as well, making VCV/MSC useless.

And if you really know where to look, the ability to look up someone's SSN will only cost you a buck or two.

That's not true for card-present transactions.

Before October 2015, issuers ate the fraud, not merchants.

After October 2015, the "liability shift" means issuers won't eat the fraud if it's a chip card and the merchant didn't use the chip reader. Otherwise, they still eat the fraud.

http://www.emv-connection.com/downloads/2015/05/EMF-Liabilit...

That's only for in-person transactions. Fraud from card-not-present transactions that are Stripe's bread and butter still falls on the merchant.

Updated accordingly.

I wonder if fraudulent transaction levels are similar in the US to those in the UK and if no, what the reason is for the difference (and if yes, why the transaction costs are so much higher in the US).

One reason why it might be much higher in the US is the prevalence of swipe and sign. In Australia signatures are no longer allowed and essentially all transactions are chip and pin (or tap if its under $100). This basically eliminates in store fraud as a chip cant be skimmed. No idea why ACH is so expensive / terrible in the US compared to other countries, I guess its the number of banks?

In India, there's a protocol called 'IMPS' that allows instant transfers. The cost per transaction is a measly Rs. 5 (around $0.08).

Other issues in India prevent IMPS from reaching scale:

- No bank account verification APIs - Recurring payment support

who are you billing in the >$25k range that doesn't have the ability to send payments via ACH and will do so free of charge.

I bill pharma and biotech companies and regularly receive payment via ACH and did not require a service provider and have never paid a fee.

I do need someone to reconcile the incoming payments to a particular account, but that really isn't a huge deal (and could be awkwardly automated already as they send an e-mail Remittance Advice the same day).

Maybe there is some intermediate set of customers, but for me, any customer paying large invoices regularly already is set up to pay by ACH.

I think it's more that you want it to be part of an automated system. Ideally, it should be set up to autobill every month and reconcile those transactions automatically (like what you can do with credit cards).

The vast majority of customers do have access to some sort of ACH payment system, but it's not automated. You still have to pester them to pay each month.

Have you tried Digital Checks ? https://www.checkbook.io https://youtu.be/N4X79qkEmog ? All the convenience of ACH plus work with non-ACH enabled bank accounts. Not all bank accounts are ACH enabled. Also ACH requires financial/bank info and verification from recipient and while Plaid solves it for some banks the recipient/sender may not be comfortable sharing it. Digital Checks have no such requirements. $1/Check regardless of transaction amount.

Digital Checks/e-Checks are very fraud sensitive. They usually clear just 5-7 days later and I have seen cases where the merchant lost tens of thousands of dollars.

Digital Checks can clear overnight (just like Check21). Much faster than ACH. As for fraud the rules are no different than ACH.

Doesn't ACH processing cost a lot less than that? If I remember right, Dwolla used to charge $0.25 and I think they made it free.

Wells Fargo CEO can do it. IIRC it wasn't cheap unless you have high volume, though.

I haven't seen it first hand, but lots of our current customers ditched them (and others) after working with their APIs or lack thereof (#xml).

In general, ACH just wasn't built to accommodate "platforms" as an entity in the transaction cycle. Banks, while although cheap, have a problem reconciling their infrastructure and processes with today's expectations. Not to mention their services don't package or include other compliance required to leverage ACH legally (KYC, OFAC, reporting, reject handling, etc.).

Bottom-line: ACH and traditional providers are not suitable options for today's platforms. Among others, banks are hemorrhaging ACH-related business to companies like Stripe and Dwolla.

>Bottom-line: ACH and traditional providers are not suitable options for today's platforms. Among others, banks are hemorrhaging ACH-related business to companies like Stripe and Dwolla.

AFAIK, to plug in to the ACH network, you have to work with a Bank that has access to FedACH/ Electronic Payments Network. I know Dwolla has its own Payments Network, FiSync, but the number of banks on this system is very small. So in many cases its not so much that banks are hemorrhaging business, but Stripe/Dwolla are selling KYC, OFAC, reporting, reject handling, etc related services.

Can you tell me where I can find information about the compliance requirements for ACH transactions?

How much time do you have? The rule book is like 600-700 pages. The best route I recommend is to engage your bank or processor, like Dwolla or Stripe, with your use case. They should be able to quickly identify what the requirements are for your platform.

With those size payments, why didnt you just send your bank account details and have them ACH/wire payments to you?

Usually the hassle is in sending payments, not receiving them.

Yep it's good news. Chargify has been doing it since early 2014, but for a lot of Stripe users it's nice to be able to continue using their API for it.

Hmm, that sounds a lot like what I was doing a few years ago...

Oh. Hey Spencer. ¯\_(ツ)_/¯

we have a commercial banking platform (from a brand name bank) with ACH origination. did that not work/was that not available to you?

In college I worked part-time for a music social network startup that sold songs and paid artists a commission, kind of like iTunes. I had to write a cron job that would issue the artist payouts every night by writing ACH files in plaintext and SFTPing them to SVB.

3 years later it's great to see Stripe providing this, but I will always have an oddly fond memory of working on that. It felt so obscure and unnecessarily difficult.

> It felt so obscure and unnecessarily difficult.

I earned a bit of money in the 90's doing a lot of those types of data transfers. I get the feeling 70% of IT is just data munging.

> I get the feeling 70% of IT is just data munging.

The remaining 30% is, as far as I can tell, fixing bugs in the data munging code.

Leave some room for the UI folks - although that is basically getting humans to munge the data as a pre-step for the computer munging.

Wow, this is oddly familiar. I wrote some software for my company to crunch tons of payment numbers on demand which eventually boil down to writing ACH files in plaintext and SFTPing them to SVB(although SVB really only processes them twice a day).

I'm pretty stoked Stripe is supporting ACH now as I have other products that customers would like to pay with ACH rather than credit. But I don't think the Stripe product just released will help send money from control accounts(and replace SVB origination), just accepting incoming ACH payments from customers to our own company accounts.

Writing files in plaintext and SFTPing them is still a r equirement when working in the insurance world :(

Sounds like a business opportunity...

Only if your business is "writing files in plaintext and SFTPing them." Payers are basically immune to technical disruption, and it's really not worth the effort trying to create friendlier facades on what are essentially 1960s-era business and EDI processes. Someday they'll catch up technically, but until then med-fin-tech startups are punching boulders uphill.

Do I sound bitter? I think I sound bitter.

> Someday they'll catch up technically.

Going to need some really good people in Congress to start. Good luck finding them!

Do I sound bitter? I'm bitter.

Yes, but probably a business opportunity to write an API layer over the top, that writes files and SFTPs them on the backend. Sadly.

I always love memories like these. Looks like you found a pain point with a clear value-add solution. Hindsight is 20/20, but I always wonder what would have happened if your startup pivoted to offering ACH as a service....

Is this satire?

The UI component presenting the login form for major banks is troubling. It seems like encouraging users to feel comfortable entering their online banking credentials into anything other than their bank's web site is a bad move.

Until banks get developer friendly and support OAuth, I'm not sure what else you could do if you want real time verification. I guess micro deposits could still work if you had faster rails, but ACH is still a batch process.

> Until banks get developer friendly and support OAuth

We may wait a long time for that one.

Not necessarily. BBVA has already this with Dwolla's real-time payment tech, FiSync. (Limited, I know, but it's the only cool proof of concept like it out in the wild)

Also, there's been a lot of work done through the Fed's remittance coalition on a supradirectory for destinations. Adding authentication capabilities would be the next logical step and they've already committed to using open standards (lots of ISO stuff to compete with though). Combined with whisperings of big bank projects and JP Morgan's CEO very vocal hatred for screen scraping, Oauth could be a powerful and quick-to-market alternative.

I have a feeling that ACH payments are mostly only going to be widely adapted in instances where the purchase price is very large (5 figure+ transactions) where you have a dedicated account rep. I think it'll be quite a while before users are comfortable entering in their bank account login info to buy a $30 product.

And where the purchase price is large, those customers don't want some 3rd party interface to send the ACH...they typically already know how to send an ACH. They just want your account+routing so they can do it.

In short, this solution from Stripe fills a niche, but it's a very narrow one.

>In short, this solution from Stripe fills a niche, but it's a very narrow one.

Not too sure about that. Klarna in Europe has a similar system called SOFORT in a lot of countries processing millions of transactions [0]. According to a german article, they processed 2.4 billion euros in 2013 [1]

iDEAL using a similar system (officially provided by banks though) is the most popular payment method in the Netherlands [2].

There is probably a big market for bank transfers with instant confirmation for the merchant. I agree with you though that it is a niche in the US, because credit cards are so common. Expansion in the EU would've probably allowed them to access a bigger potential market.

[0]: https://www.sofort.com/eng-GB/press-releases-sofort-gmbh/pre...

[1]: https://translate.google.de/translate?hl=de&sl=auto&tl=en&u=...

[2]: https://en.wikipedia.org/wiki/IDEAL

The European payments landscape is much, much different:

1. Because they make less money on cards and card networks are controlled by pushy American corporations, European banks actively campaign against the use of cards online. So instead of feeling confident in Zero Fraud Liability as they are here, consumers in Europe are scared of getting hacked.

2. In some countries, banks don't even print the card number on the card, so you can't use them online if you want to.

3. Cards do not have rewards, so there's much less incentive to use them, even if they could.

4. As a result, consumers are accustomed to using "bank buttons" which let them log into their bank site to push a payment.

5. But that becomes really complex when you have more than 6 banks in a market, so solutions like SOFORT simplify by creating a centralized bank button.

In short, Americans value rewards and convenience whereas Europeans value security. There have been several ACH-based online payment efforts in the US (eBillMe, Mazooma, Noca, etc.) and all have failed.

I would also argue that ACH process $40T a year, while all credit and debit card networks move a collective ~$7T.

What portion of the $40T do you suppose, though, is the type of transaction that would move to something like Stripe?

At least in the U.S, Stripe's opportunity is moving more of that $7T to ACH, not moving existing ACH to their platform.

ACH for B2B is a significant chunk of that money, so is payroll. It's also admittedly misleading because the card networks use ACH significantly to settle money from Bank A to Bank B (i.e. on "the backend").

This is poignantly addressed by @PC's comment addressing whether or not this would be available with Stripe Checkout.

ACH, for now, is generally terrible in retail situations. NO one wants to wait an additional 2-3 days (to all for funds to clear) to see their shipment be sent from Amazon. There are some niche use cases where it may work for pay-ins, for example online custom wood shops—where there's a built in delay to build the product—or other services where physical products don't need to change hands.

Thats a Plaid thing, users could just enter their routing number and account number.

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.

Yes, Plaid can help with most of this. You can see the full docs at https://plaid.com/docs for more details.

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.

Couldn't agree more.

I wish I had the software skills to fill one of your open positions. I'm in love with the subject, but don't quite have the technical skills.

I'll hear a lot more about beating your system in the future. I'll pass along whatever I hear.

Any plans to come to the UK?

Yikes, am I understanding that correctly?

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:

"developer can see account balances".

Fraud expert here:

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.

Wait, so if I pay someone with ACH, they get to see how much money is in my bank account? WTF?

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.

Yeah, like I mentioned upstream, not sure why any developer should have access to my account balance...

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.

No. Plaid does it all in the back end and issues the merchant a "Pass"/"Fail" on verification.

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

No. Plaid tokens live for an extended period of time and can be used for multiple balance verifications.

Please read my response below.

(I work at Stripe.)

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.

This is not coming from a specific bad experience. Quite the opposite. I just got home from a commute. I will email you shortly.

I am curious how good it is if it is standard.. Some how major vendors lost quite a lot of money on hoverboards with Stripe.

You mention Plaid for bank data scraping, but what do you do for the other banks Afaik Plaid supports about 12-13 banks (~80% population coverage).

Plaid will be rolling out support for many more banks in the coming weeks.

that's fantastic news and congrats on your deal with Stripe and your new funding.

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.

Can you talk about why you moved from Balanced? They've had AHC payments for a long time, haven't they?

they shut down and migrated all their users to the stripe ach Alpha

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.

Email me :) rwmurray(@)vt.edu

Really? I've been using Stripe for a couple years and never had a problem with fraudulent transactions. Do you require zip code verification?

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.

Power supplies for Bitcoin mining. http://gigampz.com

I dont own or support this product, but whoever downvoted, the parent clearly asked what the product was.

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".

Anything PayPal is intense. Security>convience with them

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.

You can see our risk documentation here: https://docs.adyen.com/manuals/risk-manual

And our general overview page here: https://www.adyen.com/home/payment-services/revenueprotect

Feel free to get in touch! brian.dammeir@adyen.com

BrainTree is incredibly vulnerable over mobile.

Why do you say that?

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.

This is unfortunately not the case in reality.

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.

Glad to see Stripe release this, but the $5.00 fee cap doesn't seem competitive for frequent large transactions compared to other providers that have a flat fees from $0.25 like Dwolla, with more listed here http://www.merchantmaverick.com/need-know-accepting-ach-paym.... Why the higher cost?

Dwolla also charges monthly fees: https://www.dwolla.com/pricing. You need to pay $1,500 a month in order to charge more than 10 bank accounts.

In general, most providers have a lot of fine-print. We tried to come up the simplest and fairest pricing we could.

Not sure about this. Pricing reads "funding sources" with no reference to the number of bank accounts that you can charge. http://blog.dwolla.com/connect-multiple-funding-sources-dwol...

Still, it seems unusual to charge a percentage fee. From what I understand, one of the main benefits of ACH over credit cards is the flat fee structure.

Compared to credit cards, $5 is pretty flat isn't it?

TL;DR ACH is a commodity. The business model is derived by the platforms services offered, flexibility provided, and business targeted.

ACH is a heavily commoditized product. For ACH processors, then, your business model is tied to the functionality and capabilities offered by the platform. Dwolla, which has spent the last 4 years exclusively building out its ACH API, has a range of free and paid-for products and services. This allows us to offer a fixed flat-fee price point based on the additional value we bring to platforms (instant account verification, next-day processing, higher limits, holding balances, etc.).

Both services do an excellent job at baking in the expensive compliance, support, regulatory, etc. into their products.

There is no transaction fee for Dwolla whether or not you use the free product or the white label product. There is no limit to the number of bank accounts you can debit or credit via ACH with the white label api - https://www.dwolla.com/white-label

For the size of transaction that would typically motivate ACH, $5 seems like nothing. Dwolla has much higher friction. And this seems lower than the equivalent credit card charge.

Which is exactly why I just released http://paynote.io

From a consumer perspective, paying via ACH is much more dangerous compared to paying with a credit card. In case of fraud (e.g. hacked payment provider), recovering from ACH fraud is much harder than recovering from a credit card fraud. While you will likely get your money back at the end, it is also likely that you will spend many months talking to your bank (not to mention returned checks or other payments in the meantime).

Overall, I strongly recommend to NEVER pay via ACH from an account that is used for other purposes. Personally I have a special account at my bank just for rare ACH payments I need to make. I can transfer money instantly from my primary account when I need to make a payment. And of course this special account has all the overdraft protections, etc. disabled.

Making this system integrate with Plaid out of the box was a smart move. Plaid is so much better for users' than having to manually enter bank account and routing numbers.

Looks like the TOS acceptance button on this page is spitting out a 500 error https://stripe.com/docs/guides/ach

Sorry about that -- this only affects a small number of users, but we'll have it fixed momentarily.

This has now been fixed. Sorry again for the trouble!

Thanks! Just confirmed it's working.

> "And so, today, we’re delighted to launch support for ACH payments for all U.S. Stripe users."

Any ETAs for international? More particularly Canadaland?

Hopefully they'll get there. We're a UK based company with 90% of our revenue from US based enterprises, so moving to this would be awesome :)

I wish the pricing was more competitive. In the US, I've used Beanstream - which is $5/mo + $0.25 flat per transfer. In Canada I've used Versapay - $0/mo + $1 per transfer.

This is super important for b2b companies that need to accept payments of multiple thousands of dollars (e.g. Annual subscription / support), which largerish companies typically will not hand over a cc for, either due to CC limitations or (usually) internal process red tape.

I would say both yes, and no.

My experience in B2B is that medium to large companies will want to pay you via ACH. However they have little to no interest in entering their online banking ID and password into something like what Stripe is providing.

They already make ACH payments, using their own tools, and all they want from you is your routing and account number so they can do so. Assuming you are a US company, with a US bank account, you've already been able to accept ACH payments in this way for some time.

This setup from Stripe seems to be targeted at consumers, or maybe small business owners, as the purchaser. I'm sure that's a need, but probably not a huge one. Many of my customers that are medium/large businesses want to make ACH payments, almost none of the small businesses have an interest in that.

This is my experience too. When a customer wants to buy my product and the cost is over $5K, I give them the following and it shows up in my bank in about 3 days or so.

Bank Address, Swift Code, Account Number, Routing Number.

Wait, is there no minimum?

Because 0.8% on very small amounts is very practical for micro payments.

$1 payment would cost a fraction of a penny.

What am I missing?

This will be game changing if my observation is correct.

I'd wager the only thing you're missing is the high friction involved in setting up a bank account. I've got my credit card stored in my password manager vault, and even if not, I've got that sucker memorized. Contrast that with digging through the clutter on multiple horizontal surfaces in our house to find a checkbook so I can find the routing number and account number, waiting for the two deposits to show up (because I use a small bank that hardly ever shows up on these "automatically authenticate" lists), and then trying to remember what I was trying to spend $1 on...

But that's literally the only problem. The fee structure is AWESOME for micro-payments, so for the right things (small subscriptions?) this could be amazing.

But once you've set up your bank account once, it will work on every site that takes Stripe.

That's the big sell as a merchant -- chances are your user is already configured for payments. And the larger their network grows the more likely this is true.

I'm pretty sure this isn't true. If both Merchant A and Merchant B are using stripe, and I authorize my bank with Merchant A, that doesn't mean my bank is authorized with Merchant B.

Especially because in most cases, you can be totally transparent with the fact that you are using Stripe.

Non-USA person here, I am amazed that this is even allowed. Giving your username and password to a third party? Think about all the security problems, like creating a fake Stripe. You are basically trusting every website you use. In my opinion, there should be a free and open protocol between banks for payments. Where you get redirected after you clicked on the pay button.

Can this be used, or setup in a way that supports the standard invoicing model?

i.e. I want an api call to email a .pdf to a customer, and then have them "click this link and enter your info to pay via checking account". Several kinds of customers, including consulting, would be much happier with a "push" model of paying, than a "pull" model.

Our startup, Invoiced, does exactly this. You can easily send invoices through our API [1] that customers can pay from the email. Now that Stripe ACH payments have been released we will be supporting it in the near future.

[1] https://invoiced.com/docs/api/#send-an-invoice

Sure, Stripe just provides the underlying payment API, you can build your own tool (or use one of many pre-built ones) that sends your customer an invoice and providing them a method to pay you per invoice.

https://news.ycombinator.com/item?id=10889918 looks like another announcement about this. It was posted slightly later so we'll treat it as the duplicate in this case.

Eventually we'll have some form of URL grouping when there are multiple stories on a topic.

I am trying to build a lending platform where we by definition cannot afford to lose 3% on each transaction. I'm am thrilled to see this. We have had to hand jam our current system with a local credit union (where we literally have to print out forms and bring it to them), so being able to switch to a fully programmatic system is awesome.

Just got my beta invite too. Got frustrated at the lack of an easy ACH payments platform long ago though and went ahead and made my own. Launched http://paynote.io on January 1st of this year.

This looks very interesting. Tell me more! How are you offsetting the cost of fraud when payments by fraudsters will cost them nothing?

Well it's not for ecommerce for one thing. So fraud will be a lot less just in terms of use case here. This is individuals and companies are paying invoices for services rendered. There's not an area where a fraudster would gain a lot from a fraudulent payment. The ACH Payment system I'm using is also FDIC insured up to 250k.

Is this for real? I just started a consulting business and have been searching for a good, inexpensive way to receive relatively large payments on my invoices. How are you going to make money? Is this good up to $50K?

EDIT: I just tried to sign up, and this seems really scammy. You need a photo ID uploaded, along with my bank account details? How do I have any assurance you're not going to drain my bank account?

Interesting you find that scammy. It is for real though. I'm a consultant and it's been a real pain trying to collect large payments without getting killed on fees. The information is required by law by the patriot act for any bank transfers done over the internet. I can't get around it. It's required by law and by my ACH provider.

I hear you. I'm not saying it _is_ scammy, just saying my scam-radar pinged pretty loudly.

I'm all for ease-of use, but the flow went:

* Ah, a new service I could use!

* Sign up, cool, that was easy. Just needed my email.

* Verified my email with the 6 digit code, that's cool, sorta like Square.

* Sign in... Verify identity... OK, that makes sense. Hang on a tick, you want a copy of my ID? That's the first thing I'm asked for? Who's asking?

It's the who's asking bit that made me stop in my tracks.

I'm in the same boat and have eaten the high fees in order to get paid quickly when I was first starting out. It's a great service, if it's for real...

Also if it didn't get your bank account details? How would the system pay you? Haha

Stripe should start supporting the rest of the world. I'd love to use their services.

GoCardless is another ycombinator business providing a very similar platform for the whole of the UK & Europe. https://gocardless.com/

@pc - curious if you have plans to integrate ACH into your Checkout product. Seems like an incredibly difficult UX problem, but I'm sure your folks are up to the challenge :)

No immediate plans. ACH is mostly popular for B2B use-cases whereas Checkout is optimized for "lightweight" transactions. You can obviously imagine cases where an integration would be useful but we decided not to hold up the launch in order to build that. We'll calibrate based on feedback going forward.

@pc How do you feel about the assumed fraud risk you are taking on with this? I'd love to have a conversation with you about it (in private). You can email me at rwmurray (@) vt.edu. I know you all have quite a few vulnerabilities in your system and can't ever find a way to share them.

You should definitely email the fraud team! Try mlm@stripe.com. (Feel free to CC me; patrick@stripe.com.)

Did micropayments suddenly become possible for the first time? Would this be a great service to charge 1000 users $0.10 each? Or for that matter, for selling ebooks?

I think it would need to support payments in the opposite direction too -- deposits into someone's account. I'd love to see this!

Stripe Connect allows sending money to other peoples account

Other people's Stripe accounts yes, but not just arbitrary accounts.

With Managed Accounts you can create accounts for other people via the API that besides for a line in your terms of service they don't need to be aware of Stripe for.

Just an FYI to everyone accepting payments: Fighting chargebacks for ACH payments is a lot harder than just calling up a cardholder's bank. With Stripe now making ACH payments easier, I suspect the card shops " " will see a rise in routing/account numbers for sale.

And as always, just a friendly reminder Stripe's "fraud protection" is beyond trivial to get circumvent, so don't think they're doing you a favor.

From what I gather from the comments, you as customer have to log in into your bank's online banking portal to initiate the transfers.

Don't you US guys have an equivalent to SEPA direct debits where I just give the IBAN bank account number and the merchant will automatically deduct the money from my account?

If so, then no wonder why US people are so dependent on credit cards...

This is great.

Next up: I'd love to see true Debit card transactions (i.e. With Pin) at Debit prices (perhaps 10-30c regardless of transaction size). That could really enable a ton of smaller items to be sold to a very large audience.

So is it possible for simple ACH->ACH deposits? I'm looking to take out of my bank account and put into another (royalty payments for the curious). Ideally without having to hold a Stripe balance, just simple xfer.

You could take a look at combining ACH and Stripe Connect.

So with ACH I can directly bill my customers' account. ACH lets me to bill them for multiple or single payment. So, with these I can do person to person(p2p), business to business (b2b), and business to consumers(b2c)

That is cool.

Somewhat offtopic- is there a way to use Stripe to hold payment in escrow or to authorize a payment more than 7 days in advance? I really like Stripe, though I am not sure it can do what I need.

Using Stripe Connect and Managed Accounts you can hold funds for 30 days. Its not legally escrow though (escrow tends to have a specific legal definition and set of rules).

No, as answered by a Stripe employee.

https://www.quora.com/Does-Stripe-provide-an-escrow-facility...

Praise Jesus I've been waiting for this.

We've been using the beta for about 6 months and find it to be incredibly reliable. Thanks Stripe people.

Is there an ETA on availability in Canada?

Definitely working on international. You will be able to accept payments (not send) this week in the form of a paper check mailed to you. So when you claim, just check the box for mail me a paper check and you'll get one in the mail once the payment clears.

I wonder if this means Interac Online will come soon :O that's a very big deal for the Canadian market.

Hopefully. I've had to integrate with that in the past and it was not a fun project.

I faintly remember them passing back html to inject to the user that contained iframes and a bunch of other junk javascript.

So does the ACH do settlement rather than clearing as the name suggests?

Sooooo as someone who used to live in the UK, should GoCardless tremble ?

n00b alert: Can someone ELI5 differences between the solutions/products offered by Stripe and other payment related companies like Square, Braintree?

This opens up so much

Reply on news.ycombinator.com