Skip to main content
Coverage has two sides and they are not symmetric. A client can receive fiat only over a rail it has opened, in one of a short list of currencies. It can pay a beneficiary in many more — every payout method below is a destination you can save as a contact, whether or not the same market can send money the other way.
This page is the shape of the catalogue, not a promise for your account. Rail availability is decided per integrator, per client and per partner, and the only authoritative answers are GET /dapi/v1/banks for a given client and GET /dapi/v1/contacts/{contactId}/capabilities for a given contact. Read them; do not derive from this page.

​
Money in

These are the methods a client can hold a virtual account in, and the currency each one receives. A payer wires that currency; the client is credited in the account that rail settles into. Money can also arrive on chain with no rail at all: anything sent to the client’s baseSmartWallet on Base is its balance the moment it confirms, and a transfer from another chain can be quoted first with POST /dapi/v1/payins carrying originChainId. Neither path needs a verified client — only a ready one.

​
Money out

Every method here is a destination a contact can hold. Grouped by market, with the identifiers each one routes on in Rails and payment methods.

​
Americas

​
Europe, Middle East and Africa

​
Asia-Pacific

swift is the exception to the grouping above: it is an international wire, not a domestic system, and it carries USD to a beneficiary bank in most of the world. A method suffixed _ewallet routes to a mobile wallet on a phone number rather than to a bank account. A method suffixed _local is that market’s domestic clearing system. Neither changes how you call the API: both are a contact, then a payout.

​
On chain

A client balance settles on Base, in USDC or EURC. A wallet contact on Base holding either token is paid straight out of the balance, with nothing converted and no partner involved. A contact on any other chain, or expecting any other token, is paid through a cross-chain route — the same POST /dapi/v1/payouts, quoted with fromChainId and toChainId. GET /dapi/v1/chains answers the live list: every chain, its EVM chainId, and each token’s decimals and contract address. Read it at startup rather than hardcoding the codes in Chain codes.

​
Between a client’s own accounts

A client holds up to three accounts: USDC and EURC on its Base smart wallet, and FDIC_USD when a partner bank holds a dollar virtual account for it. POST /dapi/v1/swaps moves money between any two of them it holds, and which pairs can be served at a given moment is answered by pricing them — POST /dapi/v1/swaps/preview returns the best route or refuses with 422 swap_route_unavailable (Swaps).

​
What actually decides availability

Four things narrow the catalogue above, and each one has a refusal that names it. The cheapest way to find out what a client can really do is to create one, verify it and read GET /dapi/v1/banks — in the sandbox exactly as in production. Naming the currencies and markets you sell into is part of the conversation that switches your integrator account on; see Going live.

Next: Fees

Where a fee is declared, where it is quoted, and which side of a payment absorbs it.