Previously, we introduced the basics of ACH. As a cheaper alternative to most credit card processing solutions (i.e., 0.8% processing fees for ACH vs 2.9% + $0.30 by most credit card providers), ACH makes a lot of sense for heavy-volume transactions and monthly recurring payments. Payments that don’t need to show up immediately in the user’s bank account—or don’t require immediate feedback from the user’s banking information—are most suitable for ACH, because unlike most credit card transactions, ACH payments take a great deal of time to get processed.
In this article, we’ll take a deeper dive into ACH and break down some of the players working with this system. In particular, we’ll focus on some of the work we’ve been doing here at Plaid with Stripe, and unpack how we’ve enabled everyone from entry-level developers to experienced engineers to accept payments with the most-used method for transferring money.
To get started with ACH payments, you need a system that can connect you (the originator of the ACH transaction) with an Originating Depository Financial Institution (ODFI). Additionally, that system should be able to give updates on the status of the payment and give the developer an interface to authenticate, verify, and charge the user on demand.
That’s where Stripe comes in. In January, the payments infrastructure giant debuted support for ACH payments through its platform alongside a partnership with us here at Plaid. Now, Stripe users can authenticate their customers through Plaid (or, if they must, micro-deposits) and then charge them through ACH.
Within a few minutes, any developer can start accepting ACH payments by just signing up for a Stripe account and accepting their ToS.
By also using Plaid, Stripe developers can skip the micro-deposit authentication process delay, and instead authorize their users through Plaid. At its core, Plaid is an entrypoint for applications that want to authenticate users to their banking accounts.
Like Stripe’s sign-up process, Plaid’s kickstarts ACH, and facilitates linking a customer’s Stripe account.
It’s important to understand the relationship between the two entities. Plaid only works as an authentication gateway and data provider for users—tokenizing the ACH process—while Stripe is the entity responsible for the ACH workflow, or the actual funds movement.
Once providers are selected, it’s important to get the ACH workflow right. Due to its robustness for both consumers and suppliers, ACH is a slow, multi-staged, layered process that focuses on protecting all parties involved. For a developer, then, it’s not hard to get trapped by one of ACH’s multiple pitfalls, like mistiming, providing the user with the product before the payment was accepted, and being unable to refute accounts with missing funds.
To clarify the workflow, we have created a play-by-play of the actors involved and how Stripe and Plaid work with each of them. Our focus is on modern implementations of the payment method.
- Developers: An ACH process might be implemented by a developer who has a software application looking to sell items and a user willing to buy them. These items could be physical products, digital applications, or any other services. Ideally, these items are registered in a online store that can keep track of them and record purchases in a database. Because records need to be kept to process the purchases—whether or not they were executed through ACH—most developers leverage existing ecommerce solutions to help manage their online stores. And in addition to having the application and goods for sale, developers need to register themselves with Stripe, providing personal information, details about their businesses, contact information, and a valid Social Security Number. Plaid doesn’t require information beyond a name and email to get started, although processing more than 100 users calls for some additional info.
- Plaid: Plaid authenticates users—the buyers—to be able to authorize ACH payments through Stripe. Plaid allows developers to include a simple module called Plaid Link in their application or store. This provides a safe gateway for users to connect their bank account simply by entering their credentials. After the connection is established, and assuming a Stripe account has been linked to Plaid, Plaid provides a valid token to be used by Stripe to continue with the ACH process.
- Financial Institutions: Financial institutions, or FIs, are the heart of the ACH workflow, functioning as the mediators of the network. They receive the ACH files from an ACH provider and transfer them to the proper clearing houses as batches at the end of every day. Depending on whether an FI is an ODFI or RDFI, it may also notify the ACH provider of the status of transactions or notify consumers of a transaction made to their account. Stripe uses Wells Fargo as its ODFI, and customers are reached by their own bank when the ACH transaction is processed. On the other side, Plaid connects with users’ banks to retrieve and authenticate their information to make sure the operations are actually authorized to be performed against customers’ bank accounts.
- Stripe: Stripe allows developers to charge ACH payments to customers. In order to do so, the developer needs to create a Customer item within Stripe’s internal system, connected to an authorized token provided by Plaid. After that, with the Customer record successfully created (Stripe will return an error if the bank isn't authorized), the developer needs to actually charge the customer by creating a Charge item in his or her databases. This Charge will then trigger Stripe to create a proper ACH file to forward to its ODFI. Because the authorization was made through Plaid, Stripe has all the information required (such as the account number and routing number) in tokenized form to proceed with the transaction. Stripe will also provide webhooks and endpoints to the developer for updates.
- Users: At the other end of the spectrum, customers are mostly unaware of the elaborate process behind the scenes to pay for the products they are aiming to buy. To authenticate transactions, the customer must simply provide his or her banking credentials through Plaid’s module. Once the details are confirmed and the transaction is completed, the user will see a pending transfer in his or her bank account, the delivery of the product or service, and, a few days later, the settled transaction.
There are multiple steps that can be taken for an ACH payment, but they can generally be divided into four stages: engaging the customer, authenticating the customer and the transaction, executing the ACH payment, and receiving the funds to deliver.
Step 1: User starts a transaction
In this case, let’s say we have a user who goes to a specific webpage. The developer has setup a proper store within that webpage that enables a user to browse, select, and request a specific item for purchasing.
Step 2: User authorizes an ACH transaction to pay for the item
After choosing something to purchase, the user has the ability to pay through his or her bank account (using Plaid) by entering the appropriate credentials. Plaid Link connects to Plaid, which proceeds to reach the user’s bank account. For institutions that require multi-factor authentication, Plaid helps provide the final steps to facilitate the connection.
Step 3: Developer schedules an ACH payment from the authenticated user
Once the user account is authenticated through Plaid, the developer gets a token and uses Stripe to schedule an ACH payment. Stripe defines customers according to their specific tokens, which are used to make charges to the correct customer. Stripe then reaches the ODFI and proceeds to give information to the developer based on the status of the transaction.
Step 4: Developer receives confirmation of payment and delivers item
After 5 to 7 business days, Stripe receives the funds from the RDFI. After that, it will provide a confirmation of the payment through a webhook. The developer can then reach the user and deliver the promised item to complete the transaction.
ACH payments can be intimidating to get started with—especially since not too long ago, only very big corporations could accept money directly via bank accounts. Now, anyone can use these technologies—and manage the biggest technical and security challenges—making it possible to execute all sorts of ideas with ease.