How to Integrate Adyen: A Step-by-Step Guide

August 31, 2026 at 11:55 AM

How to Integrate Adyen: A Step-by-Step Guide

Adyen is one of the most widely used enterprise payment platforms, and its own documentation is thorough, but it's written for engineers building a standalone integration, not for someone trying to decide how to integrate Adyen alongside everything else their checkout needs to do. This guide walks through what an Adyen integration actually involves, the decisions you'll need to make along the way, and where Briqpay fits if you don't want to lock your checkout to a single provider.

What "integrating Adyen" actually involves

At a high level, every Adyen integration goes through the same stages:

1. Account setup and credentials: you get access to Adyen's test Customer Area, along with an API key and a client key. These are separate: the API key authenticates your server-side calls, the client key is used by front-end payment components.
2. Choosing an integration type: see below. This decision affects how much UI code you write and how much control you have over the checkout's look and feel.
3. Building the payment flow: server-side, your backend creates a payment session (a call to Adyen's /sessions endpoint with amount, currency, shopper info, and a return URL); client-side, you use the session data to render the payment UI and handle the outcome.
4. Webhook integration: Adyen confirms final payment outcomes asynchronously via webhooks (the AUTHORISATION event is the one most integrations key off), so your backend needs an endpoint that receives and verifies these.
5. Testing in the sandbox, then going live: Adyen provides a full test environment with test card numbers and simulated local payment methods before you switch over to production credentials.

Drop-in, Components, or a custom build?

This is the first real decision, and it shapes how much work the rest of the integration is:

• Drop-in is Adyen's pre-built, ready-to-use checkout UI. You get a complete payment form with minimal front-end code: the fastest path, but the least control over layout and design.
• Components are individual, per-payment-method UI modules (a card component, an iDEAL component, and so on) that you assemble yourself into your own checkout layout. More development work than Drop-in, but you control how the checkout looks and where each piece sits.
• A fully custom integration (Adyen's "Classic" API-only approach) means building your own payment UI and handling encryption and flows manually. This gives maximum control but is significantly more work to build and maintain, and most new integrations don't need it: Adyen itself recommends Drop-in or Components for new builds.

For most merchants, the practical choice is Drop-in if you want to move fast, or Components if your checkout has specific design requirements Drop-in can't accommodate.

Where this gets more complicated: Adyen is rarely the only provider you need

A raw Adyen integration handles Adyen well. It doesn't handle what happens when you also want Swish for Swedish customers, a Klarna option at checkout, or a second acquirer as a fallback if Adyen has an outage: each of those is its own separate integration, contract, and set of credentials to manage, and your checkout code needs to know how to route between them.

Integrating Adyen through Briqpay

Briqpay connects to Adyen (and other providers) through a single API, so instead of building and maintaining Adyen's integration in isolation, you integrate once and configure which providers and methods are active (by market, cart value, or customer type) without touching your checkout code each time something changes. Concretely, that means:

• One integration, not one per provider. You build against Briqpay's API once; adding a payment method or a second provider later is a configuration change, not a new integration.
• You keep your own Adyen contract. Briqpay orchestrates the checkout logic; your commercial relationship with Adyen is unchanged.
• Rule-based routing. Show Adyen for card payments and Swish for local Swedish shoppers in the same checkout, without separate flows for each.
• Add or replace providers without a rebuild. If you later want a second acquirer alongside Adyen (for redundancy, cost, or coverage in a new market), that's a configuration change on Briqpay's side, not a new front-end integration.

If you're integrating Adyen as your only provider today but expect to add local methods or a second PSP later, it's worth deciding on the orchestration layer before you build the first integration rather than after: retrofitting routing logic onto a direct integration is more work than starting with it.

FAQ

Do I need to rebuild my checkout to add Briqpay if I already have a direct Adyen integration? You'll need to move the checkout logic to call Briqpay's API instead of Adyen's directly, but your existing Adyen contract and account stay in place. Briqpay orchestrates on top rather than replacing the underlying relationship.

What's the difference between Drop-in and Components? Drop-in is a single pre-built checkout UI; Components are individual per-method building blocks you assemble into your own layout. Drop-in is faster to implement; Components give you more design control.

Do webhooks matter if I'm using Briqpay? Yes. Final payment confirmation is still asynchronous. Briqpay's API surfaces this to you in one place rather than you needing to build separate webhook handling per provider.

Can I test an Adyen-via-Briqpay integration before going live? Yes. Adyen's sandbox/test environment works the same way whether you're integrating directly or through Briqpay; you test with Adyen's test credentials and switch to live credentials at go-live.

Want to see all the providers you can combine with Adyen? Compare every payment method Briqpay supports.