Skip to main content
A virtual account is an account that a partner bank opens for a client to receive bank transfers. Request one with POST /dapi/v1/banks and a product. The partner bank converts each incoming payment and delivers the settlement token to the client’s Base smart wallet, or to the account named in accountId. Routes here take X-Hevn-Account. Without it they act on your integrator account. See Acting as a client.

Request a virtual account

Call POST /dapi/v1/banks with one product. Responses and refusals are in Request a receiving account.

Statuses

In production the partner bank opens the account after a review and sets the timing. The sandbox has no review.

Deliver to an account

Send accountId, the acc_… id of an external account or a sub account, to open a virtual account that delivers to that account’s address. Without it the virtual account delivers to the Base smart wallet.
Response 201, Location: /dapi/v1/banks/us?accountId=acc_5Jd8Qw2LmX
The rules of each kind are on External wallets and Sub accounts.

List products

Call GET /dapi/v1/banks to read each product the client can request, or GET /dapi/v1/banks/{product} for one.
Fields are in List virtual accounts. Products are listed in the rail reference, and fees in Fees.

What still blocks it

url is absent on verification_required for a linked individual.

Account details

fields has the identifiers the method uses, listed per method in the rail reference. ContactPaymentAccountView on a contact has the same fields, holder and bankName as RailRequisitesView here. Give the payer fields, the holder name, bankName and any paymentReference. Field rules are in Retrieve one virtual account.
When paymentReference is set, a payment without it cannot be attributed to the client.

Next: Payins