Skip to main content
Rail ids are opaque strings you copy from 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: the requisites.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.
These do not open as deposit rails; they are destinations you can save as contacts and pay out to.
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.

​
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 the paymentReference on the requisites. The payer must quote it.
The bank segment is the partner behind the rail and is not something to branch on. Treat the whole id as opaque: compare it for equality, store it, copy it into POST /dapi/v1/banks, and never parse it or show it to your end users. Ids are per environment — one you hardcoded in the sandbox does not exist in production.

​
Settlement tokens

supportedTokens on a rail record is what that rail can deliver into the client’s wallet. 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. settlementToken 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 settlementToken, 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 in crypto.chain, and a quoted on-chain payin carries one in originChainId. 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 as USDC on Base, so a contact on Base is paid directly out of it. A contact on any other chain in this list 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.

Next: KYB fields

Every field of the KYB document, its accepted values, and the document slots.