Skip to content
API reference

Payout methods

Discover the payout methods enabled for your authenticated shop, their numeric payoutMethodId, currency, limits and beneficiary requirements.

GET/api/v1/me/payout/methods
Step-by-step guideStep 1 of 3

Select a stage to see what happens.

Your integration
Request readyIllustrative example
GET/me/payout/methods
Authorization
Bearer ••••••••
Accept
application/json

Prepare the request

Use credentials for the selected environment and complete the required parameters.

Illustrative flow · no data is sent

How this endpoint works

Lists the available payout methods (analogous to pay-in's GET /payment-methods). Each method carries a stable numeric `payoutMethodId` (send it to POST /me/payout/send) and the same neutral numeric identifier encoded as a string in `id`, `currency`, `country`, `rail`, indicative limits, `funded` (true if you have a payout balance in that currency) + `currencyAvailable`, `logoUrl` (alias `iconUrl`) — an absolute public URL of the rail's brand icon you can render directly (`<img src={logoUrl}>`) — and `recipientFields`: the EXACT beneficiary fields to send in the payout's `recipient` for THAT method (key, label, required, type, and `options` for bank selectors — e.g. the Colombia/Peru bank list with the exact bank_code to send). Read it to build a correct payout request without guessing. New payout methods receive their numeric ID automatically when registered in the catalog. IDs are stable within this platform and never recycled on rename or disable; they are not pay-in IDs. Only methods assigned and enabled for your shop/environment are returned. An empty list means no eligible method is configured; ask your account manager. If you want to send in a local currency with no balance, do a USD→that-currency swap first. In sandbox the synthetic `sbx_po_*` test rails are prepended.

Server-side authentication
Authentication guide
Key2Pay Developer documentationAPI v1
Documentation
Dashboard