How ACH payment API actually works, explained simply

What is an ACH payment API?

An ACH payment API is a set of endpoints that let your software move money directly between bank accounts over the automated clearing house network, without anyone logging into a bank portal. Instead of a human initiating each transfer, your application sends a request, and the API handles the rest.

If you have integrated a card gateway before, the mental model is similar, but the timing is different. ACH is a batch network by nature, so an ACH payment API is built around the idea that money moves in steps over a day or more, not in a single instant. Understanding that rhythm is the key to using one well.

What happens during a single ACH request?

A typical flow starts when you collect the customer's bank details and their authorization to debit the account. Your app sends those details to the API, which tokenizes them so your servers never have to store raw account numbers. The token is what you reference from then on.

Next you create a charge or transfer against that token. The API accepts the request, validates it, and queues it into the next ACH batch. At this point the payment is submitted but not final. The API returns an identifier and a status like pending so your system knows the request was accepted.

Over the following business days the transfer clears. On Flux, ACH settles in 1 to 3 business days, at which point the money is available. Your application learns about that transition through updates rather than by asking repeatedly.

How do authorization and tokenization work?

Two things have to be true before you debit an account: you have the correct bank details, and you have documented permission to pull funds. The permission part is a compliance requirement, not an optional nicety, so most teams capture and store proof of authorization alongside the token.

Tokenization is what keeps the sensitive part safe. Rather than holding account or card numbers in your database, you hold a token that stands in for them. Flux is SAQ-D Level 2 PCI DSS certified and captures card data inside origin-isolated iframes on payments.fluxpayments.com, so that data never touches your servers or your domain. The same principle of working with tokens rather than raw numbers carries through the API.

Why webhooks matter more than the initial response

The single most important thing to understand about an ACH payment API is that the first response is not the final answer. Because clearing takes days, the interesting events happen later: the payment settles, or it is returned for insufficient funds, or the account is closed. Polling the API for these changes is wasteful and slow.

Webhooks solve this. You register a URL, and Flux sends your application an event when a payment's status changes. Your code reacts: mark the invoice paid on settlement, flag a return, retry where appropriate. Designing around webhooks from the start saves you from bolting on brittle polling later.

Testing, errors, and returns

Good integrations plan for the unhappy path. ACH returns arrive after the fact, often a few business days in, and each carries a reason code such as insufficient funds or a closed account. Your system should be able to reopen an invoice or notify a customer when one lands, rather than assuming a submitted payment is a completed one.

Before going live, exercise the full lifecycle in a test environment: a successful settlement, a return, and a retry. Because the REST API and webhooks are the same primitives you will use in production, a thorough test pass tends to translate directly to a stable launch.

Where the ACH payment API fits alongside cards and stablecoins

ACH rarely lives alone. Most businesses want cards for speed and ACH for lower-cost, high-value payments. Flux exposes cards, ACH, and stablecoins through one REST API with drop-in hosted fields, tokenization, and webhooks, so you integrate once and choose the rail per transaction.

The practical payoff shows up in your books. Flux's QuickBooks integration syncs transactions to your accounting, so ACH payments that clear over several days still reconcile cleanly. That combination, one API plus automatic bookkeeping, is what makes running multiple rails manageable for a small team.