How it works
The mechanics, at architecture level.
Collimate sits above the money path, not inside it. Here is what moves where, what we store, what we never touch, and what happens when Adyen's API changes underneath us.
01 / Data flow
A control layer above the money path, not inside it.
02 / System of record
What stays with Adyen.
Money, verification decisions and capability grants are Adyen's. Collimate is a projection of that state, never a parallel ledger — which is what keeps the compliance surface small enough to review quickly.
- Funds and balances
- Adyen
- We never receive, hold or transmit money. Balances are read through; payouts are instructed back.
- KYB and KYC decisions
- Adyen
- Onboarding data is collected in Adyen's own legal-entity model and passed on. The outcome is Adyen's decision, surfaced with enough detail to act on.
- Capability grants
- Adyen
- Adyen grants a capability after verification. We display it; we never award or infer one.
- API credentials
- The platform
- You generate your own keys and hand them over. We act only under the keys as given, with test and production held separately per tenant.
- The operational interface
- Collimate
- The portal, the admin panel, the onboarding flow, and the translation of an Adyen status into a reason and a next action.
03 / Card data
None of it reaches us.
The shortest security review is the one where most of the surface does not exist.
- Payment interfaces are Adyen's
- Payment pages are Adyen's hosted components. Cardholder data goes from the shopper to Adyen without passing through Collimate infrastructure, so it is not in our PCI scope to begin with.
- We are not in the money path
- No funds are received, held or transmitted by Collimate. That is an architectural property, not an operational policy — there is no code path that could.
- Public identifiers are opaque
- Anything that reaches a URL, a payload or the UI uses a non-sequential public identifier. Internal identifiers are never exposed, so record counts and ordering cannot be inferred.
- Onboarding data is minimised
- What we store is what Adyen's legal-entity model requires to be collected, and it is passed on rather than accumulated. Consent version and timestamp are recorded, and data access is audit-logged.
04 / Isolation and identity
One codebase, strictly scoped.
Every platform is one tenant, configured rather than forked. Isolation is therefore a first-class concern and is treated as one.
Isolation is enforced in the application, and tested
Every record carries a tenant identifier and every query is scoped to it. The strongest objection to a shared model is that one mistaken query silently leaks across tenants — so the unscoped access path exists in exactly one place in the codebase, and an architecture test asserts it stays that way. That converts a diffuse review burden into a single audited location.
Identity is separated by surface
Sub-merchant sign-in runs in a realm created per tenant, which is where cross-tenant email collision is actually likely. Platform administrators authenticate against a separate shared realm, scoped in the application to exactly one tenant. Internal operations are separate again.
Credentials are separated by environment
Test and production Adyen credentials are stored apart per tenant and never interchangeable, so a sandbox mistake cannot reach production money.
One instance per tenant, not one deployment
A new platform is a configuration record, a subdomain and a set of flags — not a new deployment to maintain. Product improvements reach every tenant without a per-customer migration.
05 / Going live
Who does what, and how long it takes.
Collimate is configured, not self-service — which is what puts go-live in weeks rather than quarters, since none of the work below is a build. The split is the whole of it.
- 01You
Adyen API keys
Generated by you in your own Adyen account and handed over, test and production separately. Revocable by you at any time.
- 02You
Branding and policy
Logo, palette, type, and the module policy that decides what your sellers get.
- 03Collimate
Tenant provisioning
Instance record, subdomain, TLS, theming, feature flags and identity realms — configured by us on the shared codebase.
- 04Collimate
Validation, then production
The full loop against your sandbox keys — invite, onboard, watch verification statuses flow — then the same against production keys before your team takes over inviting.
06 / When Adyen changes
Tracking the API is the job, not an afterthought.
Collimate mirrors Adyen's domain model one to one rather than inventing an abstraction over it. That is a deliberate constraint, and it is what makes the next sentence possible.
The model mirrors Adyen, deliberately
Fields, legal-entity types, statuses and capabilities follow Adyen's shapes. Optional behaviour becomes configuration rather than a divergent model, so there is no translation layer accumulating its own truth.
Plain language is a presentation layer
Making a status legible is a rendering concern. It never changes the underlying value, so a change on Adyen's side surfaces as a change here rather than being absorbed silently into a different vocabulary.
Tracking changes is a standing commitment
Following Adyen's API is a permanent part of the work, not a migration project we do once. The mirrored model is what keeps the cost of that proportionate.
What this means for you
When Adyen adds a field or a status, the question is when we surface it — not whether our model can represent it.
Next step
Bring every sub-merchant into focus.
We are taking on a small number of design partners: platforms on Adyen for Platforms who want a say in what gets built, direct access to the team building it, and early pricing.