Rank #3 of 6 in Marketplace & Platform Payments
Install
npm install @adyen/api-libraryProducts
Adyen, product by product →Adyen ships more than one product — each judged line competes in its own arena on the same stories as everyone else.
| Line | Arena | Rank | PA Score | Agent-ready |
|---|---|---|---|---|
| Online Payments | Online Payments | #7/10 | 38/100 | 65/100 |
| In-Person Payments | Mobile & In-Person Payments | #4/4 | 23/100 | 47/100 |
| Adyen for Platformsthis page | Marketplace & Platform Payments | #3/6 | 23/100 | 40/100 |
| Orbacquired | Billing & Subscriptions | #7/7 | 18/100 | 33/100 |
| Issuing | Card Issuing Platforms | #5/5 | 15/100 | 22/100 |
Not yet judged (3 — no arena where they compete): Risk Management · Adyen Agentic · Adyen Uplift
Try itExperimental
See what an agent can do with Adyen for Platforms before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -si -X POST https://checkout-test.adyen.com/v71/payments -H 'Content-Type: application/json' -d '{}' # keyless → 401recorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Embedded experience — stories about embedded experience in this arenaEmbedded experienceevidence →
Stories about embedded experience in this arena
Funds routing — stories about funds routing in this arenaFunds routingevidence →
Stories about funds routing in this arena
Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputesevidence →
Stories about marketplace disputes in this arena
Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payoutsevidence →
Stories about marketplace payouts in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Payfac liability — stories about payfac liability in this arenaPayfac liabilityevidence →
Stories about payfac liability in this arena
Platform agent access — stories about platform agent access in this arenaPlatform agent accessevidence →
Stories about platform agent access in this arena
Platform ledger — stories about platform ledger in this arenaPlatform ledgerevidence →
Stories about platform ledger in this arena
Platform monetization — stories about platform monetization in this arenaPlatform monetizationevidence →
Stories about platform monetization in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Seller onboarding — stories about seller onboarding in this arenaSeller onboardingevidence →
Stories about seller onboarding in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where Adyen for Platforms stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓8/10
unlocks → Official SDKs · Scoped API keys · Machine-readable spec · Versioning policy · Official CLI · Full data export · The platform is ready for agent buyers — documented support for agent-initiated checkout on marketplace transactions (agentic-commerce protocols, delegated payment credentials) that works with split funds flows
Subscribe to events via webhooks
✓7/10
Build against official SDKs
—0/10
Issue scoped/least-privilege API credentials for an agent
—–
Connect an agent via an official MCP server
~6/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
✓7/10
Explore an interactive API reference with runnable examples
—0/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
n/an/a
Operate the product with natural-language commands
~5/10
Plug MCP servers into this product so it can use their tools
n/an/a
Get AI-generated insights and suggestions from my data inside the product
—–
Set up automations that run autonomously in the background
~4/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Embedded experience — stories about embedded experience in this arenaEmbedded experience
Stories about embedded experience in this arena
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand
~6/10
In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments
~2/10
Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me
~4/10
Funds routing — stories about funds routing in this arenaFunds routing
Stories about funds routing in this arena
Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented
~6/10
Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented
~6/10
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects
~7/10
Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputes
Stories about marketplace disputes in this arena
Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically
~6/10
Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actors
~6/10
Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payouts
Stories about marketplace payouts in this arena
International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires
~4/10
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller
✓6/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Payfac liability — stories about payfac liability in this arenaPayfac liability
Stories about payfac liability in this arena
There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming
~4/10
The responsibility split is explicit — who owns KYC/AML, card-network compliance, fraud losses, and seller misconduct between me and the provider, in the docs rather than the contract's fine print
—0/10
Seller tax reporting is handled — 1099-K thresholds tracked, forms generated, delivered, and filed, with the data corrections workflow documented
—–
Platform agent access — stories about platform agent access in this arenaPlatform agent access
Stories about platform agent access in this arena
An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
~6/10
An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
~5/10
The platform is ready for agent buyers — documented support for agent-initiated checkout on marketplace transactions (agentic-commerce protocols, delegated payment credentials) that works with split funds flows
—–
Platform ledger — stories about platform ledger in this arenaPlatform ledger
Stories about platform ledger in this arena
Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accounts
~4/10
The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny
~6/10
Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
~6/10
Platform monetization — stories about platform monetization in this arenaPlatform monetization
Stories about platform monetization in this arena
Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
~6/10
I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread
~4/10
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Seller onboarding — stories about seller onboarding in this arenaSeller onboarding
Stories about seller onboarding in this arena
Sellers can join from where they are — supported onboarding countries, local payment methods, and local-currency settlement documented as a coverage map, not discovered ticket by ticket
—0/10
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
✓8/10
Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller
~4/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | partial | 6/10 | Tprobed | |
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | 0/10 | ||
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Tprobed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Cclaimed | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Tprobed | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 5/10 | Cclaimed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 4/10 | Tprobed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | full | 7/10 | Cclaimed | |
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms C Onboarding api | developer | Seller onboarding — stories about seller onboarding in this arenaSeller onboarding | 3 | full | 8/10 | Cclaimed | |
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects C Splits | developer | Funds routing — stories about funds routing in this arenaFunds routing | 3 | partial | 7/10 | Cclaimed | |
Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically C Dispute handling | ops user | Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputes | 3 | partial | 6/10 | Cclaimed | |
Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs G Application fees | founder | Platform monetization — stories about platform monetization in this arenaPlatform monetization | 3 | partial | 6/10 | Cclaimed | |
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller C Payout schedules | ops user | Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payouts | 3 | full | 6/10 | Cclaimed | |
The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny C Ledger visibility | finance lead | Platform ledger — stories about platform ledger in this arenaPlatform ledger | 3 | partial | 6/10 | Cclaimed | |
An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials C Agent onboarding | ai-native user | Platform agent access — stories about platform agent access in this arenaPlatform agent access | 3 | partial | 5/10 | Tprobed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | partial | 5/10 | Cclaimed | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | none | untested | none yet | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces C Agent money ops | ai-native user | Platform agent access — stories about platform agent access in this arenaPlatform agent access | 2 | partial | 6/10 | Tprobed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 6/10 | Tprobed | |
Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented C Holds release | developer | Funds routing — stories about funds routing in this arenaFunds routing | 2 | partial | 6/10 | Cclaimed | |
Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule C Recon exports | developer | Platform ledger — stories about platform ledger in this arenaPlatform ledger | 2 | partial | 6/10 | Cclaimed | |
Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented C Negative balances | finance lead | Funds routing — stories about funds routing in this arenaFunds routing | 2 | partial | 6/10 | Cclaimed | |
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand C Embedded components | developer | Embedded experience — stories about embedded experience in this arenaEmbedded experience | 2 | partial | 6/10 | Cclaimed | |
Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actors C Portfolio risk | ops user | Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputes | 2 | partial | 6/10 | Cclaimed | |
I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread G Buy rates | finance lead | Platform monetization — stories about platform monetization in this arenaPlatform monetization | 2 | partial | 4/10 | Cclaimed | |
International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires C Cross border | finance lead | Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payouts | 2 | partial | 4/10 | Cclaimed | |
Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller C Progressive requirements | ops user | Seller onboarding — stories about seller onboarding in this arenaSeller onboarding | 2 | partial | 4/10 | Cclaimed | |
Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accounts C Funds custody | finance lead | Platform ledger — stories about platform ledger in this arenaPlatform ledger | 2 | partial | 4/10 | Cclaimed | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 4/10 | Cclaimed | |
Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me C Seller reporting | ops user | Embedded experience — stories about embedded experience in this arenaEmbedded experience | 2 | partial | 4/10 | Cclaimed | |
There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming C Graduation path | founder | Payfac liability — stories about payfac liability in this arenaPayfac liability | 2 | partial | 4/10 | Cclaimed | |
In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments C Omnichannel | founder with offline sellers | Embedded experience — stories about embedded experience in this arenaEmbedded experience | 2 | partial | 2/10 | Tprobed | |
Sellers can join from where they are — supported onboarding countries, local payment methods, and local-currency settlement documented as a coverage map, not discovered ticket by ticket C Global coverage | founder | Seller onboarding — stories about seller onboarding in this arenaSeller onboarding | 2 | none | 0/10 | ||
The responsibility split is explicit — who owns KYC/AML, card-network compliance, fraud losses, and seller misconduct between me and the provider, in the docs rather than the contract's fine print C Responsibility split | ops user | Payfac liability — stories about payfac liability in this arenaPayfac liability | 2 | none | 0/10 | ||
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | untested | none yet | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | n/a | untested | none yet | |
Seller tax reporting is handled — 1099-K thresholds tracked, forms generated, delivered, and filed, with the data corrections workflow documented C Tax forms | finance lead | Payfac liability — stories about payfac liability in this arenaPayfac liability | 2 | none | untested | none yet | |
The platform is ready for agent buyers — documented support for agent-initiated checkout on marketplace transactions (agentic-commerce protocols, delegated payment credentials) that works with split funds flows C Agentic commerce | developer | Platform agent access — stories about platform agent access in this arenaPlatform agent access | 2 | none | untested | none yet | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | n/a | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 40 stories with headroom
What would move Adyen for Platforms’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Openness — open source, data portability, and self-hosting storiesExport all of my data in open formats and leave
nonemoves PA Scoreimpact 30
No evidence of any data export/portability feature or open-format data dump capability; documentation covers onboarding, payouts, fraud, reporting, and API integration but never data export or account closure/portability.
Agenticness — how well agents can access and operate the productGet AI-generated insights and suggestions from my data inside the product
nonemoves Built-in AIimpact 30
The evidence pack covers onboarding, payouts, fraud rules, reconciliation reports, and an MCP server for developer integration, but nothing describes AI-generated insights or suggestions surfaced to end users from their platform data.
Agenticness — how well agents can access and operate the productUse an official CLI
nonemoves agent-readyimpact 30
Missing: any documentation of an official CLI, its install/usage, or command reference.
Agenticness — how well agents can access and operate the productIssue scoped/least-privilege API credentials for an agent
nonemoves agent-readyimpact 30
No evidence in the pack addresses issuing scoped or least-privilege API credentials for an AI agent; the docs cover onboarding, payouts, fraud monitoring, webhooks, and an MCP server, but nothing about API key/credential scoping or permission granularity for agents.
Agenticness — how well agents can access and operate the productBuild against official SDKs
nonemoves agent-readyimpact 30
Missing: any citation of an official SDK, its languages, or GitHub repo/package documentation.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
The evidence pack shows only static docs pages and confirms openapi/swagger endpoints return 404, with no mention of an interactive API reference or runnable code examples/try-it console.
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
The evidence pack shows explicit probes for OpenAPI/Swagger spec files at all standard candidate paths returning 404, and no other citation confirms a downloadable machine-readable API spec for Adyen for Platforms.
Agenticness — how well agents can access and operate the productRely on versioned APIs with a documented deprecation policy
nonemoves API qualityimpact 30
No evidence in the pack references API versioning, version numbers, or a deprecation policy/timeline for Adyen's APIs; probes for OpenAPI specs returned 404.
Showing the top 8 of 40 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map6 surfaces · 31 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
Platforms docs26 stories
- Point an agent at llms.txt or agent-oriented docs
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Set up automations that run autonomously in the background
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand
- In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments
- Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me
- Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented
- Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented
- Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects
- Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actors
- International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires
- Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller
- Do everything through the API that I can do in the UI
- There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming
- An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
- An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
- Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accounts
- The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny
- Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
- Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
- I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread
- Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
- Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller
Marketplaces docs18 stories
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- Define rules that trigger actions automatically on events
- Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand
- Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented
- Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented
- Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects
- Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically
- International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires
- Do everything through the API that I can do in the UI
- An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
- An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
- Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accounts
- The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny
- Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
- Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
- Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
- Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller
Development resources docs13 stories
- Run the product headlessly / in CI for automation
- Connect an agent via an official MCP server
- Drive the product through a documented public API
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Operate the product with natural-language commands
- Test against a sandbox environment without touching production data
- Define rules that trigger actions automatically on events
- Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically
- Do everything through the API that I can do in the UI
- An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
- An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
- Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
Platform payments docs13 stories
- Set up automations that run autonomously in the background
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me
- Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented
- Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actors
- International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires
- Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller
- Do everything through the API that I can do in the UI
- There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming
- Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
- I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread
- Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
OpenAPI spec3 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -si -X POST https://checkout-test.adyen.com/v71/payments -H 'Content-Type: application/json' -d '{}' # keyless → 401reproduced$ curl -si -X POST https://checkout-test.adyen.com/v71/payments -H 'Content-Type: application/json' -d '{}' # [redacted]less → 401
HTTP/2 401
traceparent: 00-1e6a923b091efc84ba057b9316b8bc96-cb9da9f85a3b8299-01
$curl -sL https://docs.adyen.com/llms.txt | head -3reproduced$ curl -sL https://docs.adyen.com/llms.txt | head -3 # Adyen Docs > Developer and merchant documentation for Adyen payments, Adyen for Platforms, Issuing, point-of-sale, and ri[redacted]management products. Every page is also available as Markdown by appending `.md` to the URL.
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
1 of 13 testable claims verified · 1 contradicted → integrity 0/100
18 distinct capability claims found in Adyen for Platforms’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
1
Verified
11
Unverified
1
Contradicted
19
Undersold
Verified (1)
“Use natural language to connect with Adyen's platform and build payment solutions faster”
Operate the product with natural-language commandspartialproof ↗
Unverified (17)
“Onboard sellers, service providers, or contractors and have Adyen verify them before payout”
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the formsfullproof ↗
“Split a payment across multiple users, deduct costs, and hold funds until payout”
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objectspartialproof ↗
“Split a payment across multiple users, deduct costs, and hold funds until payout”
Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documentedpartialproof ↗
“Choose managed payouts or exercise full custom control over payout timing”
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per sellerfullproof ↗
“Detect fraudulent behavior, stop suspicious payouts, and flag unusual user activity”
Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actorspartialproof ↗
“Use Adyen-generated reports for bookkeeping and reconciliation of platform funds”
Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedulepartialproof ↗
“Build a custom onboarding UI and submit seller data via API requests”
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the formsfullproof ↗
“Use an Adyen-hosted onboarding page that manages the flow and UI for you”
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the formsfullproof ↗
“Manage legal entities (KYB/KYC data) through the Legal Entity Management API”
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the formsfullproof ↗
“Create balance accounts manually via the Configuration API”
The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the pennypartialproof ↗
“Provide instructions to split payments and chargebacks directly on API endpoint calls”
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objectspartialproof ↗
“Choose between three different methods for handling chargeback events”
Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automaticallypartialproof ↗
“Create a managed payout schedule applied to balance accounts sharing a location and currency”
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per sellerfullproof ↗
“Subscribe to webhooks instead of polling for status changes on async processes”
“Test different transaction types against the integration using sandbox test credentials”
Test against a sandbox environment without touching production datafullproof ↗
“Control fees and monetize payments as a competitive edge, managed via the Adyen Dashboard”
Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costspartialproof ↗
“Set custom settlement/payout times and combine with CashOut for instant fund access”
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per sellerfullproof ↗
Contradicted (1)
“Onboard sellers globally with a single integration while Adyen handles verification and payouts”
Sellers can join from where they are — supported onboarding countries, local payment methods, and local-currency settlement documented as a coverage map, not discovered ticket by ticketnoneproof ↗
Undersold (19)
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Run the product headlessly / in CI for automationpartialproof ↗
Drive the product through a documented public APIfullproof ↗
Set up automations that run autonomously in the backgroundpartialproof ↗
Define rules that trigger actions automatically on eventspartialproof ↗
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brandpartialproof ↗
In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online paymentspartialproof ↗
Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting mepartialproof ↗
Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documentedpartialproof ↗
International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wirespartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatformingpartialproof ↗
An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfacespartialproof ↗
An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentialspartialproof ↗
Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accountspartialproof ↗
I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spreadpartialproof ↗
Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per sellerpartialproof ↗
Business model
Interchange++ card pricing plus a fixed per-transaction processing fee and method-specific fees; no setup or monthly fees; platform-specific terms (payout and onboarding economics) are sales-negotiated, not published.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
