GET /dapi/v1/banks. This page is what they mean 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: therequisites.fields you read off an open rail, 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.
Every other method
Every other method
These do not open as deposit rails; they are destinations you can save as contacts and pay out to.
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.
Deposit-rail coverage
These are the methods a client can hold a rail in, and the currency each one settles from. A payer wires that currency; the client’s wallet is credited in a stablecoin.GET /dapi/v1/banks is authoritative and narrower: it returns only the rails a given client may hold, after its residency is taken into account. Read currency and method off that response rather than deriving them from this table.
Rail ids
An id usually reads{method}_{named|pooled}-{bank} — the ids written this way on these pages, sepa_named-bank_a and ach_named-bank_b, stand in for the real ones — though a few carry no bank segment at all (wire_named). Two parts matter:
named— the client’s own legal name is on the account. Payers see the client; nothing else is needed for the money to be attributed.pooled— one partner account serves many clients, and each deposit is attributed by thepaymentReferenceon the account details. The payer must quote it.
POST /dapi/v1/banks, and never parse it or show it to your customers. Ids are per environment — one you hardcoded in the sandbox does not exist in production.
Accounts a rail settles into
supportedAccounts on a rail record is which of the client’s accounts that rail can deliver into, named as USDC or EURC.
A rail’s token is fixed when the rail is opened, so choosing the token means choosing the rail id: rails that can deliver either token ship as a pair of ids, one per token, with the EURC variant’s id ending in _eurc. destinationAccount on the record echoes what the open rail 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 rail record is HEVN’s deposit fee in basis points for that rail. It is a whole number: 25 is 0.25%.
Chain codes
On-chain destinations use a chain code, not a rail: a wallet contact carries one incrypto.chain, and a quoted on-chain payin 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 — 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:
GET /dapi/v1/banks/{rail}/rate. A currency HEVN does not price answers 404 not_found.
Next: KYB fields
Every field of the KYB document, its accepted values, and the document slots.