> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rheon.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Payins with bank transfers
> Take money in over local bank rails and settle it as stablecoin - with or without a virtual account.
A payin 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:
| Shape | Details the user gets | Use it when |
| ------------------- | ----------------------------------------------------- | --------------------------------------------------------------- |
| **Virtual account** | Permanent, in the user's own name, reusable | They will pay more than once, or you want details they can save |
| **One-off deposit** | Issued per payment, with a reference, and they expire | They pay once, or you would rather not issue permanent details |
Start at [Bank transfers](/api-reference/bank-transfer) for the virtual account
flow, or [One-off bank deposit](/api-reference/bank-deposit) for the other. Which
one a country supports is answered by
[GET /v1/payment-methods](/api-reference/reference/payment-methods).
## 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.
| Currency | Rail | Virtual account | One-off deposit |
| ----------------------- | --------------- | --------------- | --------------- |
| EUR | SEPA | Yes | Yes |
| GBP | Faster Payments | Yes | Yes |
| USD | ACH | Yes | Yes |
| USD | SWIFT, Wire | Yes | No |
| AED | Local | Yes | No |
| AUD | Local | Yes | No |
| BRL | PIX | Yes | Yes |
| MXN | SPEI | Yes | Yes |
| COP | BRE-B | Yes | Yes |
| NGN | Local bank | Yes | Yes |
| PHP | Local bank | No | Yes |
| SLE, UGX, XAF, XOF, ZMW | Mobile money | No | Yes |
Stablecoin collection is available alongside the fiat rails - USDC, USDT and EURC
on the networks listed in [Coverage](/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.** A few
are open to individuals only or to businesses only, 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 merchant.
**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 [Payouts](/products/payouts): 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.
## What the user gets back, and what it costs
Every payin returns a full breakdown rather than a single net figure. Both legs
carry their own fees, and the FX rate and our markup are stated separately:
| Field | What it is |
| ----------------------- | ----------------------------------------------------------- |
| `source.amount` | What the user sent, in their currency |
| `source.fee` | The banking partner's fee on the incoming leg |
| `source.applicationFee` | Your fee, taken on the way in |
| `source.totalFee` | The two above, added |
| `destination.amount` | The stablecoin that settled |
| `destination.fee` | Cost on the outgoing leg, including network |
| `fxRate` | The rate applied to the conversion |
| `fxMarkup` | The markup on that rate, in basis points |
| `breakdown` | Per-leg, per-component detail, each line also valued in USD |
**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.
## Following one
A payin 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](/transactions/statuses); the
settlement hash comes back on the destination leg once the stablecoin has moved.
## Identity
A payin 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](/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](/coverage), and the live answer is
on [GET /v1/payment-methods](/api-reference/reference/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.