What does a bank payment API need to handle both pay-ins and payouts?
Payments
October 20, 2026
|
Aeropay Team
This article was written by the payments nerds at Aeropay. Our goal is to provide you with solid insights to help your business operationalize more efficient, value-focused payments.
A bank payment API that handles both pay-ins and payouts needs one integration that links the customer's bank, pulls deposits, covers the returns on those deposits and sends money back out over the fastest rail the customer's bank accepts. If any of those pieces sits with a second vendor, the fintech maintains two integrations, two sets of webhooks and two records of the same customer's bank account.
Six requirements decide whether an API does the whole job, starting with the bank connection.
Payouts should go to the account the customer deposited from, using the account token created when they linked their bank. When linking and money movement come from different vendors, the fintech copies account details from one system to the other and owns every mismatch between them.
We built Aeropay this way. Aerosync, our bank-linking product, connects to more than 12,000 US banks and credit unions, and Aeropay Payouts runs on the same integration merchants use to accept pay by bank, so adding withdrawals, refunds or rewards adds no second build.
A fintech can credit a deposit instantly only if someone covers the deposit when it comes back. An ACH debit settles in one to two business days and can still be returned after that, so crediting the user's balance at deposit time means lending them the money until settlement.
A provider guarantee moves that risk off the fintech for the returns it covers. A guarantee that covers only some return types, caps coverage below your deposit volume or excludes a lower-cost payment path leaves part of the risk with you. Our explainer on what Guaranteed ACH covers walks through those terms.
For developers, timing matters as much as scope. When the guarantee decision comes back in the payment response, your app can credit the balance in the same request instead of waiting on a second callback.
An instant payout API should try RTP or FedNow first and drop to ACH automatically when the recipient's bank can't receive a real-time payment. Real-time rails settle in seconds but don't reach every US bank, so an API that only speaks real-time leaves some users unpaid and one that only speaks ACH leaves everyone waiting.
The fallback rail sets the floor on payout speed. Same Day ACH carries payments of up to $1 million each, a limit Nacha raised from $100,000 on March 18, 2022, and any payment above that limit settles the next day (Nacha).
Set the fallback to fire when a real-time payout is rejected, not only when a bank's directory entry says it can't receive. Then check that your app gets a status update when a payout switches rails. Our post on payout speed covers how much of that delay users notice.
Your app should hear about every state change, from approved and settled to returned and paid out, without polling for it. Webhooks keep the user's balance accurate, and a reason on every decline tells your support team what to say.
Ask for the decline response itself, not the marketing description of it. A specific code, such as a balance-related or risk-related reason, lets your app tell a user to try again later or to use another account. A generic decline leaves support guessing.
The easiest API to integrate is the one your team has already run end to end in a sandbox. Integration speed claims on a pricing page say less than an afternoon spent linking a test bank, pulling a deposit and sending a payout.
For mobile apps, check that the sandbox covers app-to-app bank authorization, where the customer approves the connection in their bank's own app. That flow hands the user from your app to the bank's and back, and each handoff is a point where the payment can stall.
A migration that makes every user relink their bank costs you the users who don't bother. Ask whether existing bank connections move over by API, and whether users who have linked with the provider elsewhere can pay without linking again.
Ask questions the API documentation or sandbox can answer, so every provider is compared on the same terms. For the business side of the decision, such as which layers a provider owns, see how to choose a pay by bank provider in the US.
| Requirement | Why it matters | Question to ask |
|---|---|---|
| One bank connection for pay-ins and payouts | Removes a second integration and a second copy of account data | Is the account token from linking valid for both debits and payouts? |
| Return coverage on deposits | Decides whether you can credit users instantly | Does the guarantee decision come back in the payment response? |
| Real-time payouts with ACH fallback | Pays every user at the fastest speed their bank allows | Does a rejected real-time payout retry over ACH automatically, and does a webhook report the switch? |
| Webhooks and decline reasons | Keeps balances accurate and support answers specific | Which events fire webhooks, and what fields does a decline response return? |
| Self-serve sandbox | Lets engineering judge integration effort directly | Can we run link, deposit and payout in a sandbox without a sales call? |
| Connection migration | Avoids losing users to a relink step | Can existing bank connections move to you by API? |
The best ACH payment API for a fintech links and verifies the customer's bank in the same flow that pulls the deposit, covers returns so balances can be credited instantly and pays out through the same integration. An API that only sends ACH from account numbers you supply leaves verification and return risk with you.
Alternatives fall into three groups. Payout-only APIs send money but don't pull deposits. ACH processors move money in both directions but leave bank linking and return risk to you. Pay by bank networks link the bank, pull deposits and send payouts through one integration, which suits apps that move money both ways.
Yes. A payout to an unverified account can land in a closed account or with the wrong person, and sent funds are hard to recover. When payouts go to the account the user linked and verified at deposit, that check is already done. Large payouts warrant a live balance and ownership check before release.
Open the Aerosync sandbox and run a live bank-linking integration today, before you talk to anyone.