Scopes and invites

A payee invite asks the recipient to sign in with a specified identity and grant your organization access to the information requested in the invite, such as profile details or tax forms. That request is expressed in scopes — named permissions over the payee’s verified data. The payee sees what is being requested and grants it by accepting the invite. Your organization gets exactly what it asked for, nothing more.

​

What a scope is

A scope names one piece of access, in the form read:resource or write:resource — for example, read:kyc grants read access to a payee’s verified name and address. Scopes are granular on purpose: paying someone should not mean seeing everything about them.

​

Default invite scopes

Every payee invite requests a baseline your organization needs to pay someone compliantly: An invite also requests read access to the payee’s wallet on the rail the payout settles on, so the payout can reach them.

​

Additional scopes

Beyond the defaults, an invite can request more, grouped by category:

• User — business profiles linked to the payee
• Wallets — the payee’s wallet details
• Social — the payee’s GitHub, X, Telegram, or Discord handle
• Invoices — reading and creating invoices between you and the payee

Request only the additional data your workflow needs. The payee sees these permissions when deciding whether to accept the invite.

​

Consent, enforced

Pvium checks the permissions granted by the payee before returning their data:

• The payee grants scopes explicitly when accepting the invite. Nothing is shared before acceptance.
• Every API and dashboard request that touches payee data is checked against the granted scopes. A request without the required scope is rejected, regardless of who makes it.
• The same scope model governs API keys and OAuth apps, so a key or app scoped to read payout data cannot reach payee KYC or tax records unless that access was granted.

​

When an invite becomes active

Accepting an invite records consent, but it does not always make the authorization active immediately. If the requested scopes require payee screening, the authorization remains pending until those checks complete. The oauth.authorization.activated webhook marks the transition to active after the required onboarding checks for the invite scopes have passed. An active authorization is not the same as batch payability. For Strict payouts, use the batch-scoped isPayable SDK method before adding recipients or finalizing. It reports blockers such as missing scopes, tax forms, or an authorized wallet for that batch’s chain.

​

Invites are bound to the payout

Each invite is cryptographically tied to the payout batch it belongs to and to the invited identity. An invite cannot be redeemed against a different payout, and it cannot be claimed by anyone who cannot authenticate as the invited identity — see Identity for how that proof works.

​

Related pages