Classic-platform icon

Partner platform requirements

Onboard sub-merchants and add online stores so that they can process ecommerce transactions.

The content on this page only applies when you have a partner arrangement for Adyen for Platforms.

For information about platform integrations built after August 1, 2022, refer to our new integration guide instead.

On your partner platform, you cannot process payments on behalf of your sub-merchants. Instead, Adyen establishes a direct relationship between each sub-merchant and the card schemes.

For us to be able to establish that relationship, and for your sub-merchants to be able to process ecommerce transactions, we need you to:

  • Collect additional PCI DSS compliance documentation in the form of the Self-Assessment Questionnaire (SAQ A).
  • Create online stores for each sub-merchant to establish a direct connection between them and the schemes.

Sub-merchants that process point-of-sale (POS) transactions also need stores to be created for them. However, they don't have to complete the SAQ A. The connection between the card networks and each store is established through the POS terminals, as are the PCI DSS requirements. See Point of sale for platforms for more information.

This is an overview of the steps to take:

  1. Create an account holder for your sub-merchant.
  2. Onboard account holders and collect the SAQ A information.
  3. Add a store for the account holder.
  4. Add allowed origins for sub-merchants that use their own domains.
  5. Route payments to the account holder's store.

Before you begin

Before you start with your integration, you must:

  • Be familiar with the features of Adyen for Platforms, such as the account structure, the onboarding and verification process, and notifications. The only differences for partner platforms are:
    • While onboarding, you have to gather the additional PCI compliance data in the form of the SAQ A.
    • You have to create an online store for each account holder on the platform.
  • Contact our Support Team and provide the following required information.
    • Countries
    • Currencies
    • Merchant category codes (MCCs)
    • Payment methods

You can specify different currencies, MCCs, and payment methods for each country. We use this information to enable you to create stores based on the type of payments that must be processed in the store.

Step 1: Create an account holder

Create an account holder for your sub-merchant. For details, see account holders and accounts.

You need to create the account holder before you can proceed to onboard your sub-merchants. Apart from the minimum information needed to create an account holder, also collect the following details from your sub-merchant. You will need these details later when you create a store.

Step 2: Onboard account holders and collect SAQ A details

The onboarding process is the same as onboarding regular sub-merchants, with the added requirement to send them the SAQ A.

Make sure that each sub-merchant has completed the SAQ A and has passed the KYC verification process before you add a store.

Collect SAQ A details using the Hosted Onboarding Page

If you use our Hosted Onboarding Page (HOP), the SAQ A will automatically appear for the sub-merchant as part of the onboarding flow.

Collect SAQ A details using your own onboarding flow

If you have built your own onboarding implementation, you have to include an additional call in your onboarding flow.

  1. Make a POST request to the /getPciQuestionnaireUrl endpoint, specifying:

    • accountHolderCode: The unique reference to the account holder.
    • returnUrl: The URL to your partner platform website.

    The response contains:

    • redirectURL: The page to where you redirect your account holder. This URL must be used within 15 seconds and can only be used once.
    • pspReference: The reference to this session. We recommend that you store this for troubleshooting purposes.
  2. Redirect the account holder to the redirect URL within 15 seconds after you received the response. When they are successfully redirected to the questionnaire, the session starts. The session is valid for 30 minutes.

    The account holder receives an HTTP 401 status code if:

    • The redirection did not occur within 15 seconds.
    • The account holder refreshes or reloads the browser after the session has started.

    To restart the session, make another POST request to /getPciQuestionnaireUrl.

  3. Make sure that you have configured webhooks so you can get the verification statuses in the ACCOUNT_HOLDER_VERIFICATION notification.

When you have verified that the account holder provided the SAQ A successfully and that the KYC verification is complete, you can continue with the next steps.

Step 3: Create a store for the account holder

An account holder is successfully onboarded on your platform when they have passed the KYC checks and completed the SAQ A. Now, you need to provide us with the details of their store.

Make sure our Support Team has enabled creating stores. If you haven't requested this yet, refer to Before you begin.

Once our Support Team has enabled creating stores, you can start adding stores for your account holders.

  1. Make sure that you have configured webhooks so that you are able to receive notifications. Create a notification configuration with an eventConfigs array with:

    • eventType: ACCOUNT_HOLDER_STORE_STATUS_CHANGE
    • includeMode: INCLUDE
  2. To provide the store details, include a storeDetails array when you update an existing account holder. Make a POST request to /updateAccountHolder.

    In the request body, include an accountHolderDetails.storeDetails array, specifying:

    • address: The address of the store.
    • fullPhoneNumber: The phone number of the store.
    • merchantAccount: The merchant account used for accepting payments.
    • merchantCategoryCode: The merchant category code (MCC) that classifies the business of the account holder.
    • storeName: The name of the account holder's store. This will be included in the shopper statement.
    • storeReference: Your unique reference for the account holder's store.
    • webAddress: The URL of the account holder's online store.
    • shopperInteraction: The sales channel. In this case, use Ecommerce.

    The next example shows an /updateAccountHolder request to add a store to an account holder.

    The response contains various account holder details, including the storeDetails showing that the status of the store is Pending.

  3. Before processing any payments, wait until you receive an ACCOUNT_HOLDER_STORE_STATUS_CHANGE notification showing that the new status of the store is Active.

Step 4: Add sub-merchant domains to allowed origin

If any of your sub-merchants take payments from their own domains, you need to add their domains to your allowed origins.

Step 5: Route a payment to a store

Each sub-merchant has their own unique connection to the card networks. This connection is represented by their store.

When processing payments, you have to direct them to the appropriate store. To route a payment to a store, include the store field in your /payments request. You can get the value for this field from the response you received when you added the store, or from the ACCOUNT_HOLDER_STORE_STATUS_CHANGE notification webhook.

When processing payments through a store, you can create a split configuration to automatically split payments or you can provide split data in every API request.

You can split payments across multiple account holders, but you can only process a payment through a single store.

The following example shows how to provide split information in the API, routing them over a single store.

See also