> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Adyen

> Connect Adyen to Oleria to bring Customer Area users, their roles, and API credentials with their keys and certificates from your payments platform into your identity and access graph.

Connect Adyen to Oleria to see who can sign in to your Adyen Customer Area, with which roles, and which API credentials can call Adyen on your company's behalf. Oleria reads users and API credentials from the Adyen Management API using the API key of a company-level API credential. You can review access to your payments platform and take action directly from Oleria.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Adyen company account:

* **Accounts** - every Customer Area user, whether they were created on the company account or on one of its merchant accounts. A user listed at both levels appears once. Oleria imports each user's name, email address, username, and roles. Active users are enabled. Deactivated users are imported as disabled. Users with the **Merchant admin**, **Merchant user management**, **Manage API credentials**, **Balance platform admin role**, **Partner admin**, or **Manage partner users** role are marked as administrators. Oleria also records the merchant accounts and account groups each user can access.
* **Non-human identities (NHIs)** - every API credential (web service user) on the company account and on each merchant account, imported as a service account. Oleria imports each credential's username, description, status, and roles. It also records the allowed IP addresses, the allowed origins, and the merchant accounts the credential can access. A company-level credential that isn't restricted to specific merchant accounts is marked as having access to all of them. Credentials with the **Management API—Users read and write** or **Management API—API credentials read and write** role are marked as administrators, because they can change users or other credentials. The credential this integration uses is marked as the connection's own credential.
* **Secrets** - the credentials that belong to each API credential, each linked to the API credential it authenticates:
  * **API key** - one per API credential. It's active while the API credential is active. Its scope is the credential's roles and the merchant accounts it can access.
  * **Client key** - when the API credential has one, with the allowed origins it can be used from. A client key works only for client-side payments from those origins. Oleria doesn't store the key's value.
  * **Client certificates** - each certificate's subject, serial number, SHA-256 fingerprint, and expiration date. A certificate past its expiration date is marked as expired, and the certificates of a deactivated API credential are marked as disabled. A certificate that Oleria can't match to an API credential is imported without a link to one. Importing certificates needs the optional [**Management API - Client certificates read**](#required-roles) role.
* **Roles** - every role held by at least one user or API credential. Customer Area user roles and API credential roles are imported separately, so a user role can't be confused with an API credential role of the same name. Oleria also maps which accounts hold which roles.

Adyen requires every Customer Area user to set up multi-factor authentication or single sign-on, so Oleria marks MFA as required for every user.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview#sync-model).

<Note>
  Oleria doesn't import merchant accounts, stores, payment terminals, payment data, or balance platform objects. This integration covers identity and access governance for Customer Area users, API credentials, and their roles. Adyen's Management API doesn't provide an audit log or last sign-in dates, so this integration has no activity data.
</Note>

## Prerequisites

* A user in your Adyen Customer Area who can create API credentials and assign their roles.
* A company-level API credential with access to all merchant accounts. Merchant-level credentials aren't supported. We recommend a credential dedicated to Oleria, not the one your payment integration uses.
* Admin access to the Oleria workspace.

### Required roles

Give the API credential these roles:

| Adyen API credential role | Needed for |
| :- | :- |
| **Management API—Account read** | Required. Reads your company account and lists its merchant accounts, so Oleria can find merchant-level users and API credentials. |
| **Management API—Users read and write** | Required. Imports Customer Area users. Also covers the user [remediation actions](#remediation-actions). |
| **Management API—API credentials read and write** | Required. Imports API credentials and their keys. Also covers disabling an API credential and changing its roles. |
| **Management API - Client certificates read** | Optional. Imports client certificates. Without it, Oleria imports everything else and skips client certificates. |

<Warning>
  Adyen has no read-only role for users or API credentials. The roles Oleria needs to read them also allow changes, so treat the API key as an admin credential. Don't give the credential payment roles. Oleria doesn't need them.
</Warning>

If a role isn't offered when you edit the credential, ask Adyen Support to enable it for your company account.

## Create an API credential in Adyen

<Steps>
  <Step title="Create a company-level API credential">
    Sign in to the Adyen Customer Area for the environment you want to connect: live, or test for a test account. Go to **Developers** -> **API credentials** and create an API credential on your company account, dedicated to Oleria.
  </Step>

  <Step title="Assign the roles">
    Give the credential the roles listed in [Required roles](#required-roles). Leave the credential's merchant account access unrestricted, so Oleria can read the users and API credentials of every merchant account.
  </Step>

  <Step title="Allow Oleria's IP addresses">
    If the credential restricts its allowed IP addresses, add Oleria's IP addresses. Contact [support@oleria.com](mailto:support@oleria.com) for the current list.
  </Step>

  <Step title="Generate and copy the API key">
    On the credential's page, under **Server settings** -> **Authentication**, generate an API key. Copy it and store it securely.
  </Step>

  <Step title="Note your company account ID">
    Note your company account ID, for example `YourCompanyECOM`. You need it only if the API key can see more than one company account.
  </Step>
</Steps>

<Note>
  Adyen's live and test environments are separate Customer Areas with separate API keys. Create the credential in the environment you want Oleria to read. The exact location of these settings can change over time. If the steps above don't match what you see, refer to Adyen's own documentation.
</Note>

## Connect Adyen to Oleria

<Steps>
  <Step title="Open the integration">
    Go to your Oleria workspace, select **Integrations** -> select **Adyen**.
  </Step>

  <Step title="Complete the connection form">
    Select **Continue** and provide the following:

    | Field | Notes |
    | :- | :- |
    | Environment | Required. **Live** or **Test**, matching the Customer Area the API credential belongs to. Defaults to **Live**. |
    | API key | Required. The API key you generated for the company-level API credential. |
    | Company account ID | Optional. Leave it blank to use the only company account the API key can see. Enter it if the key can see more than one company account. |
  </Step>

  <Step title="Confirm the connection">
    Select **Authenticate** to validate the API key. Oleria checks that the API credential is active, finds your company account, and lists one user and one API credential from it. If a required role is missing, the error names it. Find the newly connected company account on the **Connected** tab of your Oleria **Integrations** page.
  </Step>
</Steps>

If **Authenticate** fails, check that:

* The **Environment** matches the Customer Area where you created the API credential.
* The API credential is active and is a company-level credential.
* The credential has the three required roles.
* The credential's allowed IP addresses include Oleria's, if it restricts them.
* You entered the **Company account ID** if the key can see more than one company account.

<Note>
  Each integration covers one Adyen company account in one environment. To connect another company account, or the other environment, add a new integration.
</Note>

## Verify the integration

Confirm the Adyen company account appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered accounts, non-human identities, secrets, and roles in your Oleria workspace.

<Note>
  If you generate a new API key in Adyen, edit the integration in Oleria, paste the new key, and select **Update**. To keep the stored key when you edit the integration, leave the **API key** field empty. You can't change the **Environment** or **Company account ID** of an existing integration, and Oleria rejects a key that belongs to a different company account.
</Note>

## Remediation actions

Oleria can take these actions in Adyen. The three required roles in [Required roles](#required-roles) cover all of them. Oleria checks that the API credential holds the roles an action needs, and names any role that's missing.

| Action | What it does | Revert |
| :- | :- | :- |
| Create user | Creates a Customer Area user on the company account, with the email address as the username and a first and last name. Oleria doesn't assign roles. Grant them afterwards with the add role action. If a company-level user with that email address already exists, Oleria leaves it unchanged. | Deactivates the created user if it's still active. Adyen has no API to delete a user, so the user remains, deactivated. If the created user has since become the last active **Merchant admin**, the revert is skipped. |
| Deactivate user | Deactivates a Customer Area user on the company or merchant account they belong to. A deactivated user can no longer access the Customer Area. | Reactivates the user. |
| Reactivate user | Reactivates a deactivated Customer Area user. | Deactivates the user again. |
| Add role | Adds a role to a Customer Area user or an API credential. | Removes the role again. |
| Remove role | Removes a role from a Customer Area user or an API credential. | Adds the role back. |
| Disable NHI | Deactivates an API credential. Every key the credential holds stops working until it's reactivated: its API key, client key, password, and client certificate. | Reactivates the API credential. |

If a user, API credential, or role is already in the state an action asks for, the action succeeds without making a change, and there's nothing to revert. A revert changes only what the action changed. If the target was deleted or changed again since the action ran, the revert leaves it as it is.

Keep these limits in mind:

* Oleria won't disable the API credential this integration uses or change its roles. If Oleria can't confirm which credential that is, it refuses the action.
* Oleria won't remove the last role of an API credential, because Adyen requires at least one. Disable the credential with Disable NHI instead.
* Oleria won't deactivate the last active user with the **Merchant admin** role, or remove that role from them, so someone can always manage users. For a company-level user, only another active company-level Merchant admin counts. For a merchant-level user, Oleria checks every merchant account the user can access, and refuses if any of them would be left without another active Merchant admin who can reach it. A company-level Merchant admin counts for a merchant account only if their own access includes it. If Oleria can't read the users it needs for this check, it refuses the action.
* To disable an API credential, use Disable NHI. The deactivate user action refuses API credentials.
* User roles can be added only to users, and API credential roles only to API credentials.
* Adyen limits which roles can be granted. An API credential can be given only roles that your company's default `ws@Company.<CompanyName>` API credential holds, and a Customer Area user can be given only roles that the party granting them holds. If Adyen refuses a role, the action fails with Adyen's error. The same applies when reverting a role removal.
* Removing the **Merchant standard role** from a user stops them from signing in to the Customer Area.
* If an action targets a user or API credential that doesn't exist in the company account or its merchant accounts, the action fails.

## Known limitations

* **No activity or dormant account detection.** Adyen's Management API has no audit log, sign-in history, or last-used dates for users or API keys, so Oleria can't import activity or detect dormant accounts.
* **No groups.** Adyen has no user groups. Account groups group merchant accounts, not people, so Oleria records them as an attribute of each user.
* **No resources.** Merchant accounts, stores, and payment terminals aren't imported as resources. The merchant accounts each user and API credential can access are recorded as attributes.
* **One company account per integration.** A company-level API credential is required. Merchant-level credentials aren't supported.
* **Single sign-on and sign-in method are unavailable.** Adyen doesn't expose single sign-on settings or each user's sign-in method through its API, so these fields report as unavailable.
* **No creation dates or owners for API credentials.** Adyen's API doesn't report when a user or API credential was created, or who created a credential.
* **Some secrets aren't imported.** Adyen's API doesn't show whether an API credential has a password, so passwords aren't imported. Webhook credentials aren't imported either.
* **Roles without holders aren't imported.** Adyen has no API to list its roles, so Oleria imports only the roles that at least one user or API credential holds.
* **Missing roles stop the sync.** If the API credential loses one of the three required roles, the sync fails and names the missing role, rather than removing users or API credentials from Oleria. If the API credential can't read one merchant account's users or API credentials, for example because the credential is restricted to other merchant accounts, Oleria skips that merchant account and imports the rest. The skipped merchant account's users and API credentials aren't imported, and actions can't find them.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.