Skip to main content
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

1

The user verifies

They complete the verification flow: identity document, a liveness check, and the data their jurisdiction requires.
2

They consent to sharing

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.
3

The result is shared

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 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: 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: 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. 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. 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:
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.