Onboard players for gaming

Onboard players to accept in-game payments and receive payouts for winnings, rewards, or earnings.

Gaming platforms connect players who make deposits or in-game purchases with the ability to cash out. Real-money gaming, skill-based games, and platforms with marketplace or creator economics all need to verify players, enforce location-based rules, and pay out funds to cards or bank accounts. frameOS handles identity verification (KYC), geocompliance, and payment method setup so you can focus on the game.

Use this guide if you're building a gaming platform where:

• You need to verify players' identity before they transact or receive payouts.
• You're subject to geocompliance requirements and must restrict access by jurisdiction.
• Players accept card payments (deposits, in-game purchases) and receive payouts (push to card or bank account).
• Frame handles onboarding via hosted flow or you use the API with onboarding sessions.
• Each player has an individual frameOS account with capabilities for KYC, geocompliance, card verification, and payout methods.

We recommend this configuration when you get started with gaming on frameOS. You can compose the flow yourself, use the iOS or Android SDK, or build the API integration directly.

In addition to the essential tasks below, consider how you'll handle payout options (card vs bank) and compliance and verification for your markets.

Essential tasks

1. Create a Frame account and get a sandbox API key

Sign up at the Frame Developer Portal and obtain your sandbox API key. Use sandbox keys for development and testing — they do not move real money or trigger live verification services.

2. Create an individual account

Create an account for each player with the capabilities your use case requires. For gaming, common capabilities include:

curl --request POST \
  --url https://api.framepayments.com/v1/accounts \
  --header 'Authorization: Bearer sk_test_YOUR_SANDBOX_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "type": "individual",
  "capabilities": [
    "kyc",
    "kyc_prefill",
    "geo_compliance",
    "card_verification",
    "card_send",
    "card_receive",
    "bank_account_receive"
  ],
  "profile": {
    "individual": {
      "email": "player@example.com",
      "name": {
        "first_name": "Alex",
        "last_name": "Player"
      },
      "phone": {
        "number": "3107484186",
        "country_code": "1"
      }
    }
  }
}'

3. Inspect the response and currently_due

The API returns the account object with capabilities in pending status. The response includes currently_due — an array of field paths scoped to requirements that must still be collected or verified before each capability can become active. Use currently_due to understand what the user needs to provide in the onboarding flow.

{
  "data": [
    {
      "id": "2b253be3-6a41-4ae3-8f97-c7bd97c511d1",
      "object": "capability",
      "name": "phone_verification",
      "account_id": "e81bff78-b3e9-4804-9375-3e26ac941793",
      "status": "pending",
      "disabled_reason": null,
      "currently_due": [
        "terms_of_service.accepted_at",
        "terms_of_service.ip_address",
        "individual.phone_number",
        "individual.phone_country_code"
      ],
      "created": "2026-02-24T18:36:15Z",
      "updated": "2026-02-24T18:36:15Z",
      "disabled": null
    },
    {
      "id": "1449c598-eacb-4589-a8b4-f80084404f87",
      "object": "capability",
      "name": "card_send",
      "account_id": "e81bff78-b3e9-4804-9375-3e26ac941793",
      "status": "pending",
      "disabled_reason": null,
      "currently_due": [
        "terms_of_service.accepted_at",
        "terms_of_service.ip_address",
        "source.method_type",
        "source.card.expiration_month",
        "source.card.expiration_year",
        "source.card.number",
        "source.card.cvc",
        "source.billing_address.line_1",
        "source.billing_address.city",
        "source.billing_address.state_or_province",
        "source.billing_address.postal_code",
        "source.billing_address.country"
      ],
      "created": "2026-02-24T18:36:15Z",
      "updated": "2026-02-24T18:36:15Z",
      "disabled": null
    },
    {
      "id": "2a6e2f84-d37e-4437-96ec-3b2c6809f96f",
      "object": "capability",
      "name": "kyc_prefill",
      "account_id": "e81bff78-b3e9-4804-9375-3e26ac941793",
      "status": "pending",
      "disabled_reason": null,
      "currently_due": [
        "terms_of_service.accepted_at",
        "terms_of_service.ip_address",
        "individual.phone_number",
        "individual.phone_country_code",
        "kyc_prefill.confirmed_at",
        "kyc_prefill.ip_address",
        "kyc_prefill.user_agent"
      ],
      "created": "2026-02-24T18:36:15Z",
      "updated": "2026-02-24T18:36:15Z",
      "disabled": null
    }
  ]
}

Each capability lists the fields or checks that are still required. The onboarding session or hosted flow collects these from the user.

4. Redirect to onboarding session or hosted flow

Create an onboarding session and redirect the user to the session URL. Frame's hosted UI guides them through the remaining steps (identity verification, card or bank details, terms acceptance, etc.) based on the capabilities you requested.

curl --request POST \
  --url https://api.framepayments.com/v1/onboarding_sessions \
  --header 'Authorization: Bearer sk_test_YOUR_SANDBOX_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "account_id": "99c6b0da-2570-42a7-838a-5eaa318b07df",
  "return_url": "https://yoursite.com/onboarding-complete"
}'

Redirect the user to the url in the response. On mobile, use the iOS or Android SDK to present the flow in-app if preferred.

5. Capabilities move to active

After the user completes onboarding, Frame runs background services to approve the capabilities. In the Frame Dashboard, capabilities move from pending to active as each check completes. You can also retrieve the account via the API to inspect the current capability status.

Use webhooks to be notified when capabilities change, so your platform can unlock features or payout eligibility as soon as verification completes.

Payout options

The capabilities you enable depend on how you want players to receive payouts. You can support:

• Push to card — Use card_receive so players receive payouts to a debit card. Faster for players; requires card verification and KYC.
• Bank account — Use bank_account_receive so players receive payouts to a bank account. Often preferred for larger amounts; requires bank account verification and KYC.
• Both — Enable card_receive and bank_account_receive and let players choose their preferred method during onboarding.

Compliance and verification

Gaming platforms operate in regulated markets. frameOS helps you stay compliant by:

• KYC — Verify player identity before they can receive payouts. KYC prefill can speed onboarding when you already have verified phone data.
• Geocompliance — Enforce location-based rules and block access from restricted jurisdictions. See Geocompliance for details.
• Terms of service — Frame collects acceptance of terms during onboarding; you can pass terms_of_service when creating the account if the user accepts in your UI first.

Capabilities remain pending until all required checks pass. Monitor capability status via the Frame Dashboard or the API.

Resources

Accounts: Full reference for creating accounts and managing capabilities.

Onboarding Sessions: Use hosted onboarding to collect identity, payment methods, and compliance information from players.

Quick start: Get up and running with frameOS in minutes.

KYC and KYC Prefill: Identity verification and prefill flows.

Geocompliance: Location-based rules and restrictions.

Payouts: Card and bank account payout options.

SDKs: iOS, Android, and server-side SDKs for building your integration.