Account Center is the foundation for the other five products: tokens, merchant accounts, members, and webhooks all live here.

Account Center Overview

Account Center is not a business line; it is the shared layer beneath the other five products. The first line of code you write for any service passes through it: obtaining tokens, signing requests, creating members, and receiving events.

One Diagram: From Member Creation to Service Eligibility

This flow has three parties (you / the end user / our platform), two tracks (L1 and L2), and a supplementary-document loop that can return a review to the user. All are shown here:

Keep four points in mind while reading:

1. Membership is the entry point; KYC is the gate. After POST /v1/members, level is always 0— KYC results do not carry across merchants; new members do not inherit a level.
2. Both tracks support parameter submission: the merchant collects data → its server uploads files and submits JSON → we review it. Hosted links remain available as an optional compatibility method. L2 requires approved L1 (the horizontal arrow in the diagram).
3. Supplements are a loop, not an endpoint: review can return an application for more documents, which then goes back to review. L1 and L2 share the same request system, distinguished by level in the response.
4. Events only signal a change; always query the result. kyc.result.updated carries no level, no decision, and a constant status_version of 0. Query GET /v1/kyc after receiving it.

⚠ The easiest box to miss is QR payments. Its gate is not a level,

but a cumulative trigger. Members without L1 can keep paying until cumulative spending exceeds

kyc_trigger_amount. Therefore, in requirements,

required_level is 0, with an additional kyc_trigger_amount.

A level alone cannot correctly represent this service.

See Member Creation and the Complete KYC Flow for detailed steps.

Three Responsibilities Unique to This Layer

1. Authentication

One API Key issuance provides two values:

• api_key—used to obtain tokens. We store only its hash; a lost key must be reissued.
• signing_key—used for signature verification. We can retrieve it because signing is symmetric.

They are not interchangeable. See Authentication and Signing.

2. Account Structure

商户（你）
├── 预付账户   逐资产（USDT / USD / …），我方向你收的费用从这里扣
├── 授信额度   我方给你的敞口，算进低水位判据
└── 会员       你的终端用户。他们的资产由你托管，我方只记账

Members belong to you, not us. We do not manage their pricing, limits, or risk controls— that is your business. We manage you as a customer overall: limits, fees, capabilities, and risk.

3. Events

An event body contains only IDs and states, not amounts. Query details using data.id. See Webhooks for the rationale and signature verification.

Read These First

Three Conventions That Prevent Most Rework

• All amounts are fixed-point strings, with decimal places equal to the asset's ledger_scale. On-chain assets with 18 decimal places exceed 2^53; parsing them as JSON numbers causes precision loss.
• Retry 504 with the same idempotency key (we may already have completed the operation); use a new key after a business failure (the same key replays that failure unchanged).
• Treat unknown state values as unknown and alert, rather than falling back to “processing.” We commit to documenting new enums in the Changelog before adding them.