Skip to content

Loading…

ACH Debit #2

Closed
matin opened this Issue · 145 comments
@matin
Balanced member

Balanced only allows for pulling money in from credit cards. ACH debits enable the following use cases:

  • merchant initiated refund to a buyer after the merchant has already received their money
  • debiting a merchant in the case of a chargeback by a buyer
  • large transactions that can't support the variable fee associated to credit card payments

UPDATE

ACH Debits are now supported, visit https://docs.balancedpayments.com/current/?language=bash#debiting-bank-accounts for more information

Email us at support@balancedpayments.com to get in the beta!

Pricing
image

@matin
Balanced member

See also #3

@whit537

+1

@whit537

Am I wrong in thinking that this would be something along the lines of 25¢ pay-in transactions? That would be huge. Credit card fees are painful.

@matin
Balanced member

@whit537 haven't finalized the pricing yet, but 25¢ to 50¢ sounds like the right ballpark

@matin
Balanced member

from @femgineer

What's the current pattern for refunds? As in, how quickly would a buyer request a refund? What is the volume of refunds being processed on e-commerce sites. I ask because everyone is talking about abuse and when is the appropriate time to issue a refund.

Can you clarify what you mean by "refund"? Are you talking about refunding a card transaction or a seller initiated refund, which would require debiting the seller's bank account.

When are you anticipating this going live?

In September. ACH debits is something we have to do, but we need to prioritize against other highly requested changes that are blocking some customers from going live altogether. The more people that comment here and comment on #3, the faster we can move.

@jjhurlock

+1 for Pessimistic. ACH debits are a requested priority and a September launch would be great. In my situation most buyers prefer to be debited via ACH because the large transactions can't fit on their card.

@jkwade

@whit537 Unlike @jjhurlock's use case, you'd want to debit a buyer's bank account for a relatively small amount (~$10):

  1. Is this purely to avoid the processing fees associated with credit cards?
  2. Are your buyer tolerant of a pessimistic ACH debit work flow?
@dsog

+1 I love where this is going :).

@femgineer

@matin So I get the concept of a large transaction not fitting on the card, but would a seller also have the option to use ACH in the event they do not want to pay the large fee associated with the large transaction? I'm guessing that is something that BizeeBee would to have to offer right?

@femgineer

@matin Also I meant a seller initiated refund, because those are the only types of refunds we would be dealing with on BizeeBee.

@whit537

@jkwade

Is this purely to avoid the processing fees associated with credit cards?

Yes.

Are your buyer tolerant of a pessimistic ACH debit work flow?

Dunno, need to think about that more. The pessimistic flow means ~four days before money is available to gift back out, right?

@matin
Balanced member

@femgineer you could use it at any time

@matin
Balanced member

Dunno, need to think about that more. The pessimistic flow means ~four days before money is available to gift back out, right?

@whit537 not certain. I contacted a few banks yesterday to see the level of service they could provide. Not all banks are equal. I'll post an update here when I have more info on getting the time down, which is a huge component of the experience.

@spenczar

Holy moly, this would be extremely valuable to us at ZeroCater - very excited to follow this.

@timnguyen

@whit357 and for people looking to ACH strictly to avoid processing fees.

Anecdotally, we've seen lots of people be fairly hesitant about having to provide bank info. Many actually prefer check even with the longer delay and greater inconvenience required to actually cash the check. Additionally there have been studies and speculation positing that credit cards make consumers more likely to spend.
http://www.psychologytoday.com/blog/ulterior-motives/201001/spending-and-credit-cards
http://www.npr.org/templates/story/story.php?storyId=92178034
http://spectrum.mit.edu/articles/normal/the-psychology-of-spending/

I'm not saying ACH in is bad and I agree that card fees suck, but the above evidence makes me skeptical that ACH payment would be a very good solution for low value transactions, whimsy purchases, or marketplaces with short-term customer-marketplace relationships.

@jjhurlock

@timnguyen Regarding ACH payments for large transactions that can't fit on a single card. Could a user who is hesitant to provide their banking info have the ability to pay simultaneously with two cards? I know Apple.com allows this feature at checkout.

@spenczar

@jjhurlock I don't know about @timnguyen, but in my experience at least, payers don't always have two cards. The usual answer is to split the transaction into several charges over several days. ACH debit would be welcome to replace that awkward practice.

@timnguyen

@spenczar I absolutely agree that ACH debits is hands down the better solution for large transactions. That's where both card limits and card fees become very very significant issues. All I'm saying is that for low value general e-commerce transactions ACH for payment is lacking/needs lots of work. I forgot to mention earlier though, I think the major use case for splitting across cards is with prepaid/giftcards.

@jjhurlock Currently marketplaces can already create multiple debits with different payments instruments for the same user through balanced. The caveat is that I'm not sure what is the best way to arrange the UX for the form on the marketplace's end.

@KRecht

We vote for both ACH for customer transactions and for merchant refunds @venuebook.

@matin
Balanced member

@spenczar @khussein @KRecht @jjhurlock @whit537

What do you expect the average size of ACH debits for you to be?

You can send this number to me directly: support@balancedpayments.com

@franklangston

Big upvote here! Crucial for handling refunds and chargebacks because merchants want their money quickly, but that means they have to get it back in for those scenarios. Receiving buyer money via ACH is also a positive.

@rmanisha

What would be the limit on ACH Debits?

@matin
Balanced member

@rmanisha there won't be one in the API, but the customer's bank may impose one for that particular customer.

@matin
Balanced member
@charliepinto

I'm pretty late to this conversion. I apologize if my below questions are already answered:

ACH Credits: Do you expect to impose a limit on the number of transactions per day? Is there a limit on any particular transaction size? Do you expect to impose reserves?

ACH Credit Batching: How often and when can we batch transactions to our merchants? Will you follow strict times when you initiate instructions?

ACH Return Error/Corrections: How will you handle errors and corrections? Will you provide a smart error and return responses (e.g., frozen account, account closed, insufficient funds, invalid account number, invalid routing number). In our experience, the error responses are very helpful for risk management. Also, if a credit fails, will you automatically retry during the next ACH cycle? Some users input incorrect bank information (invalid account/routing number) and we would like to know so we can tell the user why they credit failed.

@matin
Balanced member

@charliepinto not late at all.

ACH Credits

Do you expect to impose a limit on the number of transactions per day?

No.

Is there a limit on any particular transaction size?

No.

Do you expect to impose reserves?

Can you clarify? Do you mean support a credit reversal?

ACH Credit Batching

How often and when can we batch transactions to our merchants?

You hit the API per request. The API make sure to batch the items before the cutoff times to get the funds out as quickly as possible. This saves you from having to worry about breaking up the requests or pay a fee per batch.

Will you follow strict times when you initiate instructions?

Our current (internal) cut-off is 4:30pm PT for next business day. In reality, the cut-off for the API is earlier since the requests have to get batched and pushed out. I created #81 to answer this question in more detail.

ACH Return Error/Corrections

How will you handle errors and corrections?

It would fall under rejected. There's only three states defined right now: pending, cleared, and rejected.

Will you provide a smart error and return responses (e.g., frozen account, account closed, insufficient funds, invalid account number, invalid routing number). In our experience, the error responses are very helpful for risk management. Some users input incorrect bank information (invalid account/routing number) and we would like to know so we can tell the user why they credit failed.

  • Incorrect routing numbers can be determined during the request. I already added it to the list of request errors in #80
  • I added #82 to define how rejection reasons should be returned

Also, if a credit fails, will you automatically retry during the next ACH cycle?

What would you like to see? The current spec tells you the credit was rejected and let's you try again.

@matin
Balanced member

Your ACH product will work with our bank, correct?

Yes. Here's an example:
1. debit your bank account $10k
2. use the funds to issue ten $1000 credits to different people

@matin matin referenced this issue
Closed

Payouts via check #69

@matin
Balanced member

Begun work on implementing the spec: https://github.com/balanced/balanced-api/tree/ach

@benblair

+1 will definitely use once production-ready

@matin
Balanced member

I apologize for the delay, but releasing the client libraries and taking the ACH API live has been pushed back by two weeks.

In the meantime, the ACH API is available for tests. We'd love feedback on the interface.

@rrhyne

Nearly any b2b marketplace would require ACH payments from buyers. This is an area Balanced could get a big win over Stripe, BrainTree and the like.

@matin
Balanced member

I want to give an update on why there's been such a long delay. We evaluated the potential and the costs of ACH debits and decided to revisit later.

Here's a quick explanation as to why, for the sake of transparency:

revenue = number of marketplaces x total volume ÷ average transaction size x transaction fee

The cost consists of the requirements to meet compliance and the fraud risk. ACH has a dispute process similar to card transactions. Debits from business accounts have a dispute window of two business days, but debits from a personal bank account have a dispute window of 60 days.

There's no surprises about any of the information above. What changed was that the average transaction size ended up being higher than expected (by nearly an order of magnitude) and the risk is estimated to be higher than originally expected. At the moment, it doesn't make good business sense for us to move forward with ACH debits, which really sucks.

We took all the work in designing an easy to use ACH API, and we're merging it directly into our production API for ACH credits. This means that a marketplace will be able to use us purely for paying vendors. The following will be the required fields, which you'll notice is different than the process to pay a merchant when processing a card transaction.

  • amount of the credit
  • account holder's name
  • account number
  • routing number
  • account type

The next step will be to provide marketplaces the ability to reverse a credit directly through the dashboard—something that currently requires contacting us.

@rrhyne

Thanks for the update @matin.

@taylorbrooks

No ACH debits is a deal killer for me. Needed it really badly. Back to square one.

@matin
Balanced member

@taylorbrooks I'm sorry to hear that. I'll keep this issue updating based on progress

@taylorbrooks

@matin What's the best email for you? matin at balancedpayments I presume?

@matin
Balanced member

@taylorbrooks That works. I also read emails to support@balancedpayments.com, which helps us track your request.

@loudin

Definitely understand the risks involved, but I'd like to +1 this feature. We'd love to have it.

@matin
Balanced member

We definitely want people to continue commenting and voting on this issue. At some point, there will be enough demand for us to justify the cost of supporting ACH debits.

@loudin
@taylorbrooks

Good idea. @matin what information are you looking for to gauge demand? Do you have a threshold of some sort you need to hit?

@alexsmr

We have the use case for ACH transactions only between businesses. If you can at least provide with B2B ACH debit/credit solution, you'd, probably, have us on board.

@nthj

There's no surprises about any of the information above. What changed was that the average transaction size ended up being higher than expected (by nearly an order of magnitude) and the risk is estimated to be higher than originally expected.

Would scoping ACH to transaction amounts < $THRESHOLD for a first release be a possibility? You mentioned transaction size affecting the decision: even if I had to build in UI logic to only accept ACH for certain transaction amounts, it'd be so worth it.

+1, either way. Thanks!

@doddcaldwell

I'm new here but would like to say that being able to provide ACH debit transactions would be huge my company MoonClerk. We're currently missing out on the b2b market and we could definitely use this.

@jwigal

Would love to see ACH debit transactions. I have a use case where we have an organization paying out to multiple vendors. This would be huge.

@matin
Balanced member

I made a previous comment about how it was difficult to make the business case for Balanced to offer ACH debits right now. We received a lot of feedback that the price needs to be fixed ($1 without any variable fee), but that was part of the trouble. The risk scales with the size of the transaction, which threw off the economics.

I've had a few people email me about changing the pricing structure to something on the lines of 1% + 30¢. That definitely changes things for us. We can also make improvements in the future as we build the systems to reduce risk, but it would let us move forward faster on ACH debits.

Please let me know if you would still be interested a pricing structure like 1% + 30¢ would work for you?

@doddcaldwell
@jjhurlock

+1 I'm interested in this pricing.

@loudin

Definitely. I'd be able to work with this pricing.

Edit: Would like to also reiterate the sentiment that moving away from variable pricing after activating it would be difficult. I am most attracted to it so we can move away from percentage-based pricing. However, I'd be glad to work with a 1% + 30c fee structure to get things rolling.

@taylorbrooks

+1 Agree with Dodd. It isn't perfect, but I'd support this if it gets things rolling.

I'm worried about setting precedent with variable pricing on ACH debits. If there's a path to fixed prices (for ACH) once the marketplace proves to be low risk.

@gbelote

+1. Wefunder is very interested in ACH debits and variable pricing sounds totally reasonable.

@nthj

+1 works for now, thank you for revisiting.

@juanbermudez

+1 That pricing works perfect guys. Thanks for revisiting. I was also thinking of throttling the transactions (size) to reduce cost/risk.

Really looking forward to this.

@whather

+1

@georgedyjr

+1 Definitely in favor of ACH debiting. I'd expect the cost to be something like $.25/$.50? Typically, users expect a zero fee related to ACH from bank accounts - no? I'd use Venmo as an example for this functionality, giving the user the ability to attach a bank account and avoid the CC fees.

On another note, once this feature is available, would Balanced give my company the ability to attach to a user's bank account, allow them to verify a $1000 transfer, in which case we can hold the money and pay back dividends in smaller amounts via ACH back to their bank account?

@anusheel

+1 eagerly awaiting...

@jkwade

hey @georgedyjr, yes banks can offer this functionality for around 25¢-50¢, but they manage their risk by putting applicants through rigorous vetting process, similar to traditional bank underwriting. Venmo has a $2000/day limit on transactions to control their risk.

To manage our risk, @matin is proposing a percentage based fee. Would that work for you?

Also, yes, the use case you describe would work with Balanced.

@tehgeekmeister

+1

Wish the percentage fee weren't necessary, but it'll work for us.

@thakronick

+1 I also dislike the percentage fee simply for large transactions, but would be willing to pay more than $1. Maybe have 2 options ex. $0-$400 is 1%+$0.XX and for $400+ is a flat rate.

If you implement this feature I'd imagine you would have a large portion of the market. Hope to see it soon!

@bb-cyrus

This pricing 1% is fine!!! TEEHEE, please~!!!

@thekeith

I was referred to this issue by jareau @ HN

Our company is processing ever larger CC payments and also takes checks. ACH debits (getting payed by a customer) would be immensely easier than wires (no fees and much faster than a check).

I'd be happy to pay a moderate fee, non-percentage, for each transaction due to the simplicity. Clients are generally fine with inputting information from their bank to make it work. Would love to provide any needed input and test the platform :)

@edh72

+1 on allowing ACH payments in

@zealoushacker

:+1: @jkwade I'd be up for a flat percentage structure just to get ACH debits off the ground in the first place.

Next, I positiviely love @thakronick's idea of a mixed fee structure, where some portion of your target market, which has a certain transaction size only gets charged a flat fee, whereas the target market which has a higher risk profile would be charged on a percentage basis. Two fee classes basically...

And, in the next iteration, you might build some learning algorithms that adjust rates according to history: after a marketplace/merchant establishes some form of history, perhaps having an algorithm to help lower the fee.

@MikeFair

I'd also prefer not to have any percentage on the ACH transaction fee itself.

It sounds like the real driver for the percentage fee is associated to risk (aka needing to carry some percentage of the rolling avg txn size to cover potential refunds, transfer failures, and the like).

So how about on txns that BP defines as "risky" there will be an additional txn insurance premium of 1% of the txn amount (this is different than a 1% processing fee in that it has to do with the risk associated to the txn completing).

This would then imply that there are steps the marketplace, the merchants, and the customers can take to make these transactions safer and reduce/eliminate the premium.

I see a few general categories that BP could require:
1) Have the process heavier on the customer side to reduce/eliminate fraud

  • More onerous identity verfication steps (Know the Customer Better than usual)
  • Bank info has been successfully verified (failure won't be typos)
  • Get privilege of doing account balance checking before submitting the txn
  • Have a delay between initial sign-up and making a transaction (brand new accounts are riskier)
  • Have an additional two-stage txn confirmation step (like click a link in an email they get, or hit an "authorize" button for pending txns on their account)

2) Have the merchant/transaction meet conditions to reduce the risk

  • Have the merchant wait longer to receive the money (like 10 days, or worst case, the full 60 days)
  • Other activities that reduce the likelihood of txn failure.

3) Have the Marketplace/Merchant take on funding the risks rather than BP

  • Have the marketplace/merchant keep some money "in reserve" (based on avg txn sizes) to cover refunds
  • The marketplace may elect to pay the txn insurance fee in lieu of keeping "reserve funds" in their escrow account.

e.g. a marketplace's escrow account must maintain a certain balance (say 8.5% of the 60 day rolling average of their daily ACH txn amounts) in "reserve funds". When the "reserve funds" are "underfunded" the 1% of the txn amount is used to transfer money into the "reserve funds" pool until the reserve amount is reached.

The "Reserve Funds" are used to process any refunds or failure charges and then begin to fill back up again at the 1% of the txn rate. If they don't participate in ACH then their 60 day rolling average will be 0 and need no reserve.

The percentage of "Reserve Funds" required doesn't have to be uniform to each marketplace or merchant. While the formula used should be transparent, it could be adjusted according to the risk profile of the marketplace/merchant.

@juanbermudez

I wanted to add that beyond being OK with a 1% fee this is just essential if you want to create a marketplace where a merchant can refund a buyer directly without having to charge his card.

In our case we need to enable merchants that voluntarily want to refund their buyer with minimal friction and cost.

@thakronick
@matin
Balanced member

@juanbermudez @thakronick reversing an ACH payment/credit is completely different for us. It's much lower risk, and as you mentioned, much more necessary for us to provide. Take a look at #163

Not sure what the price would be, but it would be fixed and low.

@franklangston
@LouisLang

So where does this currently stand? I'm looking at using Balanced for my payments, however I don't believe the buyers will be willing to incur a 2.9% on credit card fees for my marketplace. I would much prefer to use ACH.

@thakronick

@matin Any updates on ACH debit capabilities? Would like to work with you guys before I start building with another solution.

@lay2000lbs

+1 on adding this. It would be a huge feature for us. Agreed that a mixed fee structure is where it's at for us.

@podsports

The trade-off between ACH vs CC is much bigger for larger transactions, so I think you have to assume that people coming to Balanced are (like me) dealing with large, regular, repeated transactions (avg $170 once a week) and trying to get around a 3% fee. 1% is certainly better, but not as disruptive if I could say to my clients, forget credit cards, I will charge you $1 for any payment (say 0.50 to process the ACH in $0.25 to process it out, $0.25 for me. But, certainly I get the risk factor. Would be better if we (marketplacers) could help you absorb that risk (bond, minimum escrow limits), that kind of thing. Different types of businesses are inherently lower risk. There are models that this would fit really well, like if clients who are typically a long series of regular payments getting treated differently than someone who does one-off transactions all the time.

But as for ACH as a payment option, by all means do it now. Like right now. Start at 2.9% and lower the fee later. The only reason I'm still looking around at merchant accounts instead of coding...

@thakronick

:+1: @podsports well said. I would actually expect us to take on some risk as the marketplace. Would much rather manage do this myself than have higher fees for my clients. There are plenty of online businesses/services that offer ACH debits for less than $1...it can be done :)

@MattRogish

:+1: we would love ACH debit. We have folks who want to pay large amounts either one time or over time and the 3% is a bummer.

@endogeneity

+1 for ACH debit. What I'm looking for is something like Intuit PaymentNetwork, though I don't want buyer or seller going out of my service and registering on Balanced's (or Intuit's) site, because there's then no point for me being there and I have no record of the payment. Intuit charges just $0.50 for the credit and debit combined.

@justintoth

+1 for ACH debit, I'm looking for a service like Dwolla (they charge 25 cents for ACH transfers over $10, free for under $10), except with a useful UX. Dwolla's REST API doesn't allow you to fully register, add accounts, verify accounts, transfer money, you have to send your users to dwolla.com to input certain information to verify their accounts, which is a joke in terms of UX.

@jkwade

@justintoth how much would you be willing to pay for a fully white-label ACH API?

@thekeith

@jkwade I would be quite interested in this as well. We're processing ACH payments from customers (some will soon be in the 5-6 figure range) so credit cards are right out, wires suck beyond belief and checks take forever to clear.

@justintoth

Average monthly rent payment might be $1,000, so any sort of percentage would probably be too steep, even 1% is $10, and most landlords or tenants wouldn't be willing to pay that to transfer money. If you could make it competitive with Dwolla (25 cents) and Intuit (50 cents), maybe a dollar or less, than it could get a lot of use.

@endogeneity

@jkwade I know you didn't ask me, but any percentage for my business (as an intermediary between people paying $1K or more - my service hasn't launched so I can't cite data) might be not too attractive in the eyes of my customers. I am willing myself to pay a yearly fee, which would be out-of-pocket for me right now and for which I'd gladly pay $400, to have a white label ACH service. Perhaps rather than limit per-account transactions, you could create a pay schedule for businesses based on the number of total transactions for each business.

@podsports

@endogeneity A monthly or annual fee that would change the percentage fee to a fixed price of say $0.25 - $0.50 is a great idea. Charging a percentage of volume really slows adoption for higher avg transactions because it "feels" like so much more money. I can charge 3% on a $10 transaction all day because "hey, its only $0.30", but if I try to charge 3% on a $1K transaction, "hey! no way I'm paying $30 instead of just taking a paper check!". Even if the aggregate volumes are equal...

Which to me is backwards in some cases. Facilitating a regular monthly $1K rent payment has got to be way lower risk than 100 one-time $10 transactions, but a percentage fee means they both cost the same.

The first company to price based on the nature of the transaction\marketplace instead of the dollar volume is going to change the world for rental payments, vendor payments, any large cash transfer that today is done by check...

@quellhorst

Regarding the fees for ACH debits. In the use cases I run into 1% + $.30 could work unless it is higher dollar amounts i.e. > $500. Maybe you could do some type of cap or tier for the charge?

I'd like to mention https://www.dwolla.com/fees ... They charge $0 for payments under $10 and $.25 to receive > $10.

@kieftrav

Just read through all the comments. I agree with the general narrative...

1) Would be willing to do a small percentage fee if necessary to get it off the ground. VERY resistant, but willing for the time being. The accpetance is a sign of "good faith" with the goal of getting to a flat fee once you know the risks / costs associated with that risk.
2) Dwolla charges $.25... So keeping competitive is ideal.
3) Other methods of reducing risk (tiered pricing based on size of transaction, reserve on hand, cap in daily volume, etc). Basically wanting to explore any ideas other than a % fee.

Overall, I would really appreciate an analysis from the Balanced team about why other methods of reducing risk wouldn't work.

@mahmoudimus

You asked for it and we listened. We're very excited to show you a preview of what we've been working on. With #263, ACH debits has now been deployed in production and we're getting ready to polish our documentation and we need YOUR feedback!

Alongside #70 and #254, you can now subscribe to events that will notify you of failed debits etc. Every test marketplace has ACH debits supported, however, you must contact us to enable it for your production marketplace.

Both the python and ruby clients have examples (ruby, python) that demonstrate how to do this.

As far as we can tell, this is the first offering of its kind that offers a completely white-labeled and no signups required solution for asking your customers to pay with their bank account. It is completely seamless.

Go ahead, give it a whirl. You're all invited to preview this API for your test marketplace! We'll be announcing private beta invites next week, which @jkwade will follow up on.

Thanks for your patience!

/team @balanced

@thakronick

You guys are the shit! This is going to be huge.

@jkwade

Some additional details:

  • Pricing: 1% + 30¢ for now. @kieftrav we can't guarantee a flat fee in the future. Our intention is to come to a fair price that will give our community something that doesn't exist elsewhere while covering our costs and risks. There's too much uncertainty to guarantee anything right now, but I hope you can trust we'll be fair.
  • Invitation only: Next week, we'll begin inviting members of our community begin using this functionality
  • Naming: This thread is called "ACH Debits" but I think we need a snappier name. Right now we're thinking "Bank Payments" will work. Thoughts?
  • We'll be releasing docs on some micro-deposit verification helpers soon. Stay tuned.
@doddcaldwell

So, in saying "we can't guarantee a flat fee in the future. Our intention is to come to a fair price..." does this mean that you'll be working towards a lower rate in the future but you're just not sure yet? By flat rate do you mean you're goal is to have Dwolla-esque pricing?

@jkwade

@doddcaldwell: Exactly, we can't guarantee that our pricing will change to a flat fee. We're certainly not opposed to it, but we can't promise that yet. A flat fee pricing structure would be 30¢ per Bank Payment, for example.

@jkwade

What does everyone think about naming this product "Balanced Bank Payments?"

@doddcaldwell
@doddcaldwell
@thekeith
@podsports

Just out of curiosity, where do the funds for the bank account verification process originate? Are they Balanced funds that get withdrawn later, or do we front it as marketplaces?

@lay2000lbs

Super excited, great work guys! we've been waiting for this!!

I will say "balanced bank payments" is a little long. Not sure of a better alternative though.

@gbelote

What about "Balanced ACH"?

@quellhorst

I also like "Balanced Transfers" more.

@taylorbrooks

What do I need to do to get ACH debits in Simple Donation production?

@podsports

What about calling them "eChecks" or "Electronic Checks"? I've heard that terminology before referring to ACH payments. Paysimple calls them that. www.paysimple.com/echeck.

Could also make up a name, FastWire, or BACH (Balanced ACH), PayWithBank vs PayWithCard. "Balanced Direct", just riffing...

@remear

I prefer Balanced Bank Payments. Thanks for your work on this feature.

@justintoth
@Cyberkruz

I am excited about the turn around as well. I agree with justintoth that the price is unfortunately not viable for payments that are large (ours average 1000 dollars). Our current Ach provider does 20 cents a transaction which I would instantly pay double to be able to use your amazing api. The percentage point kills large payments for us though.

@thekeith
@quellhorst

Yes, I would love to be able to charge customers via ACH for consulting work. Problem is the vast majority of these transactions are all well over $1,000.

@JeremyPlease

+1 for fixed fee ACH debits!

@jkwade

ACH Debits are live

We've officially announced (TC, TNW) that we'll be supporting ACH debits. Here's our blog post with a bit more detail. On behalf of the Balanced team, I'd like to thank you all for being so vocal and active on this thread, encouraging us to launch this product. We're pretty excited to see where this goes.

Cost/Fees

The price, for the foreseeable future, will be 1% + 30¢. I know this isn't ideal for many of you, but this is the price point we determined we needed to cover our costs/risk. We hope to drive the price down soon, but we didn't want to delay the launch any further for those of you who were interested in using this functionality despite the 1% fee.

Bank account verifications

One new thing about this implementation of the ACH API is that Balanced requires bank account ownership to be verified via micro-deposit before it can be debited. This will add at least one day of latency to a checkout experience. We've added some micro-deposit verifications helers to our API. Check out the docs.

A quick walk-through

  1. Create a bank account
    1.1. You'll want to use balanced.js for this

  2. Bank account verification

  3. Add bank account to an account

  4. Debit an account

  5. Use callbacks so you know if the debit was successful

Requesting access

Access to Bank Payments is invite only right now. We'll be rolling out a limited number of beta invites starting today. Please email support at balancedpayments.com to request access.

@skylar

+1

@matin
Balanced member

As an update, ACH debits is still in private beta. We're still working with our bank partners to be about to control how the transaction appears on the bank statement. All ACH debit transactions currently show up "BALANCED PAYOUTS". We've found a workaround for a couple customers, which is still in progress, but the workaround does not scale.

We will keep everyone updated as me make progress

@bbry

While I am excited that you are making progress on getting ACH debits working. I look at the whole point of doing ACH debits as a quick and efficient way of accepting large payments quickly and easily. The key word being large payments. So when you are accepting large payments in the multiple K even paying one percent fee still makes a big difference. So I am looking forward to the time when balanced is more competitive to current ACH providers where they only charge $.20 per a debit or credit.

@jrus

For discussion of potentially doing ACH debits without bank account verifications, see #281

@todgru

+1

@Bula

As you mentioned, you pivoted away from an ACH Debit solution and focusing on primarily International Transactions. Please post an update if you pivot back to an integrated ACH Debit solution.

@lay2000lbs

This has been put on hold? @Bula was there an official statement about it?

ACH debiting is definitely the number 1 feature we have been excited about and why we choose Balanced in the first place.

@Bula

@lay2000lbs Its our #1 feature too. no official statement but better call BP directly as we did. We really hope they solve ACH Debit but they mentioned that their focus has shifted primarily to International Trx (currency spreads). We would have certainly used BP for everything but this has caused us to step back. ACH debit is critical. again, love their original scope, hope they come back. Hopefully @matin can clarify.

@matin
Balanced member

@lay2000lbs @Bula you can do ACH debits today. Shoot us an email at support@balancedpayments.com, and we'll enable it for you. The main thing for ACH debits we're focusing on is letting you define how the transaction shows up on the bank statement. It currently shows up as "BALANCED".

@jtoth55

You can do ACH debits, yes, however they're not viable with the current pricing.

@matin
Balanced member

@jtoth55 it's currently 1% + 30¢. Does it become more viable for you if there's a $20 cap on that fee?

@jtoth55

Unfortunately no, my scenario is tenants making rent payments to landlords. An average rent payment is ~$1,000, so we're talking a $10.30 fee per rent payment.

Dwolla offers 25 cent ach transfers (albeit with a much poorer UX). Balanced's white label api makes for a much better UX, so I would use it in a heartbeat if it was competitive in price, even if the fee was 2-4x as much (50 cents - $1).

Many bank accounts offer external transfers for free (Chase QuickPay) or for a small fee ($3 for Bank of America), so no one will use my site's rent payment services with such a large fee.

@lay2000lbs

@matin the cap was something I have been hoping you would introduce. A $20 cap is high to me but a $5 would be very reasonable and I would even pay at a $10 cap, under the assumption that the goal would be to take that fee down. We are dealing in donation processing.

@gbelote

@matin a cap would be a very welcome addition for us since we've had a few $25k debits and currently run larger payments outside of BP due to cost.

@benblair

@matin FWIW, a $20 cap on ACH debit would definitely get us to switch our transactions to balanced. We're mostly in the $20-50k range per transaction.

@mahmoudimus

again, just to re-iterate what @Matin said, email support@balancedpayments.com get in the beta for ACH debits.

@bbry

I have done a great deal of research into companies who only provide ACH transactions via their own API's. I have to reinstate that charging 1% is crazy high. On average I was quoted $00.25 that is twenty five cents total, not $00.30 + 1%, just $00.25. $00.25 is the top price and it was lowered with increased usage. Balanced might have a good API but it is not worth using it when comparing the costs involved to other companies offering the same services.

@erikcw

I agree. 1% is very high based on my research.

I understand that you guys have to eat, but it just doesn't seem competitive. I've been getting quotes for $0.25 per transaction. Of course, if the business doesn't do any significant volume, then the nice Balanced APIs/speed of integration might make it a worthwhile tradeoff. But your clients are just going to migrate to other solutions as their processing volume climbs. Balanced's competitors' APIs aren't that obtuse!

@whather
@bbry

There is never a reason to leave money on the table. A $500 ACH transaction equals a $5 transaction fee. So for example say you have 5,000 customers paying $500 or more(since there is a $5 cap), that would be a balanced payments fee of $25,000 fee VS a fee of $1,250 with other ACH processors who charge only .25 a quarter per transaction. That is a huge difference of over $23,750 you would loose.

@jkwade

@whather @erikcw

Please note we've updated our pricing. ACH Debits now cost 1% + 30¢ with a $5 cap.
image

@bbry

Yaha @jkwade I know it is still a rip off compared to other ACH providers as you will see in my example above.

@matin
Balanced member

@bbry The original goal was to provide something that is price competitive by starting at $1 per transaction. We realized that the business case didn't make sense in compared to other priorities like international, foreign currency support, etc. More info in my previous comment: #2 (comment)

We revisited offering ACH debits when several customers requested that we reconsider if they were willing to pay more. After enough customers encouraged us, we moved forward. We've had the goal to continually reduce the pricing. Adding a $5 cap was the first step. The plan is to reduce the cap in increments as it makes sense.

@lay2000lbs

I just want to jump in to state that I and my business are very happy with the ACH pricing schedule. There is an obvious selection bias to only get negative comments on a post like this so I want to say thanks for making this happen and this is a huge value add for us.

For us, we're not trying to build the cheapest product, we're building the best product and often times that means you need to pay a higher monetary costs to build a system that has other major advantages. If we were looking for cheap we would have opened our own merchant account and been processing our own payments. Likewise with ACH, they are plenty of cheap providers.

A lot of this boils down to your business model and market. If you're using ACH for traditional use cases and going against existing providers your are already in a losing margins battle. But if you are using ACH in a novel manner than the $5 fee may actually be incredibly competitive.

@bbry

That is very encouraging to hear that you are working on lowering your pricing further. Keep up the good work.

@satiani

Can you please update the documentation on balancedpayments.com?

https://docs.balancedpayments.com/current/api.html#debits says:

Currently, Balanced supports only card transactions (info on ACH debits) for debits. To debit an account, i.e. charge a card, you must create a new debit resource.

The "info on ACH debits" links to this github issue. Furthermore, this link https://docs.balancedpayments.com/current/api.html#bank-account-verifications says:

NOTE You'll only need to verify a bank account if you're planning to later debit that account, which is a functionality only available through our ACH Debits private beta. Email support@balancedpayments.com to request access.

As I understand things, ACH debits is out of beta.

@matin
Balanced member

@satiani thanks for the catch.

ping @cieplak @remear ^^^

@remear remear referenced this issue in balanced/balanced-docs
Merged

ACH debits are no longer in beta #236

@remear

Thanks, @satiani. This should now be fixed.

@jondkinney

Came here from https://www.balancedpayments.com/help#q127 seems like that q&a needs to be updated?

@whit537

Why is this ticket still open? Balanced has offered ACH debits for months now, right?

@steveklabnik
@bbry

I am still waiting for ACH debits to cost as much as other ACH processors at apx $.20 a debit or credit.

@jtoth55

Same here, my site is for landlords accepting rent payments from tenants, however rent payments are always going to hit the $5 fee limit, which isn't competitive with other services the tenant could use for sending the rent.

I love the Balanced API so I'm OK with the fees being a bit higher than other services like Dwolla (which has a terrible UX), but $5 is way too much. We're talking ACH here, not credit cards, so we would expect cents rather than dollars for the fee. Then I can add a little more to the fee for myself and have a viable business model for my site!

@bbry

@jtoth55 curious what the url to your landlord site it

also I agree @jtoth55 if dwolla can charge $.25 per a transaction then there is no reason that balanced can not follow, because no landlord is going to pay $5 when they currently pay zero when cashing a check. Or any other business that deals in high dollar amounts.

@robertdoneill

@bbry just curious who you've found that charges $0.20 per ACH transaction.

@bbry

@robertdoneill some ACH processors in no particular order are
forte.net
achworks.com
checkgateway.com
While some of them do have a monthly fee(apx $20), that is a lot creeper then paying $5 for every transaction if you are doing high ticket transactions like collecting rent.

@robertdoneill

@bbry thanks for the help! I totally agree. Especially since (in my case where there are just b2b transactions) the "risk" they are pricing for doesn't even apply.

Its really a shame, the service is really great otherwise.

@steveklabnik

We support ACH debits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.