Platform Partners

INVO Network supports non-gaming platform partners (video, microdrama, social, creator, and other digital experiences) that want to use INVO as their payment rail and ledger. This page is a high-level overview for partner teams. The technical onboarding contracts are negotiated individually.

Who is this for?

Companies running consumer apps that want a turnkey way to:

  • • Sell a branded in-app currency to their users with real money
  • • Have users spend that currency on items, unlocks, or subscriptions inside the platform
  • • Let users move balances to and from other platform tenants on the INVO Network
  • • Cash out the platform's earned revenue to their bank account

Platform status is now self-serve: any developer can choose it when adding an app, or claim it later for an active game from the Platform & Keys page in the developer dashboard (see below). Identity verification (KYC) is needed only before you withdraw earnings, not to become a platform. Negotiated fee splits and custom contracts still start with the contact at the bottom of this page.

Self-serve setup: Platform & Keys

Everything below is done from the Platform & Keys page in the developer dashboard. Sign in at console.invo.network (or console.invo.network/test for sandbox), open the user menu in the top-right corner, and choose Platform & Keys.

  1. 1

    Claim platform status

    Pick your game, then under Platform status choose Video platform, Creator platform, or Social platform and apply. The change is instant. There is no approval queue. The one requirement is that the game is live or testing. No identity verification is needed to claim it; that is asked for only before a withdrawal. Every claim is audited. If you create apps through the API, send tenantType (game, video_platform, creator_platform or social_platform) to choose at creation; omitted means game.

    You can switch back. Switching between game and platform is self-serve in either direction, here or with POST /api/dev/games/{game_id}/tenant-type, until the title's first live transaction. After that the switch returns 409 TENANT_TYPE_LOCKED_AFTER_LIVE_TRANSACTION, and INVO makes the change after review. Changing between Video platform, Creator platform and Social platform is always allowed. Switching to a platform resets a game-only storefront payment rail to the card rail, because those routes are for games. Currency moves between games and platforms in both directions either way; see Cross-Game Transfers.

  2. 2

    Get your SDK secret key

    The SDK secret key card lets you reveal and copy your ivsdk_… key, and rotate it at any time. Rotation has a 7-day grace window: the old key keeps working while you cut your integration over. See Partner Credentials & Key Handling for the handling rules.

  3. 3

    Web platforms: passkey step-up

    Nothing to configure. Passkeys run on INVO’s hosted approval page for every title. Details on Platform Step-Up (WebAuthn / Passkeys).

  4. 4

    Configure your webhook

    The console links straight to the dashboard's Webhooks page for your game. Endpoint URL, event selection, signing secret, and delivery history live there. Contract details: Receiving Webhooks.

Tenant type: game or platform

Every title on INVO is a tenant, and every tenant has a type. A new title is a game. A platform tenant is a non-game app: Video platform, Creator platform or Social platform. You see and change the type on the Platform & Keys page of the console; claiming platform status returns tenant_type and is_platform.

Identifiers say "game" by design. A platform is addressed exactly like a game: game_id, the X-Game-Secret-Key header, the /api/dev/games routes, and tenant_id on webhooks. Nothing is renamed for platforms, so the same integration code works for both.

The same rates, tiers and tax. Card fees, the international card fee, the minimum card purchase, the item and transfer fees, the payout fee, the Open and Merchant of Record tiers and who handles tax do not depend on the tenant type.

What the type changesGamePlatform
Platform Commerce (items paid by balance or card)Not available (403 NOT_A_PLATFORM_TENANT); sell items for coins with Item PurchaseAvailable
Where currency can moveTo and from other games and platformsTo and from other platforms and games
Storefront payment routes (Steam, the game storefront rail)AvailableNot available (RAIL_NOT_AVAILABLE_TO_PLATFORM); the card route is
Loyalty campaignsA campaign can admit games, platforms or both; a title can only enrol in a campaign that admits its type.

Changing it. Switching is self-serve and instant in either direction (the Platform & Keyspage, or POST /api/dev/games/{game_id}/tenant-type) until the title's first live transaction. After that a switch between game and platform answers 409 TENANT_TYPE_LOCKED_AFTER_LIVE_TRANSACTION; INVO makes that change after review. Changing between platform kinds is always allowed. Becoming a platform needs the title to be live or testing; no identity verification is needed (that is asked for only before a withdrawal). Switching to a platform resets a game-only storefront payment rail to the card rail.

What Partners Get

Branded currency

You name the currency (e.g., your platform's "Stars," "Tokens," "Credits"). The network rate is fixed at 1 USD = 10 units; the brand is yours.

Hosted checkout

Card data never crosses your servers. Partners are SAQ-A scope. INVO processes the payment, handles PCI and 3DS, runs the dispute process, and pays you out. The checkout page can show your own logo in place of INVO's. On the default Open tier your business is the seller and is responsible for its own sales tax; see Tiers.

Cross-tenant transfers

Your users can move balances between your platform and any other tenant on the network, games and platforms alike (see tenant type). Two flows: self-transfers (same human, two tenants) and player-to-player sends (gifting by phone). The sender approves with a passkey or QR device approval, the receiver collects, settlement happens server-side; you receive an authoritative webhook on every completion.

Outbound webhooks

HMAC-signed deliveries for every state change: purchases, refunds, transfers, payout status. Replay-safe: dedupe on X-Invo-Idempotency-Key, which is stable across retries and replays.

Transparent revenue split

The default network fee is 5% on each item-purchase transaction (95% to the partner), 3.5% on a Platform Commerce purchase paid from a balance, and 3.5% + $0.15 on every INVO card charge: coin purchases, Platform Commerce card sales and subscriptions (5.0% + $0.15 on Merchant of Record), plus 1.5% on a card issued outside the US. The $2.99 minimum card purchase is enforced from 2026-10-27. The card fee is paid by you, never added to the player's price, and includes fraud screening on every card payment; the fraud chargeback guarantee is included on Merchant of Record (Open-tier card payments made before October 21, 2026 keep it; from that date a chargeback on an Open card payment is yours whatever the reason). On both tiers the card network's dispute fee on a card dispute opened from October 21, 2026 is passed through to you at cost, except on a dispute the guarantee covers. Transfers and sends carry the network-standard 10% split (3.5% sending title, 3.5% receiving title, 3% INVO). Purchases through a third-party storefront or payment rail are unaffected. Negotiated rates are available on request and show up in your fee schedule. Fees by tier: Tiers.

Programmatic payouts

Request a payout of your accrued revenue at any time via API. We dispatch the bill internally, ACH the funds to your bank, and notify your webhook on every status transition. A payout you request this way is on demand: it carries a 1% payout fee, capped at $500, and must be at least $10. Payouts on INVO's schedule (the 1st and 16th of each month) are free; GET /api/partner-payouts/schedule returns the schedule.

Web step-up (passkeys)

Web platforms verify high-value transfers and sends in-browser with a WebAuthn passkey (phishing-resistant, hardware-bound, and user-verified) bound to the specific transaction. The ceremony runs on INVO’s hosted page, so there is nothing to configure. Platform Step-Up →

Cross-tenant transfers & sends

Once your partner tenant is provisioned, your users can move their branded-currency balance to and from other live tenants on the network, games and platforms alike, through the same REST API gaming-tier developers use.

Self-transfer

A user moves their own balance from your platform to a destination tenant where they're also a user. Initiate the transfer, the sender approves with a passkey or QR device approval (POST /api/sdk/transfers/{id}/approve), then the destination tenant collects it.

Transfer API docs →

Player-to-player send

Phone-based gifting. Recipient may not exist on Invo yet. Initiate the send, the sender approves with a passkey or QR device approval (POST /api/sdk/send/{id}/approve), then the recipient collects: in-game with their player token. INVO emails the claim link when the receiver's email is already on file for that phone; otherwise the receiver collects in the game.

Send API docs →

Verify in-browser with passkeys (web platforms)

Web platforms verify a transfer or send in the browser. Passkeys run on INVO’s hosted page with nothing to configure: users approve a high-value action with a WebAuthn passkey (Touch ID / Windows Hello / a security key) bound to the specific transaction, phishing-resistant and hardware-backed. Players without a passkey use hosted or QR device approval, and the rest of the lifecycle is unchanged. See Platform Step-Up (WebAuthn / Passkeys).

How transfer fees work for partners

User always pays a 10% network fee on the transfer amount. The network standard split:

  • • 3.5% to the source tenant
  • • 3.5% to the destination tenant
  • • 3% to Invo (network fee)

When sender and recipient are in the same title, that title keeps both shares (7%). On a 100.00 transfer the fee is 10.00: 3.50 to each title (7.00 to a single title on a same-title move) and 3.00 to Invo; the recipient receives 90.00. Sends between players use the same split. See the worked example.

The transfer rate is a network standard at 3.5% per side. It is the same for every partner and is not set per tenant, so there is no rate to negotiate and none to configure. The user-paid total is always exactly 10%. Read the actual numbers from fee_breakdown in the API response and fee_total in the webhook payload. Don't recompute client-side.

Transfer policy on your tenant

Three flags Invo admin sets on your tenant during onboarding:

  • • allows_outgoing_transfers: your users can send out
  • • allows_incoming_transfers: other tenants' users can send in
  • • universal_transfers: 'yes' to allow any active tenant; 'no' to whitelist specific ones via linked_game_ids[]

Always call POST /api/transfers/available-destinations first to discover which destinations are reachable from your tenant before showing options to the user. Don't hardcode destination ids.

How Partner Integration Works

  1. 1

    Kickoff & agreement

    Initial scoping call, ToS and revenue split agreed, designated technical contact identified on each side.

  2. 2

    Sandbox provisioning

    Register your game in the sandbox dashboard, claim platform status on the Platform & Keys page, and copy your sandbox SDK key from the same page. Configure your webhook receiver URL on the dashboard's Webhooks page. The signing secret is shown once on creation. INVO stands up your branded currency.

  3. 3

    Build against sandbox

    Your engineering team integrates against the same REST API documented elsewhere on this site. Hosted checkout, item purchase, and webhook handling are the same contracts that gaming-tier developers use.

  4. 4

    Soak window

    Run real flows in sandbox for a typical 2 to 4 week QA window before flipping to production. Reconciliation diffs should match your internal ledger nightly.

  5. 5

    Production cutover

    Your sandbox title is copied into production for you, once, automatically (no rebuilding by hand): its name, description, artwork and default currency come across, and production mints entirely new keys for it. A platform keeps its platform type there once your identity verification is approved in production. Then finish the production-only setup (Platform & Keys for the SDK key, Webhooks page for the signing secret), swap your base URL, set the title to Live yourself, run a small live transaction set, and you're live.

Partner Payouts

As your users top up and spend, your tenant accrues revenue (the default 95% partner share on every item purchase, plus any custom rate negotiated in your agreement). INVO pays it to your bank account itself. You can request a payout at any time:

What you send

  • • Amount in USD (must be ≤ current owed balance)
  • • Contact email for status updates
  • • The destination: a bank account added and verified in the INVO console, owned by the account that owns the game
  • • Idempotency key so retries don't double-pay

What happens next

  • • INVO admin reviews the request
  • • On approval, an internal bill is created and ACH'd
  • • Your webhook receives payout.status_changed events as the payout moves (requested → approved → processing → completed)
  • • Your owed balance decrements by the paid amount
  • • An on-demand payout to your bank carries the payout fee (1% of the payout, capped at $500 per payout by default), deducted from the amount sent, and must be at least $10 (below it: 400 BELOW_PAYOUT_MINIMUM). Creator payouts have no minimum. Payouts on INVO's schedule are free. Each payout reports offboarding_fee_pct, offboarding_fee_cap_usd, offboarding_fee_usd and net_payout_usd; see the payout fee

Account numbers are encrypted at rest; only the last four digits ever appear in API responses or webhook payloads.

Requesting a payout: POST /api/partner-payouts/request

Authenticate with X-Game-Secret-Key. Payouts are sent only to a bank account that the account owning the game has added and verified in the INVO console, the same rule a withdrawal follows. Name it one of two ways:

  • • bank_account_id (optional, recommended): the id of that verified bank account. selected_bank_account_id is accepted as an alias.
  • • bank_account: the typed details block, still accepted. It must match one of those verified accounts. If you send both, they must name the same account.
{
  "amount_usd": "500.00",
  "contact_email": "ops@example.com",
  "client_request_id": "9b1f0c3e-...",
  "bank_account_id": 12
}

The payout is always written from the verified account on file, never from typed values. A request whose destination does not qualify is refused with 400 and nothing is created:

  • • PAYOUT_BANK_ACCOUNT_NOT_ON_FILE: the id or details match no active bank account of the account that owns the game. Add the account in the INVO console, have it verified, then request again.
  • • PAYOUT_BANK_ACCOUNT_NOT_VERIFIED: the account is on file but cannot receive payouts yet. Complete its verification in the INVO console.
  • • PAYOUT_BANK_ACCOUNT_DETAILS_MISMATCH: bank_account_id and the bank_account details were both sent and name different accounts.

A retry with the same client_request_id returns the payout already created.

The owed balance is net of money already claimed. It excludes the account's pending withdrawals and its other requested payouts, as well as approved payouts. A request above that figure is refused with 400 INSUFFICIENT_OWED_BALANCE, carrying owed_balance_usd and requested_amount_usd. With nothing else pending the figure is unchanged.

Payouts are held while the account is not in good standing. A request made while the account that owns the game cannot be paid out is refused with 403 and nothing is created. The error_code says why:

  • • ACCOUNT_SUSPENDED: the account is suspended or closed. See account standing.
  • • PAYMENTS_PAUSED: INVO has paused payments on the account. Payouts already requested are paid once payments resume.
  • • ACCOUNT_UNDER_REVIEW: payouts are held while INVO reviews the account.

A payout to a creator (below) is refused the same way. Contact INVO support.

Statuses can be skipped or repeated. A payout can go from requested straight to completed or failed without an approved or processing event, and the same status can arrive twice as separate events. Dedupe deliveries as you do for every webhook, apply a status that is later than the one you have recorded, and ignore a repeat. Use previous_status only to drop an event older than what you have; do not require it to match your recorded status.

A payout that could not be sent reads status: "failed", and its failure_reason on the payout reads is always the same neutral sentence: "Payout could not be sent. INVO will contact you." The amount is owed to you again and can be requested again. While INVO is resolving a problem sending an approved payout, the payout stays approved and may show the same sentence.

Approved payouts are money on its way. From approval until the payout is completed or marked failed, its amount is not available for a withdrawal or another payout. A payout request refused for insufficient owed balance, while a payout is in flight or a Merchant of Record chargeback reserve is held, carries in_flight_payouts_usd, reserve_held_usd, reserve_next_release_at, reserve_release_schedule, reserve_terms, balance_before_reserve_usd and reserve_scope: "developer_account". With nothing held and nothing in flight the refusal is unchanged.

A payout the receiving bank sends back moves from completed to returned, with returned_at and return_reason_code set. What the bank sent back (up to the net amount that left) is owed to you again and can be requested again; the payout fee is not refunded, and a new payout carries its own fee. Fix the bank details before requesting again.

Creator Payouts

If your platform has creators, INVO pays them directly. You register each creator, INVO verifies them, and when you ask, INVO pays the creator's bank account as INVO's own payee, from the earnings INVO owes you. Players still never cash out: creator payouts come only from your owed balance, never from player balances.

What you do

  • • Register the creator: POST /api/partner-payees
  • • Watch payee.status_changed until the creator is verified
  • • Ask INVO to pay them: POST /api/partner-payouts/request with payee_id
  • • Watch payout.status_changed for the payment

What INVO does

  • • Emails the creator a link to INVO's own page, naming your company
  • • Collects and reviews the creator's identity, tax and bank details
  • • Pays the creator's verified bank account and emails them when it is sent
  • • Issues the creator's year-end tax form

Creators are INVO's customers, and INVO is responsible for their data. You never collect or see a creator's documents, tax id or bank details; you see their status and the details you registered. The account owner can do everything below in the INVO console (Payouts) as well as through the API. Creators are verified to the same standard INVO applies to developers, and creators outside the US can be paid.

Server only. Every call below uses your game secret key. Never put the key in a game client, a web page or a mobile app. INVO emails your account owner when a creator is registered with the key and when INVO verifies one, and the first payout to such a creator waits for the owner's confirmation in the console.

Register a creator: POST /api/partner-payees

Authenticate with X-Game-Secret-Key.

{
  "partner_reference": "creator-001",
  "legal_name": "Sam Creator",
  "email": "sam@example.com",
  "country": "GB",
  "payee_type": "individual"
}
  • • partner_reference: your own id for the creator, 1 to 128 characters from A-Z a-z 0-9 . _ : @ -, unique in your account. It comes back in webhooks, so don't use personal data such as an email address.
  • • legal_name: the creator's legal name, or the registered business name.
  • • country: an ISO 3166-1 alpha-2 code; a country under comprehensive sanctions returns 400 COUNTRY_NOT_SUPPORTED. payee_type: individual or business.

201 returns {success, payee, invite} with status: "invited". invite is {sent: true, expires_at}, or {sent: false, error_code, error} when INVO did not email the link; the creator is registered either way. ACCOUNT_NOT_VERIFIED there means INVO emails creators once your company verification is complete: resend the invite then. Sending the same partner_reference with the same details returns 200 with duplicate: true; with different details, 409 PARTNER_REFERENCE_CONFLICT. A game with no owner account returns 403 GAME_HAS_NO_OWNER.

payee_id is an opaque string starting cp_; store it as a string. The payee always shows the legal_name, email, country and payee_type you registered, and erased: true once the creator's details were erased (such a creator can't be invited or paid). payable is true when nothing on INVO's side stops a payout right now, and payable_blockers lists why not when it is false: erased, closed, not_verified, verification_expired, terms_not_accepted, bank_not_verified or not_payable_now (no action is needed from you; try again later). A game's key reads only the creators registered through that game; the console shows every creator on the account.

  • • GET /api/partner-payees: this game's creators, newest first (limit, offset, status).
  • • GET /api/partner-payees/{payee_id}: one creator.
  • • POST /api/partner-payees/{payee_id}/resend-invite: email the creator a new link (the old one stops working). Links last 14 days. Allowed while the creator is invited, rejected or expired; otherwise 409 INVITE_NOT_NEEDED. 409 PAYEE_ERASED for an erased creator, and 429 INVITE_RATE_LIMITED with retry_after_seconds when invites are sent too often. If INVO asked the creator to update their details, a resend sends INVO's update notice again, with its reason.
  • • POST /api/partner-payees/{payee_id}/remove: remove a creator from your program. The status becomes closed and INVO tells the creator. Refused with 409 PAYEE_HAS_PAYOUTS_IN_FLIGHT while a payout to them is still being processed (payouts_in_flight_by_status counts them by status). A requested payout can be cancelled; otherwise wait until it completes, fails or is declined. Removing is not a block: you can register the same person again under a new partner_reference.

In sandbox, invites go only to the account owner's or a team member's address, so register a test creator with one of those to try the page.

Creator statuses

  • • invited: registered; INVO has emailed the creator a link.
  • • details_submitted: the creator has sent their details; INVO is reviewing them.
  • • verified: INVO has verified the creator and their bank account. Only a verified creator can be paid.
  • • rejected: INVO asked the creator to correct or update something, and emailed them what to change.
  • • suspended: INVO has stopped payouts to this creator. Final.
  • • expired: the verification is more than a year old; INVO has emailed the creator to verify again.
  • • closed: the creator is no longer in your program (you removed them, or they asked INVO to close their record).

INVO tells the creator the outcome itself and does not share the reason with you. payee.status_changed fires when a creator is registered and on every status change, and never carries the creator's name or email.

Pay a creator

Send the payout request with payee_id instead of a bank account:

POST /api/partner-payouts/request
X-Game-Secret-Key: <the key of the game the creator was registered through>

{
  "amount_usd": "250.00",
  "contact_email": "ops@example.com",
  "payee_id": "cp_3f9a1c2b7d4e5f60718293a4",
  "client_request_id": "<uuid>",
  "partner_note": "October revenue share"
}
  • • The money comes from the earnings INVO owes your game, with the same 400 INSUFFICIENT_OWED_BALANCE check as a payout to your own bank.
  • • The payout fee (1% of the payout, capped at $500 per payout, unless your agreement says otherwise) is taken from the payout. The creator receives net_payout_usd.
  • • Send exactly one of payee_id or a bank destination; both together return 400 PAYEE_DESTINATION_FIXED. On a creator payout bank_account is null.
  • • amount_usd is in USD with at most two decimal places. A creator whose bank account is in another currency receives USD, converted by their bank.
  • • The same client_request_id with the same amount and creator returns the original payout; with a different amount or creator, 409 IDEMPOTENCY_KEY_REUSED.
  • • The first payout to a creator registered with the game key has owner_confirmation_required: true. INVO approves it only after your account owner confirms it in the console.

Refusals:

  • • 404 PAYEE_NOT_FOUND: not a creator of this game.
  • • 409 PAYEE_NOT_VERIFIED: the creator is not verified right now. Check their status: they may still be finishing, or INVO may be reviewing them.
  • • 409 PAYEE_VERIFICATION_EXPIRED, 409 PAYEE_BANK_NOT_VERIFIED: INVO has asked the creator to verify again or to add a bank account.
  • • 409 PAYEE_CLOSED: the creator is no longer in your program.
  • • 409 PAYEE_TERMS_NOT_ACCEPTED: the creator hasn't accepted INVO's current Payee Terms yet. INVO asks them to on their next visit.
  • • 409 PAYEE_NOT_PAYABLE: the creator can't be paid right now. No action is needed from you or the creator; try again later.

INVO emails your account owner about every creator payout request. A creator payout still in requested can be cancelled with POST /api/partner-payouts/{payout_id}/cancel: its status becomes cancelled and the money is free again at once. Anything past requested returns 409 PAYOUT_NOT_CANCELLABLE, and a payout to your own bank returns 404 NOT_FOUND. If INVO stops paying a creator, it declines their payouts that have not started to leave INVO, and the money is free again.

GET /api/partner-payouts?payee_id=cp_... lists one creator's payouts. payout.status_changed carries payee_id (null for a payout to your own bank) and never carries the creator's bank or personal details. partner_message is a note INVO wrote for you, when there is one.

If the creator's bank sends the payment back, the payout moves to returned with return_reason_code: "returned": what the bank sent back is owed to your game again and the payout fee is not refunded. INVO contacts the creator about a new bank account; until it is verified, payouts to them are refused.

INVO issues each creator's year-end tax form. A creator payout is not counted as your own income on your INVO earnings statement.

What's the same as the gaming-tier API

Partners use the same REST API that gaming-tier developers use:

  • Same auth. Single X-Game-Secret-Key header on every server-to-server call.
  • Same hosted checkout. Mint a session, open the URL, listen for the webhook.
  • Same item-purchase flow. POST /api/item-purchases/purchase-item with idempotency-keyed bodies.
  • Same balance reads. Single, batch, and streaming reconciliation endpoints.
  • Same webhook envelope. HMAC signature, retry policy, de-duplication on X-Invo-Idempotency-Key.

The technical pages on this site (Authentication, Currency Purchase, Item Purchase, Player Balance) all apply directly. What's different for partners is the business agreement, the branded-currency setup, and the payout flow described above.

Talk to us

Partner onboarding starts with a conversation. Tell us what you're building, the volume you expect, and what shape you'd want the integration to take.

partners@invo.network