> ## Documentation Index
> Fetch the complete documentation index at: https://hevninc.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> HEVN has two products and they authorize money differently. Self-serve (the General tab): the person who owns the email holds the only key and signs for themselves. Whitelabel (the Whitelabel and REST API tabs): the integrator's backend holds a developer key, signs on behalf of client accounts it created, and HEVN co-signs. Never mix the two models in an answer.
> Use HEVN's terms exactly. A rail is a bank route a client can request. A virtual account (bnk_) is an opened rail. Account details are what a payer needs in order to wire money, and arrive in a field named requisites. A client is an account the integrator created; the business behind it is the integrator's customer. A contact is a saved destination; a beneficiary is the party at the far end of a fiat payout. Every departure of money is a payout, to a bank account or to a wallet alike.
> Never name a banking partner. Say 'a licensed banking partner'.
> There are no published fee rates, spreads or minimums. Prices come from a quote on a specific payment; direct pricing questions to HEVN rather than inventing numbers.
> The whitelabel API is at /dapi/v1 and takes a developer-key session plus an X-Hevn-Account header. The CLI uses an app API key in X-Api-Key. They are different credentials and neither works on the other surface.
# Coverage
> The currencies and payment methods money can arrive in and leave by, the chains a payout can reach, and why the authoritative answer is always per client.
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.
| Method | Currency | Market |
| --------------- | -------- | -------------------- |
| `ach` | USD | United States |
| `fedwire` | USD | United States |
| `swift` | USD | International |
| `sepa` | EUR | Euro area |
| `ukfps` | GBP | United Kingdom |
| `uaefts` | AED | United Arab Emirates |
| `pix` | BRL | Brazil |
| `spei` | MXN | Mexico |
| `npp` | AUD | Australia |
| `nip` | NGN | Nigeria |
| `breb` | COP | Colombia |
| `pse` | COP | Colombia |
| `transfers_3_0` | ARS | Argentina |
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](/whitelabel/reference/rails#what-each-method-needs).
### Americas
| Currency | Market | Methods |
| -------- | ------------------ | --------------------------------- |
| USD | United States | `ach`, `fedwire`, `fednow`, `rtp` |
| CAD | Canada | `cad_eft` |
| MXN | Mexico | `spei` |
| BRL | Brazil | `pix`, `brl_local` |
| ARS | Argentina | `transfers_3_0` |
| COP | Colombia | `breb`, `pse`, `cop_local` |
| CLP | Chile | `clp_local` |
| BOB | Bolivia | `bob_local` |
| CRC | Costa Rica | `crc_local` |
| GTQ | Guatemala | `gtq_local`, `gtq_ewallet` |
| HNL | Honduras | `hnl_local` |
| DOP | Dominican Republic | `dop_local`, `dop_ewallet` |
| JMD | Jamaica | `jmd_local` |
### Europe, Middle East and Africa
| Currency | Market | Methods |
| -------- | --------------------------- | ----------- |
| EUR | Euro area | `sepa` |
| GBP | United Kingdom | `ukfps` |
| PLN | Poland | `pln_local` |
| DKK | Denmark | `dkk_local` |
| NOK | Norway | `nok_local` |
| TRY | Türkiye | `try_fast` |
| ILS | Israel | `ils_local` |
| AED | United Arab Emirates | `uaefts` |
| SAR | Saudi Arabia | `sar_local` |
| EGP | Egypt | `egp_local` |
| NGN | Nigeria | `nip` |
| XOF | West African CFA franc zone | `xof_local` |
| SLE | Sierra Leone | `sle_local` |
| TZS | Tanzania | `tzs_local` |
| UGX | Uganda | `ugx_local` |
| ZMW | Zambia | `zmw_local` |
### Asia-Pacific
| Currency | Market | Methods |
| -------- | ----------- | ----------------------------- |
| AUD | Australia | `npp` |
| JPY | Japan | `jpy_local` |
| KRW | South Korea | `krw_local` |
| CNY | China | `cny_alipay`, `cny_wechatpay` |
| HKD | Hong Kong | `hkd_fps` |
| INR | India | `inr_local`, `inr_upi` |
| IDR | Indonesia | `idr_local`, `idr_ewallet` |
| MYR | Malaysia | `myr_local` |
| PHP | Philippines | `php_local`, `php_ewallet` |
| PKR | Pakistan | `pkr_raast`, `pkr_ewallet` |
| THB | Thailand | `thb_local` |
| VND | Vietnam | `vnd_local` |
| BDT | Bangladesh | `bdt_local`, `bdt_ewallet` |
`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](/whitelabel/reference/rails#chain-codes).
## What actually decides availability
Four things narrow the catalogue above, and each one has a refusal that names it.
| What | Effect | You see |
| ------------------------------------- | ------------------------------------------------------- | --------------------------------------------------------------------- |
| Your integrator agreement | Which rails HEVN enables for you at all | `403 rail_not_available` on `POST /dapi/v1/banks` |
| The client's residency and legal form | Which of those rails this client may hold | The rail is absent from `GET /dapi/v1/banks` for that client |
| The client's verification state | Whether a rail can open, and whether it can go `active` | `422 rail_requirements_unmet` with `details.blockers` |
| The partner behind the rail | Whether it is accepting business right now | `503 provider_unavailable`, or the rail reports `channel_unavailable` |
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](/whitelabel/going-live#what-hevn-must-enable).
Where a fee is declared, where it is quoted, and which side of a payment absorbs it.