Hacker News Reader

Comment by troyk | Hacker News Reader

This is cool, but the money has to be charged via credit card first right? It would be nice to transfer money from the bank account linked to stripe to another account, and as a user of Stripe's connect API, it would be nice to enable this in our apps for our users.

Even cooler would be full blown ACH. We are working with ACH providers now and what a stark contrast to the beauty of stripe. All require some form of monthly fee, paper set-up forms with 1-2 week delays (vetting periods) and API's from the 90's

View on HN

You could checkout Balanced Payments (https://balancedpayments.com/) - a YC company that does ACH.

Last time I checked they didn't do ACH, and were doing basically what stripe released today.

I originally thought the same too, but found that it is in Beta. http://blog.balancedpayments.com/balanced-payment-method-pay...

The Balanced Payouts service has been available for some time. Our ACH Debit (pay with bank account) is in Beta however.

Taking over this thread talking about your service is pretty awful - surely you can announce your features in your own right rather than riding on the back of Stripe's name?

I completely agree. I apologize if it came off that way.

We launched payouts in February: http://techcrunch.com/2013/02/14/balanced-payments-ach-api-o...

For another opinion, I'm a Stripe customer, and I really appreciate Balanced talking about their product in this thread. They're not trashing Stripe, they're just talking about the differences between the products.

It seems cordial and I would rather read about the two products together than in some later thread I'll probably miss.

It looks like he was just adding some clarity to a discussion a few users were having. He didn't post any links, or 'announce' anything.

This is an open forum and the comments about Balanced are entirely on topic.

whoa...1% + $.30 for bank payments??? why would you need a percentage on an ACH transfer when most others charge a flat rate?

We're still trying to figure out the right pricing and are discussing it openly (https://github.com/balanced/balanced-api/issues/2#issuecomme...).

The risk scales with the size of the transaction. Granted, the risk does not scale at the same rate as the transaction size, but we wanted to keep it simple in the beginning.

What do you think about 1% + 30¢ with a cap?

Our customers are doing millions with ACH, most pricing of quality ACH providers is 0% + 25-40 cents and a $20/month service fee. So if the 1% was capped at $20, I could bring over a lot of business from low-risk non-profits.

What's the risk factor with large transactions ? Is it that they can be reversed or challenged ? I am not too familiar with the ACH system, but isn't it the case that once a transaction clears and a transfer completes, then that's it - there is no reversal process.

The money is a bank account is real money after all, and once it's spent, it's gone for good. This is one reason I (and I suspect a few others) feel very uneasy connecting bank account(s) with a third party web service.

ACH has a dispute system like credits cards. Credit cards have a dispute window of 120 days. Personal bank accounts have a dispute window of 60 days. Business bank accounts have a dispute window of 3 business days.

The problem with disputes on ACH debits is that the process is not formalized through a standard network like Visa or MasterCard. It's a mess operationally, and there's a near zero chance of winning the dispute. This becomes even worse because of the size of ACH transactions.

We've reduced the risk by requiring trial deposits on any bank account that you want to debit, which is also a problem for a lot of our customers.

> It's a mess operationally, and there's a near zero chance of winning the dispute

To be clear, does this refers to the business accounts / users ? The consumers with personal accounts who dispute the charges have their way and the charging entity is left to deal with the results?

I'm not sure about the percentage with or without cap. Most of the transactions for the service that we're building will be in the $500-700 range. With us taking a flat percentage, the merchant taking their percentage, and then payouts to clients. As you can see, there are a lot of levels of processing and selling the merchants on a percentage is difficult enough and then charging them a percentage again on a payout will be seen as nickel and diming them.

(I work at Stripe.)

Right. Those are both things that are on our product roadmap. (:

Free hugs and kisses from me when you guys roll it out (really gets my cofounder motivated, so thought I'd try it here!)

On an only moderately related note... here are two more things that I would love to see on the roadmap:

1) Better support for disputes in the API (right now to get all our disputes, we have to pull _all_ charges and walk them...)

2) The ability to generate test disputes. You guys provide an awesome test API, but there's no way to generate disputed charges in testing, so I can't test any of that functionality...

1) You should be able to pass in "disputed=true" to the charge listing call: GET https://api.stripe.com/v1/charges?disputed=true

2) Definitely. We'll keep that in mind!

Ah, the folks in your IRC channel (and your docs) didn't know that one... Awesome, thank you!

I too would love to be able to accept ACH payments. Our customer base is currently organizations that are happy to pay via ACH, but CC is not usually good option. (B2B)

I think Dwolla offers what you want, don't they?

Reply on news.ycombinator.com