> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gethevn.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> HEVN accounts are non-custodial in both products. 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 customer creates and owns their account through Sign in with HEVN, a HEVN-hosted popup on the integrator's site; the integrator's backend holds a developer key, operates linked accounts and books their payouts, and the account holder approves every payout in that popup. The developer key signs only for the integrator's own wallet; it never signs a client's money.
> 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 a customer's own account linked to the integrator through Sign in with HEVN (POST /dapi/v1/connect/sessions, then POST /dapi/v1/clients/link); there is no API call that creates one. 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. Developer keys have an IP allowlist and no scopes. Remote transfers are at /api/v1/remote_spend_limit and take a remote transfer key (rsl_) in X-Api-Key, bounded by an onchain spend permission the account holder grants. They are different credentials and neither works on the other surface. The HEVN CLI is discontinued.

# Rails and payment methods

> What each payment method needs, which products a client can request, and the currency each one carries.

A virtual account is requested by **product** — a region code such as `eu` or `us` — and HEVN picks the rail behind it. This page is what each product carries and what each payment method needs.

## What each method needs

A payment method is defined by the identifiers it routes on. The same matrix governs both directions: the `requisites.fields` you read off an active virtual account, and the `fields` you send when you save a contact.

`+` means every group is required. `or` means any one of the alternatives in that group.

| Method | Identifiers |
| - | - |
| `sepa` | `iban` |
| `swift` | `accountNumber` or `iban` + `bic` |
| `ach` | `accountNumber` + `routingNumber` |
| `fedwire` | `accountNumber` + `routingNumber` |
| `ukfps` | `accountNumber` + `routingNumber` |
| `uaefts` | `iban` |
| `pix` | `pixKey` or `accountNumber` |
| `spei` | `accountNumber` or `iban` |
| `npp` | `accountNumber` + `routingNumber` |
| `nip` | `accountNumber` |
| `breb` | `paymentKey` or `accountNumber` |
| `pse` | `accountNumber` or `iban` |
| `transfers_3_0` | `accountNumber` or `iban` |

> [accordion] Every other method
>
> These do not open as deposit rails; they are destinations you can save as contacts and pay out to.
>
> | Method | Identifiers |
> | - | - |
> | `bdt_ewallet` | `financialInstitutionId` + `phoneNumber` |
> | `bdt_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` |
> | `bob_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
> | `brl_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` + `accountKind` |
> | `cad_eft` | `financialInstitutionId` + `accountNumber` + `routingNumber` |
> | `clp_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
> | `cny_alipay` | `phoneNumber` |
> | `cny_wechatpay` | `phoneNumber` |
> | `cop_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
> | `crc_local` | `financialInstitutionId` + `iban` + `phoneNumber` |
> | `dkk_local` | `iban` |
> | `dop_ewallet` | `financialInstitutionId` + `phoneNumber` |
> | `dop_local` | `financialInstitutionId` + `accountNumber` + `accountKind` |
> | `egp_local` | `financialInstitutionId` + `iban` |
> | `fednow` | `accountNumber` + `routingNumber` |
> | `gtq_ewallet` | `financialInstitutionId` + `phoneNumber` |
> | `gtq_local` | `financialInstitutionId` + `accountNumber` + `accountKind` + `phoneNumber` |
> | `hkd_fps` | `financialInstitutionId` + `accountNumber` |
> | `hnl_local` | `financialInstitutionId` + `accountNumber` + `accountKind` + `phoneNumber` |
> | `idr_ewallet` | `financialInstitutionId` + `phoneNumber` |
> | `idr_local` | `financialInstitutionId` + `accountNumber` |
> | `ils_local` | `financialInstitutionId` + `iban` |
> | `inr_local` | `accountNumber` + `routingNumber` |
> | `inr_upi` | `accountNumber` |
> | `jmd_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` + `accountKind` + `phoneNumber` |
> | `jpy_local` | `financialInstitutionId` + `branchNumber` + `accountNumber` + `phoneNumber` |
> | `krw_local` | `financialInstitutionId` + `accountNumber` |
> | `myr_local` | `financialInstitutionId` + `accountNumber` |
> | `nok_local` | `iban` |
> | `php_ewallet` | `financialInstitutionId` + `phoneNumber` |
> | `php_local` | `financialInstitutionId` + `accountNumber` |
> | `pkr_ewallet` | `financialInstitutionId` + `phoneNumber` |
> | `pkr_raast` | `financialInstitutionId` + `accountNumber` or `iban` |
> | `pln_local` | `iban` |
> | `rtp` | `accountNumber` + `routingNumber` |
> | `sar_local` | `financialInstitutionId` + `iban` |
> | `sle_local` | `financialInstitutionId` + `phoneNumber` |
> | `thb_local` | `financialInstitutionId` + `accountNumber` |
> | `try_fast` | `financialInstitutionId` + `iban` |
> | `tzs_local` | `financialInstitutionId` + `phoneNumber` |
> | `ugx_local` | `financialInstitutionId` + `phoneNumber` |
> | `vnd_local` | `financialInstitutionId` + `accountNumber` |
> | `xof_local` | `financialInstitutionId` + `phoneNumber` |
> | `zmw_local` | `financialInstitutionId` + `phoneNumber` |

Alongside the identifiers, every requisite and every contact carries a `holder`: `type` (`individual` or `business`) with `firstName` and `lastName`, or `businessName`. Some methods route on the name alone and ignore the account identifiers for matching; the identifiers are still required.

## Products

These are the products a client can request with `POST /dapi/v1/banks`, the methods its payers use, and the currency each one settles from. A payer wires that currency; the client's wallet is credited in a stablecoin.

| `product` | Methods | Currency | Region |
| - | - | - | - |
| `us` | `ach`, `fedwire` | USD | United States |
| `swift` | `swift` | USD | International |
| `eu` | `sepa` | EUR | Euro area |
| `uk` | `ukfps` | GBP | United Kingdom |
| `uae` | `uaefts` | AED | United Arab Emirates |
| `br` | `pix` | BRL | Brazil |
| `mx` | `spei` | MXN | Mexico |
| `co` | `breb` | COP | Colombia |
| `au` | `npp` | AUD | Australia |
| `ng` | `nip` | NGN | Nigeria |

`GET /dapi/v1/banks` is authoritative and narrower: it returns only the products a given client can request, after its residency and legal form are taken into account. Read `currency` and `method` off that response rather than deriving them from this table. The `product` enum in the API reference lists more codes than this table; a code with no rail behind it for a client is simply absent from that client's list, and requesting it answers `403 rail_not_available`.

The product is the key: the same code in every environment, and the one you send, store and put in the path. `rail` on the record names the route HEVN chose behind it. It is informational and can change while the record is `preparing` — compare nothing against it and never show it to your customers.

A named account is opened in the client's own legal name, so payers see the client and nothing else is needed for the money to be attributed. A pooled account is one partner account serving many clients; its account details carry a `paymentReference`, and each deposit is attributed by it, so the payer must quote it.

## Accounts a rail settles into

`supportedAccounts` on a virtual account is which of the client's accounts its rail can deliver into, named as `USDC` or `EURC`, and `railCurrency` is what the rail delivers.

The token is fixed by the rail, and HEVN picks the rail for the product, so it is not something you choose when you request. `destinationAccount` on the record echoes what the active account delivers.

Per deposit the choice is on the money-in call: `POST /dapi/v1/payins` takes a `destinationAccount`, and a token no rail of the client's settles into answers `422 payin_not_available` with `details.options[]` listing the pairs that do.

`feeBps` on the record is HEVN's deposit fee in basis points for that product, from the client's plan. It is a whole number: `25` is 0.25%.

## Chain codes

On-chain destinations use a chain code, not a rail: a wallet [contact](https://docs.gethevn.com/whitelabel/payouts.md#save-an-address-as-a-contact) carries one in `crypto.chain`, and a quoted on-chain [payin](https://docs.gethevn.com/whitelabel/payins.md#quote-an-on-chain-transfer) carries one in `originChainId`.

`GET /dapi/v1/chains` answers the live list rather than this page: every chain, its EVM `chainId`, and each token's `decimals` and contract `address`. `settlement: true` marks the chain balances live on, and a token's `account` names the account it holds when a client can hold a balance in it. Read it once at startup instead of hardcoding what follows.

`eth` · `bsc` · `avax` · `op` · `arb` · `pol` · `sol` · `base` · `gnosis` · `tron` · `xrp` · `zec` · `doge` · `ltc` · `btc` · `cardano` · `bera` · `sui` · `near` · `near_intents` · `xlayer` · `plasma` · `ton` · `stellar` · `monad` · `starknet` · `aptos` · `adi` · `bch`

A client balance settles on **Base**, in USDC or EURC, so a contact on Base holding either token is paid straight out of it. A contact on any other chain in this list, or expecting any other token, is paid through a [cross-chain route](https://docs.gethevn.com/whitelabel/payouts.md#a-routed-payout-is-priced) — the same `POST /dapi/v1/payouts`, quoted with `fromChainId` and `toChainId`, refused with `409 payout_not_fundable` when routing is unavailable for the account.

## Market rates

`GET /dapi/v1/rates?from=EUR&to=USDC` converts one currency or token into another at the current market rate, before any transfer exists:

```json theme={null}
{ "fromCurrency": "EUR", "toCurrency": "USDC", "rate": "1.14776038", "indicative": true }
```

Both sides accept a fiat code or a token symbol, so a fiat pair, a token pair and a mixed pair answer the same way. It is a display rate and says so: the rate a transfer settles at comes from that transfer's own quote, and a rail's deposit rate comes from `GET /dapi/v1/banks/{rail}/rate`. A currency HEVN does not price answers `404 not_found`.

> [card] [Next: KYB fields](https://docs.gethevn.com/whitelabel/reference/kyb-fields.md)
>
> Every field of the KYB document, its accepted values, and the document slots.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.