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 routing and account numbers are cut to their last four digits, 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. The payout joins the open batch and leaves at the next batch close, so batch_id is null until then.
{ "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": null, "is_settled": false, "is_returned": false, "returned_at": null, "time_created": "2026-07-15T17:31:44Z", "amount": 25000, "tip": 0, "tax_amount": 1250, "currency": "USD", "payment_method": { "type": "ACH", "standard_entry_class": "CCD", "account_type": "CHECKING", "route_number_truncated": "0021", "account_number_truncated": "9012", "payment_token": "BANK_TOKEN-01KFDKXMQ637ETEAY410MSQTUH", "first_name": "Dana", "last_name": "Reyes", "description": "Vendor payment" }, "recurring": false, "metadata": { "invoice_id": "INV-2291", "sales_channel": "api" } }
The response reports the bank account with the routing and account numbers cut to their last four digits. The payout joins the open batch and leaves at the next batch close, so batch_id stays null until then.
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.