> ## 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.
# Rheon ID
> Verify a user once and reuse that result across cards, bank transfers, and virtual accounts.
Rheon ID is the identity layer under every product - cards, bank transfers,
virtual accounts, and card issuing. A user verifies once, and that verified result
is shared with the payment partner behind the rail they are using - so the same
person is not put through verification twice when they move from a card payment to
a bank transfer.
## How it works
They complete the verification flow: identity document, a liveness check, and
the data their jurisdiction requires.
Sharing a verified identity with a payment partner requires the user's explicit
consent. The first time, they are shown a consent screen; after that, sharing is
automatic.
The payment partner receives the verified result instead of running its own
check. A returning user goes straight through.
## Two ways identity reaches Rheon
Rheon ID has no API surface of its own. You do not start, poll, or complete a
verification by calling an endpoint, and there is no headless integration to build.
Identity data reaches Rheon in exactly two ways:
1. **Collected from the user inside the Rheon flow.** The user goes through the
verification steps above, in the widget or on the hosted page.
2. **Handed over by you, as a share token.** If you already verified the user, you
pass the result instead of sending them through the flow again.
Which of the two applies decides what you have to know about tiers - see
[What each product requires](#what-each-product-requires).
## What is collected
### Tier 1
* First and last name
* Email address
* Date of birth, read from the document
* An identity document
* A selfie with a liveness check
### Tier 2
Everything in Tier 1, plus **address verification**.
Address verification is not one fixed document. How it is satisfied depends on where
the user lives:
| Method | When it applies |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| Geolocation | The default. The user's location is captured during verification, and no address document is asked for. |
| Proof of address document + IP geolocation | Used where a document is required or where geolocation is unavailable. A utility bill or bank statement. |
| Document upload only, no geolocation | United Kingdom and Argentina. |
A proof-of-address document is **mandatory in Argentina**. Everywhere else it is a
fallback, not the default path - so most users are not asked for a utility bill.
## What each product requires
The model has two branches, and which one you are in depends on whether you pass a
share token.
**You do not pass a share token.** Rheon collects the verification once through
Rheon ID. An extra document is asked for only where a specific product or payment
method requires it - virtual accounts, bank transfers, and card issuing are the ones
that do. The user is not re-verified per product.
**You do pass a share token.** Then you have to know which tier each product and
payment method requires, because the result you hand over has to already satisfy it.
The table is the contract in that case, not background:
| Product | Requires |
| -------------------------- | ----------------------------------------------------------- |
| Card on/off ramps | Tier 2 |
| Bank transfer on/off ramps | Rheon ID, plus an extra document where the rail requires it |
| Virtual accounts | Rheon ID, plus an extra document where the rail requires it |
| Card issuing | Rheon ID, plus the extra documents issuing requires |
A user who does not meet the tier for cards is not turned away: Rheon opens its own
verification for that user and hands the result to the card partner. A user verified
for bank transfers is verified for cards and the other way round - it is one result.
For the exact document set per corridor, ask us before you build a share-token
integration.
Because geolocation is the default, the browser must be able to grant it. If you
embed Rheon in an iframe, the host page has to pass the permission through - see
[Embedding and permissions](#embedding-and-permissions). Without it, address
verification fails for the majority of users.
## By jurisdiction
What is asked varies by the user's country. This reflects the current partner set
and changes as coverage expands.
| Jurisdiction | Identity document | Liveness | Database check | Extra data |
| -------------- | ----------------------------------------------------- | ----------------------------------------------- | ----------------------------- | ------------------------------------------------------------------- |
| Spain and EEA | ID card, passport, EU residence permit | Web camera plus a recorded video identification | - | - |
| United Kingdom | ID card or passport; eVisa for resident non-nationals | Web camera | - | Postcode and phone, optional |
| Brazil | ID card, residence permit, passport, driving licence | Advanced liveness | CPF | Date of birth from the document |
| Argentina | DNI, captured live | Advanced liveness | Renaper DNI | Marital status, a sworn statement, and a mandatory proof of address |
| Nigeria | ID card, residence permit, passport | Advanced liveness | - | BVN |
| United States | ID card, residence permit, passport, driving licence | Advanced liveness | - | SSN or TIN |
| Singapore | ID card, residence permit, passport | Advanced liveness | Singapore Identity Validation | Date of birth from the document |
| Rest of world | ID card, residence permit, passport, driving licence | Advanced liveness | - | - |
An application is declined before any of this if the user's country of residence is
not served or they are under the legal age.
## What this means for your integration
* **Plan for the extra fields.** A user in the United States, Brazil, Nigeria, or
Argentina is asked for data that a user in the EEA is not. If you pre-fill the
form, pre-fill only what you actually hold, and leave the rest to the flow.
* **Do not promise a document-free flow everywhere.** Argentina always needs a proof
of address; the United Kingdom and Argentina never use geolocation.
* **Verification is a step, not a screen you own.** Unless you pass a share token,
the document, selfie, and jurisdiction-specific data are collected inside the
verification flow. You collect the basics and hand over.
## Embedding and permissions
The verification flow needs the camera, and by default it needs geolocation. When
Rheon runs inside your page as an iframe, both permissions have to be passed through
from the host document, and the host page itself must be served over HTTPS:
```html theme={null}
```
Leaving `geolocation` out of that list does not produce an obvious error - the flow
simply falls back to asking for an address document, or fails, depending on the
jurisdiction. Include it.
## Requesting an extra document
Where a partner or a jurisdiction needs a document beyond the standard set - a
utility bill, for example - it can be requested inside the same verification flow,
without sending the user somewhere else. Tell us which document and for which
users, and it is added to the flow.