Skip to main content
A virtual account is a set of real bank details - IBAN, SWIFT, or local rails - issued to one of your users and kept for good. Your user pays it from their own bank, like any other transfer. What arrives is converted and settled as stablecoin to the wallet and chain you attached to that account, with no reconciliation on your side.

​
What it is for

Each account behaves as a programmable collection point:
  • Collection - one payer, one permanent set of details, any number of transfers.
  • Conversion - fiat that lands is converted to the output asset you set on the account.
  • Settlement - the converted amount is delivered to the wallet you attached, on the chain you named.
  • Attribution - funds arrive already tied to one user, so you are not matching names on statements.
Typical uses: a fintech giving every customer their own deposit IBAN; a marketplace giving each merchant a collection account that settles on-chain; a platform collecting EUR and holding balances in USDC.

​
How it works

1

Verify the user once

Identity is checked once and reused across rails - see Rheon ID. The user consents to sharing the result with the banking partner; a returning user is not asked again.
2

Open the account

You name the destination wallet, the chain, and the output asset. You get back the bank details to display and the fee that applies.
3

Show the details

Display the account details and the reference exactly as returned. A transfer that arrives without the reference has to be attributed by hand.
4

Money arrives and settles

The user sends a normal bank transfer. Conversion and settlement happen without another call from you. Bank transfers clear in hours or days, not seconds - do not build a UI that expects the user to wait on screen.
5

Track it

Poll for funding status until the transfer is delivered, then credit the user.

​
What an account carries

​
Fees

Your fee is set in basis points on the account and taken from the incoming amount. The banking partner charges its own fee on top of that, so what the user receives is smaller than the amount minus your fee alone. If you show a “you send / you receive” figure before the transfer, quote it - do not compute it from your own fee only.

​
API

Two ways in, depending on who drives:
  • The buyer-facing flow - onboard the user, open the account, poll for funding. Three calls, in order: the Bank transfers reference.
  • Direct management - create, read, update, and list virtual accounts from your backend, starting at Create a virtual account. Creating accounts needs the virtual-accounts permission on your API key - see Authentication.

​
Currencies, rails, and limits

EUR, GBP, USD (ACH, wire, RTP, and SWIFT), AED, AUD, BRL, MXN, NGN, and COP, plus stablecoin collection accounts on eight networks. Per-currency rails, who is allowed to pay in, and the settlement ceilings are on Coverage; pricing is on Fees. Two operational details worth building for:
  • Some accounts provision asynchronously (USD, AED, COP). The details come back empty and populate moments later - poll rather than showing your user a blank screen.
  • Not every rail accepts a third-party payer. GBP and AUD accept money only from the account holder. A transfer from someone else’s account is not a payment you can credit.