PayPal User Management Guide

• Model type: permission-sets
• Description: PayPal Business accounts use a permission-set model. When adding a secondary user, the primary account holder or an Admin selects from a fixed list of granular permissions (e.g., view transactions, process payments, issue refunds, manage disputes, access reports). There are no saveable named role templates; each user's permissions are configured individually.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Per-user permission toggles selected from a fixed list of approximately 10–15 predefined capabilities. No field-level or object-level granularity beyond the predefined options.

1. Log in to the PayPal Business account as the primary account holder or an Admin.
2. Click the Settings gear icon in the top-right corner.
3. Select 'Account Settings'.
4. Navigate to 'Account Access' in the left-hand menu.
5. Click 'Manage Users' next to the 'Manage Users' row.
6. Click 'Add User'.
7. Enter the new user's first name, last name, and email address.
8. Create a username for the new user (must be unique within the account).
9. Set a temporary password for the new user.
10. Select the permissions to grant from the available list.
11. Click 'Save' to create the user.

Required fields: First name, Last name, Email address, Username (unique sub-account login), Temporary password, At least one permission selected

Watch out for:

• The new user receives a separate username/password credential, not an invitation to link their own PayPal account. They log in using the business account's email plus their assigned username.
• The email address entered is for identification purposes; the user does not receive an automated invitation email in all cases - the primary holder must share credentials manually.
• Usernames cannot be changed after creation.
• There is no bulk CSV import for secondary users on standard PayPal Business accounts.
• The maximum number of secondary users per account may be limited; PayPal documentation does not publish a hard cap but community reports suggest limits exist.
• SCIM-based provisioning is only available for Enterprise Braintree accounts and is irreversible once enabled.

• Can delete users: Yes
• Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.

1. Log in as the primary account holder or an Admin.
2. Go to Settings → Account Settings → Account Access → Manage Users.
3. Locate the user in the list.
4. To deactivate: click 'Edit' next to the user, then toggle the user's status to inactive/deactivate and save.
5. To remove permanently: click 'Remove' (or 'Delete') next to the user and confirm the action.

Watch out for:

• Removing a user is immediate and cannot be undone; the username cannot be reused.
• If the removed user had API access configured, those integrations must be reconfigured under a different user or the primary account.
• Deactivated users retain their username slot; reactivation restores prior permissions.
• The primary account holder cannot be deactivated or removed through the UI.

• Where to check usage: Settings → Account Settings → Account Access → Manage Users (lists all active and inactive secondary users).
• How to identify unused seats: Review the user list in Manage Users for accounts with no recent login activity. PayPal does not provide a native 'last login' timestamp in the standard UI; unused accounts must be identified by manually reviewing activity logs or contacting PayPal support.
• Billing notes: Secondary users on standard PayPal Business accounts do not incur per-seat fees. All costs are transaction-based. Enterprise Braintree pricing is custom and negotiated; SCIM/SSO features are included at that tier.

Secondary users on standard PayPal Business accounts carry no per-seat fee. All account costs are transaction-based, so adding or removing users has no direct billing impact.

The real cost is operational. There is no bulk import, no role template to reuse, and no native last-login timestamp in the Manage Users UI - meaning every app that needs access requires individual setup, and identifying inactive accounts requires manually cross-referencing activity logs.

Usernames cannot be changed after creation, and removed users leave a permanent gap in the username namespace. Admins can add or remove other secondary users, which creates privilege escalation risk if access reviews are not run regularly.

Practitioners consistently flag three friction points with PayPal's user management. First, the absence of role templates means permissions must be rebuilt from scratch for every new user - a significant time sink at scale.

Second, there is no bulk import path on standard Business accounts, so onboarding a team means clicking through the same form repeatedly.

Third, the lack of last-login visibility in the Manage Users UI makes access hygiene difficult. Identifying stale accounts requires either manual log review or a support request to PayPal.

The SCIM irreversibility issue is a recurring concern in enterprise discussions: once enabled on a Braintree account, there is no documented rollback path, and all future provisioning must flow through the IdP.

Common complaints:

• SCIM provisioning is irreversible once enabled on Braintree Enterprise accounts - there is no documented rollback path.
• No bulk import option for secondary users on standard Business accounts; each user must be added individually.
• No saveable role templates - permissions must be reconfigured from scratch for every new user.
• Usernames assigned to secondary users cannot be changed after creation.
• No native 'last login' visibility in the Manage Users UI, making it difficult to identify inactive accounts.
• Secondary users log in with a shared business account email plus a unique username, which causes confusion and is not compatible with standard SSO flows on non-Enterprise plans.
• Group management is not available on standard Business accounts; permission assignment is strictly per-user.
• Complex onboarding requirements for Enterprise/Braintree SCIM setup, including mandatory SSO prerequisite.
• Community reports suggest an undocumented cap on the number of secondary users per account.

Manual provisioning is workable for small, stable teams where transaction volume is low and user turnover is infrequent. The permission-set model gives reasonable granularity for finance and operations roles without requiring enterprise infrastructure.

For organizations managing every app through a centralized IdP, or those with frequent onboarding and offboarding cycles, the manual path becomes a liability. No bulk import, no role templates, and no last-login data mean access reviews are slow and error-prone.

Enterprise Braintree with SCIM resolves the provisioning gap but introduces an irreversible commitment. Evaluate that tradeoff carefully before enabling SCIM in production - there is no undo.

Bottom line

PayPal Business's manual user management is functional for small teams but does not scale cleanly. The permission-set model is granular enough for most finance and operations use cases, but the absence of role templates, bulk import, and last-login visibility creates compounding overhead as headcount grows.

Every app in a modern SaaS stack benefits from lifecycle automation; PayPal's standard tier offers none of it. Teams that need automated provisioning must commit to Enterprise Braintree and accept that enabling SCIM is a one-way door.