Creating a Modern ACH Payment Workflow

Modernization is inevitable for SaaS companies. Now, thanks to Qualpay, we were able to add ACH transfers as a payment option for services. In this article, our CEO, David Ordal, goes over the process our team went through to implement ACH.

Modern and Efficient Payment Options

One of our core operating principles is keeping our business efficient. To that end, we’re always looking at ways to simplify our payment infrastructure. 

When we started the company, you could pay us one of two ways — via credit card or PayPal. We didn’t take checks, or wires, or any other type of payment. As we’ve grown, and begun working with more enterprise customers, that’s changed. Many of our larger customers have a policy prohibiting credit card payments, and most corporate Accounts Payable departments have barely heard of PayPal.

Additionally, credit cards and PayPal are expensive — 2.9% + 30c per transaction is a typical credit card pricing model. Of course, you can do a lot better than that with interchange-plus pricing (a topic for another day), but even so, you’re still looking at a few percent, especially on smaller transactions.

ACH as an Alternative

ACH offers a way out. ACH (‘Automated Clearing House’) payments are bank to bank transfers – a way for one bank to send another bank money directly, routed with the help of a nationwide ACH network. 

From our standpoint, ACH payments work considerably differently than credit card transactions.

Credit Card Transactions

A credit card has two steps: authorize and capture. When you process a credit card, you make a request to a credit card processing network asking to verify a specific card has a certain amount of funds available. For example, ‘Does Mary Jane’s card x1234 have $100.00 available?’. You get a reply right away, and that reserves the funds for you. Sometime later (sometimes seconds, sometimes days), you’ll ‘capture’ the transaction you authorized, which moves the funds into your account.

ACH Payments

ACH is different. The big advantage of credit cards is that you know right away whether funds are available. By authorizing the transaction, you’re guaranteeing that you’ll get your payment, as long as you follow through and capture it. With ACH, you make a request to transfer funds from your customer’s bank to your bank. Then you wait. After some number of days, the funds either show up — or they don’t.

*Sender is the originator for an ACH transaction.

The big challenge with ACH is automation — traditionally, verifying that funds are received was a manual process. For us, that wouldn’t work: verifying ACH payments at scale wouldn’t be feasible.

Figuring Out the Scope of the Problem

After a series of meetings between Elizabeth (Head of Customer Ops), Amy (Customer Ops Engineering), and myself, we started to get a handle on what we needed to do.

– We knew we’d need to either find or write an ACH module to interface with our customer management and billing software, called WHMCS.

– We’d need to find a ‘modern’ ACH vendor. I’m not going to name names, but many of the vendors out there have technology that could charitably be called ‘traditional.’ Web interfaces that look like they were last updated in the days of Netscape Navigator. APIs that use heavy SOAP and XML protocols. We wanted something modern — a clean interface for us to work with, and a fast, easy to use RESTful API.

Attempt 1: A One-Stop-Shop

We figured we’d have the best time if we could find a vendor that already had a WHMCS module. So we started searching… Google ‘WHMCS ACH module’. Then, visiting the WHMCS marketplace, looking for ACH modules. 

It rather quickly became apparent that there were no solid options out there — of the few options we found, most didn’t have automated ACH — they could initiate a transaction for you. Still, it was up to you to log in and figure out if the transaction went through.

Attempt 2: Interviewing Vendors

We resolved that we’d have to write our own module, which meant finding a vendor that we wanted to work with. We’d done a lot of Google searching, and a lot of talking to vendors, but nobody was standing out. Then, lightning struck — I was fortunate enough to meet with Jon Gilbert at the Wordcamp National Conference in Nashville, TN, who worked for Qualpay. At the time, Qualpay didn’t support ACH, but they had a fantastic credit card processing platform, and ACH was on the near term roadmap. We offered to be one of their first ACH customers.

Building a Module

Now the real work began. We had to build the module that would tie our WHMCS billing and automation system into Qualpay’s ACH platform. 

The first problem to solve was to learn how WHMCS supported ACH. We knew it did — somehow; there are extant ACH modules listed on their billing automation page. By inspecting the database schema, we saw encrypted fields relating to bank information in the table for client information (bankname, banktype, bankcode and bankacct, for those of you playing our home game). While WHMCS’s documentation was a bit coy on details about how to use the fields, we were pointed in the right direction by WHMCS developer support.

Architecting an ACH Integration

Now we just had to figure out how to do the build.

We determined there would be three steps to an ACH payment:

1. Ask the customer for their bank information and store it securely.
2. On a recurring basis, send that information to Qualpay, our ACH processing gateway. At that point, we’d mark the transaction ‘Payment Pending’, to let the customer know we hadn’t received the money yet, but it was in progress.
3. Check regularly to figure out if the money had come through. If it had, we’d change the payment status to ‘Paid.’ If not, we’d leave it in ‘Payment Pending’ for up to ten (10) days. After ten days, we’d assume the payment wasn’t coming through, and we’d change the status to ‘Unpaid’ and email the customer.

We built a module that does exactly that.

A form is inserted into the invoice asking the customer for their bank account info. This form lets us capture their account details, including their routing number and account number.

Once a customer hits ‘Authorize Payment,’ we make an API call to Qualpay, to start the ACH process. We then mark the transaction as PAYMENT PENDING and store the information in WHMCS’s encrypted ACH fields for future use.

Every night, we run an automated job which: 

1. Checks the status of any submitted payments. This is pretty simple — it goes through the payment pending transactions and checks to see if they’ve completed. If they have, it marks the invoice as PAID. If the transaction hasn’t completed after ten days, or if it is marked as failed by Qualpay, the job marks the invoice as UNPAID in WHMCS and alerts the customer. 
2. Processes any due transactions (e.g., a monthly invoice). 

Going Live

We launched our integration on July 24, 2019, and have seen great success so far. Many of our clients have opted to switch to ACH payments, which is easier for them and saves money for us. ACH took some research to get working right, but has ended up to be a very positive payment option for both our customers and us.

Want file transfer built for your business? Try ExaVault today!