Archive | October, 2012

API-Based ACH Payment Vendors for Web Developers

26 Oct

While there has been tremendous progress in the world of plug-and-play online credit card payments providers for web developers (see: Stripe, Card.io [now PayPal], Braintree, and others), as well as the introduction of some exciting alterative payments platforms (e.g. Dwolla), it is shockingly difficult to find a robust API-based solution for accepting ACH payments online [and apparently has been for a while].  I have spent the last couple months looking for just such a solution while leading Product management for an online small business lending platform, Endurance Lending Network.

Quick overview of the Pros/Cons of ACH:

ACH PaymentsACH (Automated Clearing House), also sometimes called “eChecks” or “electronic bank transfers”, is an old-school framework for inter-bank money transfer, governed by NACHA. There are two kinds of ACH transactions – a “push”, where a user instructs their bank to send money to another bank (that of your business), and a “pull”, where a user authorizes one bank (i.e. that of your business, through your web application) to request money from another bank.

  • Pros: It’s cheap (per transaction costs can be as low as $.10 per transaction), it’s scalable (it’s typically charged per-transaction, not as a percent of the transaction amount), and it’s reasonably common and therefore not “scary” to customers
  • Cons: It’s fraud-prone (while you will receive an NSF  (insufficient funds) error within 3 days, a customer can walk into her bank up to 60 days after a “pull” transaction has occurred and claim she never authorized your payment. Her bank will then claw back the money they sent you, and you’re left with little recourse outside of a lawsuit, if you can even find the customer), and the rest of this blog post as evidence, it’s hard to find a good plug-and-play provider.

Given we’re building a lending product, and have a solid legal contract in place with all of our borrowers, we’re not worried about fraud, we are moving high volumes of money per transaction, and so ACH seems like an ideal solution.  So what providers are available?

“Next Generation” solutions:

  • ZipMark – utilizing the framework for Digital Checks (think: photo deposit of paper checks) and layering in security features to guarantee ACH transactions in real-time (they take the hit in the event of insufficient funds). Solid technology, nice team based out of New York, and fixed per-transaction fees – great! Problem is, they cannot yet offer web developers substantial customization of the user experience. Your users interact with ZipMark through a “context-ignorant” Facebook-connect-like modal window.  That means that while my web application is collecting SSNs, DOBs, and other information from my users, they have to re-enter these into ZipMark to make a payment. Similarly, using ZipMark requires that users create a username / password with their service – they cannot yet handle single sign on with our application. So, overall very promising technology, but not yet about to deliver the user experience what we are looking for. 1% per transaction, capped at $5.
  • BancBox – offers a robust set of payments capabilities, including Credit Cards, ACH and PayPal, through a single set of APIs.  What’s more, they’re able to create “eWallets” within your app for your users, helping you keep their money within your marketplace vs. having to send it back out to an external bank account.  Problem is, they charge for ACH on a percent-of-transaction basis (~1%), which is far to expensive than other solutions (at ELN, we’re sending loans of up to $500K here – it’d be cheaper for me to fly to our customer’s house with a suitcase of cash than send it through BancBox). 1% per transaction, no cap.

Traditional ACH providers, with APIs:

  • PaySimple – offers an API, but it’s from a 3rd party, meaning they don’t have the expertise to support it if you run into trouble.  Overall, they just don’t come across as being very developer focused – their primary solution is a white-labeled payment interface hosted on their site.  I asked, and no, you can’t just iFrame this into your site (or at least, they won’t support you if you do).  $35/month + $.55/transaction
  • ACHDirect – same deal. Another web developer who used them told me “they sucked, but they seemed to suck the least.” — needless to say, I didn’t rush to sign a deal with them. $20/month + $.35/transaction

Others:

I’ve heard about these offerings, but when I reached out to them, they didn’t get back to me.  So… while they seem to have the capabilities, they haven’t exactly won me over yet:

Build it Yourself?

Interestingly, I have read in a few places the idea that it’s actually still easier to build your own ACH capability.  Until recently, I wasn’t really clear what that meant.  Randal Lucas recently tipped me off to this:

  • AirBnB’s Do-it-Yourself ACH Guide – AirBnB apparently went through a similar process to mine, and ended up building a simple mechanism to generate a daily dump of all the transactions that needed to be processed, would login to their bank’s portal, and upload the list.  This required daily, manual work, and manual error-handling, but as you’ll read, they think it’s the best solution available.

Hopefully this has been helpful.  Unfortunately, I can’t yet provide you a recommendation since we’re still figuring this out.  I’m leaning towards ACH Direct, Authorize.net, or do-it-yourself.

Have you found a good solution you would recommend?