Skip to main content

Overview

PCX uses a two-tier access control model:
  1. Platform type — set on the user record. Determines platform-level access.
  2. Org member role — set on the OrgMember record. Determines what a user can do within a specific organization.
Fine-grained permissions can be layered on top of org member roles to grant specific resource-level actions.

Platform type (UserType)

Every user has a type field with one of two values:
TypeDescription
internal-adminFull platform access. Can manage all organizations, approve payments, update KYB, access all analytics, and perform all administrative operations across every org.
userStandard user. Access within an organization is determined by their OrgMember role.

Org member role

When a user is added to an organization they receive an OrgMember record with a role that governs their capabilities within that org:
Org member roleCapabilities
adminFull management of the organization — members, invites, payments, rate configs, permissions
staffRead access to org resources. Cannot make changes.
userEnd-user within the org. Can manage their own data and interact with org features they have been granted access to.
A user can be a member of multiple organizations simultaneously, each with a different role:
User (type: user)
  ├── OrgMember in Org A (role: admin)
  └── OrgMember in Org B (role: user)

Fine-grained permissions

Beyond roles, org admins and internal admins can grant specific permissions to individual members on a per-resource basis. This allows access to be scoped precisely without elevating the member’s overall role.

Permission structure

{
  "resource": "payment_orchestration",
  "actions": ["READ", "CREATE", "UPDATE"],
  "constraints": {}
}
FieldDescription
resourceFeature key (e.g. payment_orchestration, virtual_accounts)
actionsOne or more of READ, CREATE, UPDATE
constraintsOptional object for resource-level restrictions

Managing permissions

OperationEndpoint
Grant permission to a memberPOST /organizations/{org_id}/members/{user_id}/permissions
Get member’s permissionsGET /organizations/{org_id}/members/{user_id}/permissions
Update a permissionPUT /organizations/{org_id}/members/{user_id}/permissions/{resource}
Revoke a permissionDELETE /organizations/{org_id}/members/{user_id}/permissions/{resource}
Batch update all member permissionsPUT /organizations/admin/organizations/{org_id}/members/permissions
Check if a user has a permissionGET /organizations/permissions/check?user_id=&resource=&action=&org_id=

Available features

The full list of grantable features is defined in the Organizations service and can be retrieved dynamically:
GET /v1/organizations/features
GET /v1/organizations/features/{feature_key}

Permission check

Services check permissions programmatically before performing sensitive operations:
GET /v1/organizations/permissions/check \
  ?user_id=user_abc \
  &resource=payment_orchestration \
  &action=CREATE \
  &org_id=org_xyz
Response:
{
  "user_id": "user_abc",
  "resource": "payment_orchestration",
  "action": "CREATE",
  "org_id": "org_xyz",
  "allowed": true
}

Combined user + member permissions

To retrieve both the user record and their member permissions in one call (useful for admin dashboards):
GET /organizations/admin/users/{user_id}/member-permissions
Requires internal-admin type.