Member Creation and the Complete KYC Flow

One diagram covering member creation through KYC approval—who does what and when, plus three common wrong turns.

Member Creation and the Complete KYC Flow

There are three parties in this flow. Each step is advanced by one of them. Identify the lanes before reading the diagram:

You (the merchant server)—call the Open API
The end user—enters information on our hosted page
Our platform—reviews submissions and sends events

⚠ The dashed line in the diagram (validation fails → retry) does not return to your system. A typo

does not require you to issue a new link—the ticket is consumed only when submission succeeds.

⚠⚠ **APPROVED / REJECTED / SUPPLEMENT_REQUIRED in the platform lane

are our internal states and are not exposed through the Open API.** They appear here to explain

why you may receive another event.

You can only read the three states from GET /v1/kyc: approved / pending / none.

REJECTED appears there as none—exactly the same as never having applied.

See “What You Can Actually See” on the L1 page.

Three Common Wrong Turns

1. Identifiers: `x-on-behalf-of` accepts both types, but other endpoints may not

x-on-behalf-of accepts both identifiers: a value starting with mem_ is looked up as our internal ID; otherwise, it is looked up as your external_member_id.

This rule is not universal across the API.

Location	Accepted identifier
`x-on-behalf-of`	Either type
`GET /v1/members/{id}`, `/limits`	Either type (selected by the `mem_` prefix)
`POST /v1/members/{id}/sessions/revoke`	Only `external_member_id`

⚠ The id we return is mem_<uuid>, including the prefix. If you strip the prefix before storing it

and later send the bare UUID, it will be looked up as an external_member_id—404 member_not_found.

⚠ Selection means there is no fallback. If you have an external_member_id

that actually starts with mem_, that member will always return 404 in the three locations above. Do not use external IDs starting with mem_.

2. “Submitted” does not mean “KYC approved”

When the hosted page displays “Submitted,” the member's kyc_level is still 0. Review is asynchronous.

At this point, the status from GET /v1/kyc is pending—this is the only place where you can tell that the user has submitted their information and it is under review.

⚠ Treating successful submission as approval lets unapproved users enter services that require KYC.

They will be rejected only at the next step—after you may already have collected payment or created an order.

Wait for kyc.result.updated.

3. Do not hard-code KYC levels for each service


GET /v1/kyc/requirements

Requirements can change when our configuration or yours is updated. With hard-coded requirements, on the day of a change, your users may be blocked by your own frontend, or may complete six screens only to receive kyc_required。

Timing and Expiration

Valid for 24 hours, single use. You must pass it to the end user, who then needs to find their ID and take photos— so it is not 5 minutes. Do not expect longer either: anyone holding this URL can submit a KYC profile in that member's name.