Skip to main content
The on-ramp is the incoming direction over a bank rail: a user sends a normal transfer in their own currency, it converts on arrival, and stablecoin settles to a wallet. Nothing is held as fiat at any point - see the warning below. Two shapes, and the country decides which one is open: Start at Bank transfers for the virtual account flow, or One-off bank deposit for the other. Which one a country supports is answered by GET /v1/payment-methods.
Provider sandbox on this deployment. Onboarding, consent and the virtual account flow run against the banking partner’s sandbox: test bank details, no real transfer, settlement on a testnet. Every response says which environment answered in its environment field.
Errors on this endpoint carry the banking partner’s own codes. The envelope is the platform one, but code and fields inside it are passed through from the banking partner unchanged rather than mapped to the platform vocabulary - a deliberate exception to the one-error-format story. Branch on the HTTP status first; treat code as a string to log and show, not a fixed set to enumerate.

​
Where money can come in

Permanent virtual accounts and one-off deposits do not cover the same set, so check the shape you intend to use rather than the currency alone. Stablecoin collection is available alongside the fiat rails - USDC, USDT and EURC on the networks listed in Coverage.
The incoming side is much narrower than the outgoing one. Roughly three times as many currencies can be paid out as can be paid in. If a corridor matters to your product, confirm the incoming leg first - it is the one more likely to be missing.
Some rails are restricted by who the user is, not only where they are. Several are closed to US residents regardless of currency, and a large share of rails - roughly a third - refuse gambling as a business category outright. That check happens on the partner’s side and cannot be waived per account, so confirm it before promising a corridor to a user.
No fiat balance exists at any point. A virtual account is a receiving address bound at creation to a conversion and settlement route, not an account with money sitting in it. There is no “withdraw fiat” action, because there is nothing to withdraw - money that lands is converted and settled immediately. To send fiat out, see Off-ramp: the user’s wallet sends stablecoin back and we transfer to the beneficiary.

​
Why a local transfer beats a cross-border one

The reason virtual accounts exist in the flow at all: a user sends money from an account in their own name to an account in their own name, in the same country and the same currency. That is a local wire - it executes faster and converts at a better rate than the same money crossing a border first. The conversion happens on our side of that hop, not the bank’s.

​
Fees

Your fee is set on the account in basis points (applicationFeeBps on the virtual account) and taken from the incoming amount; the banking partner’s fee and the conversion come out of the same amount. What an on-ramp transfer returns is the two figures you reconcile on: depositedAmount, what arrived in fiat, and deliveredAmount, the stablecoin that settled to the wallet. The difference is the cost of the transfer.
Fees come out of the amount, never added on top. A 100 EUR transfer with 1.40 in total fees settles the remainder - the user is not charged 101.40. Showing the two figures side by side without saying so reads as a surcharge.
How the layers are built - source rail, destination rail, FX markup, and your own markup or subsidy - is on Fees.

​
Following one

An on-ramp transfer passes through the partner’s own states before it is finished. Two of them are easy to misread:
  • A transfer appearing on the account does not mean the user received anything. It is listed while the money is still in flight. The delivered amount is the first moment anything true can be said about what arrived - poll for that, not for the record’s existence.
  • The details expire, the money does not. A payment already on its way still settles after expiresAt; only new payments stop being accepted.
Statuses and their meanings are in Statuses; the settlement hash comes back on the destination leg once the stablecoin has moved.

​
Identity

An on-ramp transfer is money arriving for a named person, so the user is onboarded and their identity result shared before any details are issued - see Rheon ID. Extra documents can be requested through the same flow. Address is captured by geolocation by default; proof-of-address upload is the exception rather than the rule.

​
Who may pay in

For most currencies a third party may send the money. Some rails require the payer to be the account holder - GBP over UK rails and AUD are the ones to check first. The per-currency detail is on Coverage, and the live answer is on GET /v1/payment-methods.
Sending from an account in someone else’s name on a rail that does not allow it gets the money returned, not credited. Where your product lets one person fund another, check the rail before showing the details.