Build vs buy on Adyen for Platforms: the real cost of a sub-merchant portal

Adyen’s Platforms segment brought in €75.0 million of net revenue in Q1 2026, up 40% year on year at constant currency. Every tenant on Adyen for Platforms can onboard sellers and move money as soon as its integration is in place. The businesses underneath it, the salon and the restaurant and the personal trainer, usually have no sub-merchant portal to sign in to.

That gap gets filled one of two ways. Either the platform’s own team answers “where is my payout” by hand, or someone builds a portal. Most platforms assume they will build it, and the build is rarely as contained as the first estimate suggests. Getting embedded payments live is the easy half.

What a sub-merchant portal on Adyen for Platforms has to do

A sub-merchant portal looks like a dashboard. It behaves like a translation layer over a financial system you do not control.

Adyen records payment and account states in its own terms. A seller does not want to read those terms, and your support team should not be reading them aloud over email. “Verification pending” is worthless to a seller on its own. It becomes useful only when they can see why it is pending and what action clears it. That translation, applied to every status in the system, is the actual product. The screens are what it gets delivered in.

Take a Monday morning on a live platform. A seller logs in to check why her payout is short. An operations lead figures out which new sellers from last week didn’t finish signing up. Behind the scenes, all those sellers went through an onboarding flow that had to match Adyen’s business verification needs. In Collimate, our sub-merchant portal for Adyen for Platforms, each of these tasks has its own dedicated area:

• The sub-merchant portal lets that seller from Monday morning see why her payout is short. Each payment appears in her transaction list with the fee already deducted, so she can find the answer herself instead of emailing support. The portal needs to work for quick checks on a phone and for detailed reviews at the end of the month.
• The tenant admin panel lets your operations lead see all sub-merchants on one screen, including any tricky cases. For example, a seller might pass verification but still cannot receive payouts. From her perspective, everything is complete, but her money is not arriving. If your ops lead has to check Adyen directly to figure this out, the panel is not doing its job.

PCI scope is the thing to settle before any of this gets built. Card details are entered through Adyen’s hosted components, so card data never touches the portal’s infrastructure and the portal stays out of scope. Render a card field yourself, once, anywhere in the flow, and you have taken on a PCI DSS obligation nobody budgeted for and your security team inherits.

Sub-merchant onboarding follows Adyen’s legal-entity model

Sub-merchant onboarding follows Adyen’s order of operations, set by its legal-entity model, and that order is not what a signup form suggests. A sole trader has to exist as a person first, then as a business linked to that person. A company needs a record for each owner and signatory behind it, each verified separately. Design your own form around one “business owner” field and the first company with three signatories sends you back to rework it.

The honest build estimate: six to seven people for six months

Our estimate for this scope is a team of six or seven: frontend, backend, an engineer who owns the Adyen integration, QA, a business analyst, a PM and a designer, with fintech experience spread across the group. Six months to a first release, assuming the team is capable and working closely with Adyen’s technical contacts. £300,000 to £500,000 to build.

Two caveats on the number. It covers a first release, not the steady state. And it assumes the estimate holds.

This range comes from our own delivery experience, which is not a published benchmark. Use it as a starting point for your own calculations, because everything depends on your own requirements.

Why building a sub-merchant portal in-house runs over budget

When an IT project goes badly wrong, it does not go 50% wrong. The average one in that group costs 5.53 times what it was supposed to.

That comes from 5,360 IT projects studied by Flyvbjerg and colleagues in Project Management Journal this year. Roughly four in ten went over budget at all, and plenty of those were the ordinary, absorbable kind. The minority is what matters: nearly one in five blew past the estimate by more than half, and it is that group whose average lands at 5.53 times.

So an IT budget has no typical overrun to plan around. Of the 23 kinds of project compared, IT was the only one with no stable average at all, which is another way of saying you cannot add a contingency percentage when the failures have no characteristic size.

The study’s word for what separates the two groups is bespokeness. On an Adyen build, it tends to surface around month four, when the team finds that the seller model they designed against does not map cleanly onto Adyen’s legal entities, that sole traders and multi-director companies need different onboarding paths, and that the verification status they had treated as a field is really a sequence of capability grants arriving by webhook. None of that was in the spec. We have to build all of it before anyone logs in. Therefore, a six-month estimate starts being wrong.

The cost that starts on go-live: API changes and payout support

Adyen versions its APIs and ships a new version whenever a change would break existing integrations. Good API design, and a standing commitment for whoever maintains your portal. Versions 1 and 2 of the Transfers API are already deprecated; current balance platform integrations run on v4.

The legal-entity model is the other moving part. If you mapped Adyen’s entity requirements into your own schema during implementation, every change to those requirements becomes a migration in your system rather than a passthrough. Mirroring the model one to one is more work on day one and considerably less work in year two.

A marketplace payout comes in lighter than the salon owner expected. She emails your support inbox, and someone opens Adyen, pulls her week’s payments, adds up the fee your split rule took from each one, and writes back with the total. That is one seller, one week. Your platform will have hundreds of sellers, sometimes a few thousand.

None of that appears in the build estimate. All of it competes with your core product for the same engineers.

Build vs buy: in-house vs Collimate, criterion by criterion

Criterion	Build in-house	Collimate
Time to first release	6+ months of engineering	4 to 5 weeks across four delivery phases
Engineering team	Six to seven people, including QA, BA, PM and design	None to hire. You provide the Adyen API keys
Upfront cost	Estimated £300–500k to build	A one-off setup fee
Ongoing cost	Engineering maintenance, plus a roadmap of its own	A monthly subscription based on platform size, such as active sub-merchant count, rather than transaction volume
Adyen API changes	Your team tracks and implements every change	Handled inside the product
Adyen legal-entity model	Mapped into your schema during implementation	Onboarding already mirrors it one to one
Status display	Designed as part of the portal build	Every status carries a reason and a next action by default
Cardholder data	In your PCI scope unless you integrate hosted components	Adyen’s hosted components. Card data never reaches the portal
Codebase	Yours, along with every line you maintain	One shared codebase, configured per tenant, never forked per client
System of record	Adyen, plus whatever you store yourself	Adyen, for funds, card data and the ledger

There are four delivery phases: model fit (1 week), tenant provisioning (1 to 2 weeks), testing with a real test seller (1 week), and production cutover using your production keys (1 week). Most of the time is spent on configuration, not building from scratch, which is why it takes weeks instead of months.

Who owns what: funds, KYB verification and the interface

Take the question a compliance lead would ask: can this portal touch a seller’s money? It cannot. The portal reads the seller’s balance from Adyen and sends payout instructions back, and the money never passes through it. Most of the table below works the same way, and it works that way whether you build or license.

Boundary	Owner
Funds and balances. The portal never receives or holds money. It reads balances and payout information from Adyen and sends payout instructions back.	Adyen
KYB verification and KYC decisions. The portal collects onboarding information in Adyen’s legal-entity format and passes it on.	Adyen
Cardholder data. Entered through Adyen’s hosted components, so it stays outside the portal’s PCI scope.	Adyen
Capability grants, issued after verification. The portal shows the current status to the seller.	Adyen
API credentials. You provide the keys, with test and production kept separate.	Your platform
The interface: portal, admin panel and onboarding, plus turning Adyen’s statuses into something sellers can act on.	Kindgeek

Your brand is the exception, and it is the part sellers actually see. It is a white-label portal where your logo, colours, typeface, and subdomain are set when we stand the tenant up. A seller signs in at your address and never sees ours, even though the code underneath is the same code every other tenant runs.

Another question is what happens if you leave. The sub-merchant portal only reads the payment records and does not keep its own copy. Therefore, all your transaction data stays in an Adyen account. You can switch off the portal, and your records will still be there.

When not to buy a sub-merchant portal

Three situations in a build vs buy decision where building, or doing nothing, beats licensing the software.

Your sub-merchants are private individuals. The onboarding flow follows Adyen’s legal-entity model, which is designed around registered businesses. If your sellers are individuals, the model does not fit.

Your sellers run their own finance systems. A business with its own accounting stack may want a data feed, not a login. A portal solves a problem they do not have.

You have in-house payments engineering and the portal is your differentiator. If what your sub-merchants see is the reason they choose you, and you employ people who have integrated Adyen for Platforms before, build it closer to your own product.

It is also not a drop-in for another PSP. The onboarding is mirrored to Adyen’s model specifically.

Everything else is the ordinary case. The portal is table stakes, your sellers expect it because comparable platforms have it, and you are deciding whether to spend six months and most of half a million reaching parity, then paying every year to stay there.

The build vs buy question was never whether your engineers could build it. It is whether this is where you want six months of their time.