Stripe User Management Guide

• Model type: role-based
• Description: Stripe uses a fixed set of predefined roles assigned per team member per account. There are no custom roles or granular permission toggles available in the standard Dashboard. For SSO-enabled enterprise accounts, roles can be assigned via SAML attribute statements in the identity provider, but the role set itself remains fixed.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level only; no per-resource or per-feature permission toggles. Role scope is account-wide; there is no object-level or workspace-level permission scoping within a single Stripe account.

1. Log in to the Stripe Dashboard as an Administrator or Owner.
2. Navigate to Settings → Team and security (https://dashboard.stripe.com/settings/team).
3. Click 'Invite team member'.
4. Enter the invitee's email address.
5. Select the appropriate role from the dropdown (Administrator, Developer, Analyst, Support Specialist, View Only).
6. Click 'Send invitation'.
7. The invitee receives an email and must accept the invitation to gain access. If they do not have a Stripe account, they will be prompted to create one.

Required fields: Email address, Role selection

Watch out for:

• Invitations expire if not accepted; a new invitation must be sent if the original expires.
• The invitee must create or log in to a personal Stripe account to accept the invitation; Stripe does not support shared credentials.
• A team member's access is tied to their personal Stripe account email, not a corporate directory entry, unless SSO is configured.
• For accounts with SSO enabled, new members may be provisioned automatically via SCIM (private preview / enterprise), but roles must still be assigned via SAML attribute statements in the IdP.
• There is no bulk CSV import for team members; invitations must be sent individually.

• Can delete users: Yes
• Delete/deactivate behavior: Stripe allows removing (revoking) a team member's access to an account. This removes their access to that specific Stripe account but does not delete their personal Stripe account. The action is labeled 'Remove' in the Dashboard. There is no separate 'deactivate' state; removal is immediate and permanent for that account's access.

1. Log in to the Stripe Dashboard as an Administrator or Owner.
2. Navigate to Settings → Team and security (https://dashboard.stripe.com/settings/team).
3. Locate the team member in the list.
4. Click the overflow menu (three dots) or 'Edit' next to their name.
5. Select 'Remove member' (or equivalent removal option).
6. Confirm the removal. Access is revoked immediately for Dashboard login.
7. If the removed user had API keys associated with their access, rotate or revoke those API keys separately under Developers → API keys.

Watch out for:

• API keys are not invalidated automatically upon team member removal. Failure to rotate API keys after removing a developer-role user is a significant security risk.
• For SSO-enabled accounts, deprovisioning in the IdP (e.g., Okta) removes Dashboard SSO access, but if the user has a direct Stripe login (non-SSO), that access may persist unless the account enforces SSO-only login.
• SCIM deprovisioning (where available) handles account suspension but role management remains tied to SAML attributes; verify both IdP deprovisioning and SAML attribute removal.
• There is no audit log export directly from the team management UI; use the Stripe Dashboard event log or API to audit access history.
• Removing a team member does not notify them; communication must be handled separately.

• Where to check usage: Settings → Team and security (https://dashboard.stripe.com/settings/team) - lists all active team members and their roles.
• How to identify unused seats: No built-in 'last login' or activity timestamp is displayed in the Team settings UI. Administrators must cross-reference the Dashboard event log or use the Stripe API to identify inactive members. There is no automated unused-seat detection.
• Billing notes: Stripe does not charge per team member seat. Adding or removing users has no direct billing impact. Costs are driven entirely by payment processing volume and any add-on products (Radar, Billing, etc.).

Stripe does not charge per team member seat; adding or removing users has no direct billing impact. Costs are driven entirely by payment processing volume and any add-on products. The absence of granular permissions means roles broader than strictly necessary must be assigned when a narrower scope would suffice.

There is no bulk invitation or CSV import; every team member must be invited individually. There is also no last-login or activity timestamp in the Team settings UI, so identifying and cleaning up inactive accounts requires cross-referencing the Dashboard event log or querying the API separately.

The most consistent friction reported by Stripe teams centers on three gaps: the fixed role set forces over-provisioning when a narrower scope is needed; API keys are not automatically revoked on team member removal, creating a security gap that requires a deliberate separate step; and role management is decoupled from SCIM, requiring SAML attribute configuration in the IdP on top of provisioning setup.

SSO enforcement and SCIM access are gated behind an enterprise agreement, which is not accessible on self-serve plans. Teams that need audit visibility are also limited - there is no last-login display in the Team UI, and no audit log export directly from team management.

Common complaints:

• No custom roles or granular permissions; users must be given broader access than needed because the fixed role set does not allow fine-grained scoping.
• API keys are not automatically revoked when a team member is removed, creating a security gap that requires a separate manual step.
• No bulk invitation or CSV import for team members; large teams must be invited one at a time.
• No 'last login' or activity visibility in the Team settings UI, making it difficult to identify and clean up inactive accounts.
• Role management is separate from SCIM provisioning; roles must be assigned via SAML attribute statements in the IdP, not through SCIM, adding IdP configuration complexity.
• SSO enforcement and SCIM provisioning require an enterprise agreement, which is not available on self-serve plans.
• Delayed or incomplete access revocation when relying solely on IdP deprovisioning if SSO-only login is not strictly enforced on the Stripe account.
• No native support for Google Workspace or OneLogin SSO/SCIM; only Okta and Entra (Azure AD) are documented as supported IdPs.

Stripe's manual team management is straightforward for small teams: invite by email, assign a role, remove when done. The process breaks down at scale or in security-sensitive environments, because every app connected via a Developer-role holder carries residual API key risk after that person is removed - key rotation is a manual, non-negotiable offboarding step.

If your organization requires SSO enforcement, automated provisioning, or deprovisioning guarantees, an enterprise agreement is a prerequisite - not an upgrade option. Teams operating on standard plans should accept that role granularity will not improve without a plan change and should treat API key rotation as a mandatory control.

Bottom line

Stripe's team access model is functional for small, trusted teams but shows clear limits as headcount or compliance requirements grow.

Every app that connects via a Developer-role holder carries residual API key risk after that person is removed - key rotation is a manual, non-negotiable step. The fixed role set, lack of last-login visibility, and one-at-a-time invitation flow add operational overhead that compounds at scale.

SCIM and SSO enforcement are available but require an enterprise agreement and IdP configuration that goes beyond what SCIM alone handles, since roles must be set via SAML attribute statements separately.