Adyen User Management Guide

• Model type: role-based
• Description: Adyen uses role-based access control (RBAC). Each user is assigned one or more predefined roles that determine what they can view and do in the Customer Area (e.g., look up payments, configure risk settings, download financial reports). Admins can only assign roles they themselves hold; roles outside the admin's own set require a support request to Adyen. Roles are also scoped to specific merchant accounts.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Role-level granularity across functional categories: account management, payments, POS, payment links, partner permissions, balance platform, risk and disputes, donations, and PII access. No custom role builder; all roles are predefined by Adyen.

1. Log in to the Customer Area.
2. Go to Settings > Users.
3. Select 'Create new user'.
4. Enter the username and email address for the new user.
5. Choose the login method: Email and password, Username & account, or SSO (SSO must be pre-configured).
6. Select which merchant accounts the user can access (all or specific accounts).
7. Assign one or more roles to the user.
8. Review the summary and select 'Create new user'.
9. The new user receives an email with a verification link (valid for 14 days) to verify their email, set a password, and configure MFA.

Required fields: Username, Email address, Login method (Email and password, Username & account, or SSO), Merchant account access selection, At least one role assignment

Watch out for:

• The verification link sent to new users is only valid for 14 days; if it expires, the admin must resend the verification email.
• Admins can only assign roles they themselves already hold. Roles outside the admin's set require a support ticket to Adyen.
• SSO login method requires SSO to be fully configured in the Customer Area before user creation.
• For SSO users, the person must already have an account with the organization's identity provider.
• Users must verify their email separately for the test Customer Area and the live Customer Area.
• For security reasons, no users or roles can be added over the phone.
• Duplicating a user may result in fewer permissions than the source user if the admin does not hold all of the source user's roles.

• Can delete users: Yes
• Delete/deactivate behavior: Adyen supports both deactivation and deletion of users. Deactivation (setting a user to inactive) revokes Customer Area access and terminates the active session immediately, but the user record is retained and can be reactivated. Deletion is also documented as an available admin action. Deactivation is the recommended approach when an employee leaves, as it preserves the audit trail and allows reactivation if needed.

1. Log in to the Customer Area.
2. Go to Settings > Users.
3. Select the user from the User List.
4. On the User details page, select 'Deactivate user'.
5. Confirm by selecting 'Deactivate' in the pop-up window.
6. The user's session is immediately terminated and they can no longer access the Customer Area.

Watch out for:

• An admin cannot deactivate the user account they are currently logged in with.
• Deactivated users can be reactivated at any time by an admin via Settings > Users, filtering by Inactive status.
• SSO-managed users: when an employee leaves, access can also be removed through the SSO/IdP solution, which will block Customer Area access via SSO. However, the Customer Area user record itself must still be deactivated manually unless SCIM deprovisioning is configured (Okta only).
• API credentials associated with a departed user must be separately deactivated under Developers > API credentials to prevent continued programmatic access.

• Where to check usage: Customer Area > Settings > Users (view all users and their status). Download the 'Users within a company' report for a full list of users, their roles, and last login timestamp.
• How to identify unused seats: Download the 'Users within a company' report from the Customer Area. The report includes the last login date for each user, enabling identification of accounts that have not been used recently.
• Billing notes: Adyen has no monthly fees, setup fees, integration fees, or per-seat user fees. All costs are transaction-based (Interchange++ model: interchange fee + scheme fee + Adyen processing fee per transaction). A minimum invoice may apply depending on industry or business model; details require contacting Adyen sales. Chargeback fees and payout fees are not publicly listed and must be obtained directly from Adyen.

Adyen charges no per-seat or per-user fees - all costs are transaction-based - so there is no direct financial penalty for orphaned accounts. The operational cost is access risk: departed employees or unused API credentials retain access until manually deactivated.

Admins must separately deactivate web service users under Developers > API credentials; the Settings > Users path does not surface them. Identifying stale accounts requires downloading the 'Users within a company' report, which includes last login timestamps, and then acting on each record individually. This manual reconciliation cycle must be repeated on every offboarding event.

Practitioners consistently flag two friction points with Adyen's access model.

First, the role-assignment ceiling: admins cannot grant roles they do not themselves hold, so onboarding a user who needs an unfamiliar role requires a support ticket to Adyen - a delay that compounds during bulk onboarding.

Second, the SCIM gap: SCIM provisioning works only through Okta; organizations using Azure Entra ID, Google Workspace, or OneLogin have no automated deprovisioning path despite Adyen supporting SAML SSO.

A secondary compliance concern is the requirement to maintain at least one non-SSO admin account for emergency access, which auditors may flag as a standing backdoor. Verification links for new users expire after 14 days, requiring admin follow-up if a user misses the window.

Common complaints:

• Complex initial setup requirements; integration can take longer than expected due to paperwork and compliance requirements.
• Admins must maintain at least one non-SSO admin account for troubleshooting, creating a security backdoor that compliance auditors may flag.
• Chargeback fees and payout fees are not publicly available; must be negotiated directly with Adyen.
• SCIM provisioning is only available via Okta integration; teams using Azure Entra, Google Workspace, or OneLogin are left with fully manual user management despite SAML SSO support.
• Admins cannot assign roles they do not themselves hold; obtaining new roles requires submitting a support ticket to Adyen, which can delay onboarding.
• New user verification links expire after 14 days; if a user does not complete verification in time, the admin must manually resend the email.
• Users must verify their email address separately for the test and live Customer Area environments, doubling the onboarding effort.
• Support is primarily email/ticket-based; some users report difficulty getting timely resolution for urgent issues.
• Some users report monthly charges even when the payment gateway is inactive.

Representative quotes (verbatim):

Adyen offers SCIM 2.0 provisioning, but only through Okta's integration-there's no native SCIM endpoint.

• Stitchflow SCIM & Provisioning Directory (third-party research) (https://www.stitchflow.com/scim)

Teams using Azure Entra, Google Workspace, or OneLogin are left with manual user management despite Adyen supporting SAML SSO.

• Stitchflow SCIM & Provisioning Directory (third-party research) (https://www.stitchflow.com/scim)

Adyen's chargeback fees or payout fees are not publicly available.

• Noda.live Adyen fees analysis (https://noda.live/articles/adyen-fees)

Manual management is the only option for most Adyen customers, and for every app in a stack where SCIM is unavailable the offboarding burden compounds. SCIM-based automation is gated behind an Okta-specific integration; no other IdP is supported for automated provisioning or deprovisioning.

Teams that can tolerate the Okta dependency and are on an Enterprise agreement should evaluate that path for offboarding reliability.

Everyone else should establish a documented offboarding checklist that covers both Settings > Users and Developers > API credentials, since the two surfaces are independent and a deactivated UI user does not automatically revoke their associated API credentials.

Bottom line

Adyen's user management is functional but manually intensive for most teams.

The predefined RBAC model is straightforward once roles are understood, but the inability to assign roles outside an admin's own set, the absence of a native SCIM endpoint for non-Okta IdPs, and the need to manage API credentials on a separate screen all create compounding overhead at scale.

There are no per-user costs to optimize, but the access-risk exposure from ungoverned offboarding is real - particularly for API credentials, which remain active independently of the associated human user account unless explicitly deactivated.