A payout is an ACH credit: money moves from the merchant to a bank account. It is the opposite direction from everything else in this section.
Reach for it when you owe someone money that is not tied to a specific earlier transaction — paying a seller on a marketplace, settling a vendor invoice, disbursing a claim. When you are returning money from a transaction you already took, refund it instead, so the two records stay linked.
- Your
Api-KeyandClient-Id— see Authentication - A processor integration configured for ACH
- The recipient's routing and account numbers
POST /v1/transactions with type set to PAYOUT.
The request shape is the same as an ACH debit — same required fields, same SEC codes, same 30-character description of which only the first 10 reach the statement. Change type from SALE to PAYOUT and the direction reverses.
CCD is the SEC code for a business-to-business payment, which most payouts are. Use PPD when you are paying an individual.
The approved payout. payment_method.type is ACH and the account identifiers are truncated, the way they are on any ACH response.
is_returned is false and returned_at is null because nothing has been returned yet. return_code and return_reason are absent rather than null — they appear only once a return arrives, which can be days after this response. batch_id is assigned, so the payout leaves at the next batch close.
{ "id": "TRANSACTION-01KEW3J7NRW9T4M2QVBXK8HZD3", "reference_transaction_id": null, "type": "PAYOUT", "result": "APPROVED", "client_id": "CLIENT-01KFDKXMQ637EKEAY410MSQSXB", "client_dba": "Acme Jewelry", "integrations": [ "VERICHECK" ], "response_code": "00", "response_description": "Approved", "batch_id": "BATCH-01KEW32V6YNV11T33XGDR7TGWC", "is_settled": false, "is_returned": false, "returned_at": null, "time_created": "2026-07-15T17:31:44Z", "amount": 25000, "tip": 0, "currency": "USD", "payment_method": { "type": "ACH", "standard_entry_class": "CCD", "account_type": "CHECKING", "route_number_truncated": "****21", "account_number_truncated": "****9012", "payment_token": "PAYMENT_TOKEN-01KFDKXMQ637ETEAY410MSQTUH", "first_name": "Dana", "last_name": "Reyes", "description": "Vendor payment" }, "metadata": { "invoice_id": "INV-2291", "sales_channel": "api" } }
The response reports the bank account with its identifiers truncated. batch_id is assigned, so the payout leaves at the next batch close.
PAYOUT works with a bank account. It does not work with a card: the gateway does not support pushing funds to a card, and a payout with a card payment method returns 400 with INVALID_ACTION and the message "Payment method not supported for this transaction type".
| Payment method | SALE | AUTH | PAYOUT |
|---|---|---|---|
| Card | Yes | Yes | No |
| Bank account | Yes | No | Yes |
| Token | Whatever the instrument behind it supports |
A payout carries the same return risk as a debit, for the same reasons: a wrong account number, a closed account, a name mismatch at the receiving bank.
Watch is_returned, returned_at, return_code and return_reason exactly as you would on a debit. return_code and return_reason are omitted rather than null when there has been no return.
Because a payout sends money you may not get back, verify the destination before sending. A returned payout arrives days later, and by then the recipient may have told you the money never came.