Onboarding comparsion

Overview

Wirex Pay supports two onboarding models for end-users:

1. Standard Onboarding — Users are fully onboarded into Wirex Pay with on-chain presence and internal balance management.
2. External Authorization Onboarding — Users are onboarded for partner-managed balances; settlement occurs via the partner’s Master Account.

---

Glossary

• EOA (Externally Owned Account): A standard Ethereum address (format: 0x...). In Standard flow, users control this address. In External Authorization, it serves only as an identifier.

• AA (Account Abstraction): ERC-4337 compliant smart contract wallet deployed at a unique address. Required for Standard flow, not used in External Authorization.

• KYC (Know Your Customer): Regulatory-required identity verification. Both flows use the same process with identical requirements and outcomes.

---

Standard Onboarding Flow

In the standard model, users are fully represented on-chain and inside Wirex Pay.

Steps (in order):

1. Account Abstraction (AA) Creation — Deploy a per-user AA smart wallet.
2. Registration in Accounts Contract — Register the user on-chain (status/verification plumbing).
3. Registration in Offchain API — Create/link the user in Wirex Pay’s off-chain system for UX, history, and services.
4. KYC Verification — User completes KYC; status is reflected on/off-chain per platform rules.

Data required:

• EOA Address — Serves as a unique identifier of the user on the platform
• User Email - Serves as a secondary identifier for communication and account inquiries
• KYC Information — Collected as per regulatory requirements
• AA Address - Generated during deployment (stored on-chain)

Key characteristics:

• Wirex Pay maintains per-user balances (on/off-chain projection).
• All authorizations and balance checks occur inside Wirex Pay.
• Per-user AA is the settlement endpoint.

sequenceDiagram
    title Standard Onboarding Flow
    participant U as User
    participant WP as Wirex Pay
    participant AAF as AA Factory (Blockchain)
    participant AC as Accounts Contract (Blockchain)
    participant KYC as KYC Provider

    U->>AAF: Deploy AA (per-user)
    U->>AC: Register user (EOA, AA)
    AC-->>WP: AA address
    U->>WP: createUser(EOA, email)
    U->>WP: requestKYCLink()
    WP-->>U: KYC link

    U-->>KYC: Complete verification flow
    KYC-->>WP: KYC result (approved/declined)

    WP-->>U: Onboarding complete

---

External Authorization Onboarding Flow

In this model, balances are managed by the partner, and Wirex Pay settles against a prefunded Master Account.

Steps (in order):

1. Registration in Offchain API — Create the user in Wirex Pay (no per-user AA required).
2. KYC Verification — Same KYC process as standard flow.

Data required:

• EOA Address — Serves as a unique identifier of the user on the platform
• User Email - Serves as a secondary identifier for communication and account inquiries
• KYC Information — Collected as per regulatory requirements

Key characteristics:

• No per-user AA deployment and no Accounts Contract registration required for this feature.

sequenceDiagram
    title External Authorization Onboarding Flow
    participant U as User
    participant P as Partner System
    participant WP as Wirex Pay API (WP API)
    participant KYC as KYC Provider

    U->>P: Provide EOA & email
    P->>WP: createUser(EOA, email)
    WP-->>P: UserCreated

    P->>WP: requestKYCLink(userId)
    WP-->>P: kycInitLink

    P-->>U: Present KYC link
    U-->>KYC: Complete verification flow
    KYC-->>WP: KYC result (approved/declined)
    WP-->>P: KYC status webhook/response

    P-->>U: Onboarding complete

---

Comparison Table

---

Notes

EOA Address Requirements

• Must be a valid Ethereum address format (0x followed by 40 hexadecimal characters)
• Case-insensitive, but should follow EIP-55 checksum encoding when possible
• Used as a primary user identifier in both flows

KYC Integration

• Both flows use the same KYC provider and verification process
• KYC session must be initiated after user registration
• Verification results are communicated via webhook
• The user cannot transact until KYC is approved

Edge Cases and Constraints

Registration Constraints

• EOA and email address cannot be changed after registration
• Duplicate EOA or email addresses are rejected

External Authorization Specific

• Users cannot be migrated from Standard to the External Authorization flow
• Master Account must be funded before user onboarding