Adyen for Platforms: What the API Gives You, and What You Still Build

Adyen processed €803.8 billion in H1 2026, with Platforms as its fastest-growing segment and volume up 42% year on year. Adyen for Platforms provides the regulated infrastructure behind the flow: a licensed entity holds the funds, Adyen handles KYB decisions, and payouts are supported across dozens of markets.

The experience around that infrastructure is the sub-merchant portal, and it remains part of your product. When a seller wants to know why a payout is late, the screen they read the answer on is one you build.

This article maps that boundary: what Adyen for Platforms covers out of the box, what remains on your side of the integration, and where the custom layer comes in.

What Adyen for Platforms Covers Out of the Box

Adyen for Platforms runs on the balance platform, the accounting system that holds your users and their funds. Four resources carry most of the model.

A legal entity holds the information Adyen needs to verify a seller. An account holder carries the capabilities that define what the seller may do. A balance account holds their money, and a transfer instrument is the verified bank account it leaves to.

On top of that structure, Adyen runs these parts:

• Verification. You submit seller data in Adyen’s legal-entity format. Adyen makes the KYB and KYC decision and grants capabilities on the result.
• Funds. Adyen holds balances, splits payments between sellers and your platform, books your commission, and executes payouts.
• Payouts. Sweeps push funds from a balance account to a verified transfer instrument on a schedule. On-demand payouts go through the Transfers API.
• Cardholder data. Card details go into Adyen’s hosted components, which keeps them clear of your infrastructure and of your PCI DSS scope.

The product ships interface too. Hosted onboarding redirects your seller to an Adyen-hosted page that collects their data and handles document upload.

Platform Experience components, covering Transactions Overview, Payouts Overview and Capital, drop interactive data views into your own frontend through the @adyen/adyen-platform-experience-web library. The Capital components include the regulatory disclosures that financial products require.

Why Adyen for Platforms Is a Strong Foundation

The case for Adyen for Platforms starts with regulation. Adyen holds the licences and owns the regulated relationship with your seller, so fund custody, payment facilitator registration and scheme negotiation stay with Adyen. 

In H1 2026 the company secured direct access to France’s domestic interbank clearing system and a Retail Payment Services licence from the Central Bank of the UAE. That licensing footprint keeps widening underneath you.

The capability framework is the second reason. Compliance reaches your code as data: an account holder either holds a capability or waits for one, and the grant follows verification. A new market can then arrive as a configuration change.

What You Still Own, Part One: Onboarding Around the Legal-Entity Model

Even on hosted onboarding, Adyen’s lower-effort path, the setup belongs to you. Your backend creates the main legal entity, links supporting legal entities for directors and beneficial owners, creates the account holder, and connects them before a seller sees a screen.

Then the link. A hosted onboarding link expires four minutes after creation, survives one click, gives your seller an hour on the page, and dies on refresh. The link therefore lives between your API call and the seller’s click, which puts link generation inside your own UI.

Settings on that same call decide which PCI questionnaires the seller signs, by sales channel. Each constraint turns into a UI state, including the one that issues a fresh link when a seller comes back to finish.

Mapping is usually the larger piece of work. Platforms name their sellers in product terms. Adyen names them as legal entities of a specific type, with associated individuals, business lines and transfer instruments.

One registered company trading under several brands resolves differently from a sole trader operating as a business. The schema underneath everything else follows from that decision.

Part Two: Translating Adyen’s State Into Language Sellers Act On

Adyen exposes detailed system states through its platform. These include capability grants, verification errors with deadlines, account holder statuses such as active, suspended, and closed, and transfer failures caused by insufficient balance, missing capabilities, or a deleted transfer instrument.

These states are accurate, but many of them also end up in your support queue.

A status such as “verification pending” tells a seller where the process stands. A message that explains which document is missing, which registered address needs to be provided, and when the deadline falls gives them a clear next step.

Turning one into the other is product work. Each verification error needs to be mapped to a reason and a next action, with a clear distinction between what the seller can resolve and what requires your operations team. That mapping also needs to change as Adyen updates its requirements.

Adyen’s components provide the underlying data. The explanation around that data, including why an account is limited or where a payout has reached, affects how much of the resulting support queue sellers can resolve themselves.

That translation layer is a core part of the sub-merchant portal on Adyen for Platforms we build, where each status is presented with a reason and a next action.

Part Three: The Admin Panel for Seller Operations

The Balance Platform Customer Area serves your payments and finance teams, while seller operations often need the same underlying information to answer seller questions.

A dedicated admin panel can bring the onboarding pipeline into one place: invited, in progress, verified, and needs attention, with the reason shown for each seller. Admin invites and per-sub-merchant capability visibility can sit alongside the same information, giving the operations team a single view of each seller without switching between tools.

Customer Area credentials provide broad access across the balance platform. An admin panel can narrow that view to the information seller operations actually need, while also making the queue measurable: how many sellers are at each stage and how long they have been there.

Webhooks, Reconciliation, and the Quiet Systems Work

The balance platform runs asynchronously throughout. Account holder updates, capability changes, verification outcomes, transfers and transactions all arrive as webhooks. Transfer webhooks come in sequence, each carrying a sequence number, as a payout moves from created to authorised to booked.

Acknowledgement and recovery after a missed webhook stay on your side of the integration, which puts a durable queue and an idempotency strategy in scope.

Reconciliation follows. Your sellers see earnings after fees. Adyen publishes the Balance Platform Payout Report daily, listing scheduled payouts and the transactions composing them. Lining those two views up spans each settlement currency and the fees deducted along the way.

Live configuration is its own build. Webhooks, sweeps, onboarding themes and credentials go up again against production keys, so the end-to-end flow runs twice.

Build It In-House, or Configure a Tenant

Both routes end with sellers logged into something carrying your brand. They differ in where your engineering time goes.

Dimension	Building in-house	Configuring a tenant with Kindgeek
Starting point	You design and build the portal from scratch	We adapt an existing implementation to your seller model
Legal-entity mapping	Your team maps it during implementation	Our onboarding already mirrors Adyen’s legal-entity model
Status display	You design it as part of the build	Every status carries a reason and a next action by default
Codebase	One codebase, one platform	One shared codebase, configured per tenant
Maintenance	The team that builds it also maintains it	We maintain and support it after go-live
Security review	Covers the whole architecture your team assembled	Adyen stays the system of record for funds, card data and the ledger

Build in-house when you already have payments engineering inside your product team, and when the portal belongs in the same codebase as the rest of your product. Build in-house as well when your sellers are private individuals, because our onboarding mirrors Adyen’s legal-entity model and that model covers registered businesses.

Configure a tenant when Adyen is live or contracted, your sellers are registered businesses, and you want the portal answering seller questions inside the current quarter. For sellers who run their own finance systems, a scheduled data feed costs less than a portal and gives them the reconciliation they are after. 

We cover partner-side integrations in the Kindgeek Fintech Integration Hub.

What a Sub-Merchant Portal on Adyen for Platforms Looks Like in Practice

That division of labour is what usually lets us deliver in weeks. Adyen stays as the system of record while the portal is an interface over it.

Responsibility	Owner	What that means in the portal
Funds and balances	Adyen	The portal never receives or holds money. It reads balances and sends payout instructions back
KYB and KYC decisions	Adyen	The portal collects data in legal-entity format and passes it on. Adyen decides
Cardholder data	Adyen	Card details go through Adyen’s hosted components, outside the portal’s PCI scope
Capability grants	Adyen	Adyen grants capabilities after verification; the portal shows the current status
API credentials	Platform	Your Adyen keys. We keep test and production separate
The interface	Kindgeek	We build the portal, admin panel and onboarding flow, and translate Adyen’s statuses into seller language

Funds stay with Adyen and card data moves through hosted components, keeping the portal’s security and compliance surface relatively small. The remaining work is largely product design and integration.

The seller view shows earnings after fees, transactions with clear statuses, payout initiation with the relevant account and schedule, and verification status with a reason and next action. Alongside it, an admin panel gives your operations team a view of the full pipeline, while the onboarding flow follows Adyen’s legal-entity model so the same underlying structure can be used throughout.

Delivery runs in four phases: model fit (1 week), tenant provisioning covering the subdomain, branding, and modules (1–2 weeks), end-to-end validation with test keys (1 week), and production cutover (1 week).

The approach is to configure the tenant rather than build the portal from scratch, using Adyen’s existing platform capabilities and focusing development effort on the parts that are specific to your product.

What Belongs on Your Roadmap

Adyen for Platforms covers much of the infrastructure behind platform payments, including licensing, fund custody, verification decisions, PCI scope, and payout execution across markets.

That leaves a product layer to design: how seller-facing onboarding maps onto Adyen’s model, and how Adyen’s status information is presented to the seller using it.

A useful first step is to list the Adyen statuses your team currently explains to sellers by hand, along with the response each one receives. That list can become a first specification for the portal, while its length can help indicate whether the work is closer to a month of product design or a quarter.

Where sellers are registered businesses and seller operations are handled by a dedicated team, this layer can often be configured around Adyen’s existing capabilities. Book a technical call to discuss the scope, timeline, and team needed for your setup.