canonical: https://jentic.com/apis/adyen.com/adyen-payout # Adyen Payout API The Adyen Payout API is the classic-integration surface for storing payout details, submitting third-party payouts, and confirming or declining them with a separate review credential, plus running instant card payouts. The six endpoints implement the dual-credential flow Adyen requires for payouts: one credential stores details and submits a payout, a second credential confirms or declines it. Adyen has deprecated this API for new integrations and recommends the Transfers API for instant bank payouts and richer webhook signalling; the Payout API remains available for existing classic integrations. ## For AI agents Submit, confirm, decline, and store details for third-party payouts on Adyen's classic platform, plus run instant card payouts. ## Scope Does not authorise card payments, manage account holders, or handle disputes - use only for submitting, reviewing, and disbursing classic-platform payouts. ## Capabilities - Store payout recipient details for later use via POST /storeDetail and combined store-and-submit via POST /storeDetailAndSubmitThirdParty - Submit a third-party payout for review via POST /submitThirdParty using a stored recipient - Approve a queued payout from a second credential via POST /confirmThirdParty - Reject a queued payout from a second credential via POST /declineThirdParty - Run an instant push-to-card payout via POST /payout when supported on the network and BIN - Use distinct API credentials for the submission and review steps to enforce dual control ## Use cases ### Marketplace Seller Payouts with Dual Control Marketplaces operating on Adyen's classic platform use POST /submitThirdParty to queue a payout to a stored recipient, then a separate operator with the review credential calls POST /confirmThirdParty to release the funds or POST /declineThirdParty to reject it. This satisfies segregation-of-duties controls common in regulated payouts. Recipient bank details are stored once via POST /storeDetail and reused across submissions. Example prompt: Call POST /submitThirdParty with recurringDetailReference, amount, and merchantAccount, then from a reviewer credential call POST /confirmThirdParty with the originalReference ### Instant Push-to-Card Payouts When a recipient needs funds in minutes rather than days, POST /payout runs a push-to-card payout against eligible debit networks. This is suitable for gig-economy daily settlement, insurance disbursement, and rebate payouts when the recipient's debit BIN supports the network. The classic Payout API supports this single-call model alongside the dual-control third-party flow. Example prompt: Call POST /payout with card details, amount, recurring.contract, and merchantAccount to run a push-to-card payout ### Recipient Detail Tokenisation Storing recipient bank or card details once means subsequent payouts only carry a recurringDetailReference rather than raw account data. POST /storeDetail tokenises the details and returns a recurringDetailReference; POST /storeDetailAndSubmitThirdParty does both in one call, which is convenient when a new recipient onboards and immediately needs a payout. This reduces PII handling on the integrator side. Example prompt: Call POST /storeDetail with bank account or card details and shopperReference to receive a recurringDetailReference for future payouts ### AI Agent Payout Operations via Jentic An operations agent that processes daily seller settlements searches Jentic for 'submit an Adyen third-party payout', loads the schema for /submitThirdParty, and executes per seller from the day's settlement file. A second agent or human reviewer with the review credential confirms each payout via /confirmThirdParty. Jentic isolates the two credentials so neither the submitter nor the reviewer ever sees the other's secret. Example prompt: Search Jentic for 'submit an Adyen third-party payout', load the submitThirdParty schema, then execute one call per seller in the daily settlement file ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /submitThirdParty | Submit a payout for review | | POST | /confirmThirdParty | Approve a queued payout | | POST | /declineThirdParty | Reject a queued payout | | POST | /storeDetail | Tokenise recipient details | | POST | /storeDetailAndSubmitThirdParty | Tokenise and submit in one call | | POST | /payout | Run an instant push-to-card payout | ## Key resources - **Third-party Payouts** — Submit, confirm, and decline payouts using the dual-credential review flow - **Stored Details** — Tokenise bank account or card details once and reuse them across payouts - **Instant Payouts** — Run push-to-card payouts in a single call against eligible debit networks ## Why Jentic - **Setup:** Wiring the Adyen Payout API by hand means handling its X-API-Key or basic auth, targeting the classic PAL host, and preserving the submitter and reviewer dual-control roles yourself. Through Jentic you install once, import the Payout API from the API Directory, store each role credential once, and your agent calls it. - **Permission scoping:** The Payout API takes the payout details in the request body rather than a resource id in the URL path, so you limit the agent to the operations it needs, such as submitting a third-party payout. Because you pick the operations, confirm and decline stay out unless you include them, which lets you keep the two roles separate. - **Credential handling:** Your Adyen submitter and reviewer credentials are stored once, encrypted, as separate entries by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'submit a third-party payout' or 'confirm an adyen payout', and Jentic returns the matching Payout operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Adyen Transfers API** — Modern Adyen payout surface that supersedes the deprecated Payout API - **Adyen Transfers API v3** — Earlier major version of Transfers API that already supersedes Payout - **Adyen Payment API** — Source of funds that the Payout API later disburses - **Adyen Fund API** — Move funds between platform accounts before payout ## FAQ ### What authentication does the Adyen Payout API use? The API supports an API key in the X-API-Key header (ApiKeyAuth) and HTTP Basic auth (BasicAuth). Adyen requires two distinct credentials in production: one for storing and submitting payouts, another for confirming or declining them. Through Jentic, both credentials are stored encrypted and exposed only as scoped tokens at execution time. ### Can I run an instant payout to a debit card with the Adyen Payout API? Yes. POST /payout supports push-to-card payouts where the recipient's debit BIN and network allow it. Pass the card details, amount, and recurring.contract in the request. For broader instant payout coverage including bank rails, Adyen recommends migrating to the Transfers API. ### Is the Adyen Payout API still recommended for new integrations? No. Adyen has marked the Payout API as deprecated for new integrations and points to the Transfers API for richer payout state, instant bank payouts, and consolidated webhooks. Existing classic integrations continue to be supported, and this enrichment covers the v68 surface for those integrations. ### What are the rate limits for the Adyen Payout API? Adyen does not publish a fixed numeric rate limit for Payout in the spec; throughput is provisioned per merchant account through your contract and risk profile. If 429 responses appear, contact Adyen support to review the merchant account's payout limits. ### How do I submit a third-party payout with the Adyen Payout API through Jentic? Search Jentic for 'submit an Adyen third-party payout', load the submitThirdParty schema, then execute with recurringDetailReference, amount.value, amount.currency, and merchantAccount. From a separate reviewer credential, call confirmThirdParty with the returned pspReference. Get an account through Jentic One, the self-hosted execution layer. ### Why does the API require two API credentials? The dual-credential model implements segregation-of-duties: the credential that submits a payout cannot also confirm or decline it, which is a regulatory requirement for many payout flows. POST /submitThirdParty must be called from the submitter credential; POST /confirmThirdParty and POST /declineThirdParty must be called from a distinct review credential. ### Can I limit what my agent is allowed to do with the Adyen Payout API? Yes. Because you run Jentic One yourself, you choose exactly which of the six Payout operations the agent can call, so you can allow POST /submitThirdParty and POST /storeDetail while leaving POST /confirmThirdParty and POST /declineThirdParty out. Since this API takes the payout details in the request body rather than a resource id in the URL, the operations you select are the boundary the agent works within. That lets you keep the submitter and reviewer roles separate under your own rules, with each credential injected only for the operations you permit.