Payout API

A payout API is an application programming interface that lets a business send money out by software. The business's system makes a request to a bank or payment provider stating who should be paid, how much, in which currency and by which method, and the provider delivers the funds to the recipient's bank account, card or wallet and reports the result.

Payout APIs are used by marketplaces paying sellers, gig platforms paying workers, insurers paying claims, lenders disbursing loans, payroll services and remittance companies. They replace manual bank portal entry and the uploading of batch files with an automated, payment-by-payment connection, and they are the usual way of reaching several payment systems and countries through one integration.

Most payout APIs follow the conventions of a REST API, with requests and responses in JSON, and expose a similar set of functions.

• Recipients. The business registers each payee with name, country and account, card or wallet details. Providers validate the format and may verify the account, the subject of beneficiary onboarding.
• Balances and funding. The business checks how much it holds with the provider in each currency and obtains instructions for adding funds.
• Quotes. For a payout in another currency, the API returns an exchange rate and fee, often held for a short period.
• Payouts. The core request creates a single transfer; a batch payout request creates many at once.
• Status. Each payout can be queried, and changes are pushed to the business by webhook notification.
• Reports. Statements and transaction lists support payout reconciliation.

The API is an instruction channel; the money has to be in place first. In the commonest arrangement the business transfers funds to the provider in advance, and the provider records them as a balance. This prefunding means that each payout request simply reduces the balance, and a request that exceeds it is refused. Some banks instead debit the business's own account for each payout, and some providers extend a credit line to established clients.

When a payout is created, the provider screens the recipient, selects a payout rail and submits the payment. A domestic payout might go over an instant payment scheme, an automated clearing house or a push to a debit card. A cross-border payout is converted and then delivered through a local bank or partner in the destination country. The logic that chooses among the options is payout routing. The recipient sees a credit from the provider or its partner bank, with the business's name in the reference.

A successful API response rarely means the money has arrived. It means the instruction was accepted. The payout then moves through states such as pending, processing, paid and failed, at a pace set by the rail: seconds for instant schemes, a day or more for batch systems. Some rails confirm delivery; others report nothing unless the payment is returned, which can happen days later.

A payout failure may therefore occur at three points: immediately, when validation rejects the request; shortly after, when the receiving bank rejects it; or later, as a return. In the last two cases the provider credits the amount back to the balance and notifies the business, which must then correct the details and try again. Integrations need to treat a payout as final only when the provider says so, and to handle a payout that moves from paid back to returned.

Because the interface moves money out, its security matters more than that of a collection API. Requests are authenticated with an API key or a short-lived token, and providers commonly add request signing, restriction to listed network addresses, separate credentials for creating and for approving payouts, and limits per transaction and per day. Stolen credentials or a compromised server can otherwise be used to drain the balance.

Duplicate payments are the classic operational error. If a request times out, the business cannot tell whether it was received, and sending it again might pay twice. Payout APIs therefore accept an idempotency key, a unique value supplied with the request; a repeat with the same key returns the original result instead of creating a second payout.

Compliance checks run inside the flow. The provider performs sanctions screening on recipients, monitors payout patterns and may hold a payment for review, so a business should expect occasional delays and requests for information. The business, for its part, is normally required to have identified its own payees. Providers supply a sandbox environment in which all of these outcomes, including failures and returns, can be simulated before going live.

Providers differ in the countries and rails they reach, whether they hold the necessary licences themselves or rely on partners, their pricing per payout and for currency conversion, their cut-off times, and the quality of status information they return. Businesses with large or critical volumes often integrate two providers and switch between them when one has an outage. Rate limiting on the provider's side caps how many requests can be sent per second, which matters for platforms that pay thousands of recipients at the same moment and may need the batch function or a queue to spread the load.