Stripe Connect vs Mangopay

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Mangopay
   Stripe Connect✓fullprobed8/10

   Evidence confirms an llms.txt file is live at docs.stripe.com/llms.txt (HTTP 200) alongside markdown-formatted docs pages (e.g., connect.md) accessible for agent consumption, directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: no explicit documentation describing llms.txt's intended use/structure for agents, and no independent third-party confirmation of agent usage beyond the probe.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/connect.md # Platforms and marketplaces with Stripe Connect Build a SaaS platform or mar…”

   proof ↗⚑ flag

   Mangopay✓fullprobed9/10

   Mangopay provides a confirmed llms.txt (HTTP 200) explicitly instructing AI agents on retrieving clean Markdown docs, plus a documented OpenAPI spec and even an MCP server endpoint, directly enabling an agent to be pointed at agent-oriented docs. Missing for 10: independent/community confirmation of actual agent usage against these endpoints.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mangopay.com/llms.txt # Mangopay docs ## Instructions for AI Agents - For clean Markdown of any p…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.mangopay.com/_mcp/server”
   • [claimed-docs] “Send custom text to appear on the user's bank statement for a payment on your platform.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Stripe Connect~partialprobed6/10

   Stripe Connect is fundamentally API-driven (API onboarding, webhooks, testing docs) and ships an official CLI, both of which support headless/CI automation, but there is no explicit documentation or example of running it in a CI pipeline or scripted automation context. missing for 10: explicit CI/CD examples, automation-focused docs, independent evidence of CI usage.

   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Before going live, test your Connect integration for account creation, identity verification, and payouts.”
   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Mangopay~partialprobed6/10

   Mangopay is a REST API/SDK payments platform with a documented OpenAPI spec, sandbox, and multi-language SDKs, which naturally supports headless/CI automation (scripted API calls, no UI required). However, there is no explicit evidence of CI-specific tooling, CLI, test automation examples, or hands-on confirmation of running it in a CI pipeline. missing for 10: dedicated CLI or CI/CD integration guide, hands-on CI pipeline examples, independent confirmation of headless automation workflows.

   • [claimed-docs] “Start calling the Sandbox API to explore all Mangopay's features”
   • [claimed-docs] “Get started in your language: Node.js PHP Python .NET Java Ruby”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Stripe Connect✓fullprobed7/10

   Stripe documents an official MCP server at docs.stripe.com/mcp, confirming agents can connect via a first-party MCP endpoint; Stripe is a payments platform (not itself an agent), so the axis applies and is satisfied. Missing for 10: no detail on Connect-specific MCP tool coverage, no independent/hands-on corroboration of the MCP server working with Connect operations.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Mangopay✓fullprobed7/10

   Mangopay is a payments API platform (not an agent itself), so publishing an official MCP server is a valid axis; evidence shows a documented official MCP server endpoint at docs.mangopay.com/_mcp/server alongside llms.txt and OpenAPI probes confirming AI-native tooling support. Missing for 10: no independent/hands-on confirmation of connecting an agent to this MCP server, and no detail on its tool coverage or setup docs beyond the endpoint existing.

   • [probe] “official MCP server documented at https://docs.mangopay.com/_mcp/server”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mangopay.com/llms.txt # Mangopay docs ## Instructions for AI Agents - For clean Markdown of any p…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Stripe Connect
   Stripe Connect✓fullprobed7/10

   Stripe documents an official CLI (stripe-cli) that supports platform-wide API workflows including Connect, giving AI-native users a scriptable interface. missing for 10: no direct evidence the CLI has AI-native/agentic features (e.g., natural-language mode) or independent hands-on validation of CLI usage specifically for Connect workflows.

   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Mangopay—none0/10

   No evidence of an official CLI tool; only SDKs in multiple languages, docs, and an MCP server are mentioned, none of which constitute a CLI.

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Mangopay
   Stripe Connect✓fullprobed8/10

   Stripe Connect is fully driven through Stripe's documented public REST API (account creation, onboarding, charges, payouts, balances, webhooks) per docs, and probes confirm an official CLI and MCP server exist for programmatic/agentic access. missing for 10: no direct OpenAPI spec discovery (probe found 404s on standard OpenAPI paths) and no independent hands-on validation of AI-agent-driven API usage specifically.

   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Mangopay✓fullprobed9/10

   Mangopay provides a documented public REST API with OpenAPI spec, SDKs in multiple languages, sandbox environment, and confirmed live openapi.json endpoint, clearly supporting programmatic/AI-driven use. Missing for 10: independent third-party confirmation of AI-agent usage in production beyond vendor docs/probes.

   • [claimed-docs] “Start calling the Sandbox API to explore all Mangopay's features”
   • [claimed-docs] “Get started in your language: Node.js PHP Python .NET Java Ruby”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mangopay.com/llms.txt # Mangopay docs ## Instructions for AI Agents - For clean Markdown of any p…”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Mangopay
   Stripe Connect~partialprobed6/10

   Evidence shows Stripe Connect exposes a full API (docs-5, docs-6) and references official package distribution via npm (probe-1), plus AI-friendly docs (llms.txt) and an official MCP server/CLI (probe-4, probe-5), all of which support AI-native SDK-based development. However, the pack never explicitly documents a dedicated 'Official SDKs' page or lists supported languages, so the SDK claim is inferred rather than directly evidenced. missing for 10: explicit official SDK/library documentation page, multi-language SDK examples, independent developer confirmation of SDK usage for Connect specifically.

   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Create a charge and split payments between your platform and your sellers or service providers.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Mangopay✓fullprobed8/10

   Mangopay documents official SDKs across Node.js, PHP, Python, .NET, Java, and Ruby, plus a public OpenAPI spec, giving AI-native users concrete language-specific starting points and machine-readable API definitions to build against. Missing for 10: independent/hands-on developer corroboration of SDK quality or GitHub repo activity beyond docs claims.

   • [claimed-docs] “Get started in your language: Node.js PHP Python .NET Java Ruby”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Start calling the Sandbox API to explore all Mangopay's features”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Mangopay
   Stripe Connect✓fullcommunity7/10

   Stripe Connect has documented webhook support explicitly for Connect events ('All Connect integrations should establish a webhook endpoint to listen for Connect events'), and community evidence confirms real-world usage ('The webhooks are great'). This covers the core subscribe-to-events capability. Missing for 10: explicit documentation of event types/payload schema in this pack, agentic/AI-native framing of webhook consumption, and independent verification of reliability at scale.

   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [community] “'I implemented stripe connect on donat.io and it is awesome! The webhooks are great and the oauth flow is super simple too.'”

   proof ↗⚑ flag

   Mangopay✓fullprobed8/10

   Mangopay documents a clear webhook subscription system for event notifications on API objects, configurable via Dashboard or API, which supports agentic/automated integration patterns; docs are also machine-readable (llms.txt, OpenAPI, MCP server) aiding AI-native consumption. Missing for 10: explicit documentation of programmatic webhook creation via API (only Dashboard flow shown) and no independent/hands-on confirmation of webhook reliability.

   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mangopay.com/llms.txt # Mangopay docs ## Instructions for AI Agents - For clean Markdown of any p…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Stripe Connect~partialprobed4/10

   Stripe Connect supports background, event-driven automation via scheduled automatic payouts and webhooks for Connect events, and an official MCP server exists for AI agent integration, but there is no documentation of end-users setting up autonomous AI-driven automations or agent workflows built on Connect. missing for 10: explicit AI-agent automation setup, orchestration/scheduling controls beyond payouts, evidence of autonomous background AI workflows using Connect.

   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Mangopay~partialclaimed4/10

   Mangopay offers webhooks for event-driven notifications and an API/SDKs that could be used to build background automations like automated payouts and fraud checks, but there is no evidence of a native scheduling, workflow, or agentic automation framework that runs autonomously without external orchestration. missing for 10: no first-party automation/scheduler product, no evidence of autonomous background job execution, no documented agent/automation orchestration layer beyond webhooks and API calls.

   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”
   • [claimed-docs] “Automate order processing and payouts for your Mirakl marketplace”
   • [claimed-docs] “Define custom logic to detect and mitigate fraud attempts on your platform”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Stripe Connect~partialprobed5/10

   Stripe documents an official MCP server (docs.stripe.com/mcp) which would let AI agents interact with Stripe Connect via natural-language-driven tool calls, and also has an official CLI, but the evidence pack gives no detail on what Connect-specific actions are exposed via MCP or any hands-on confirmation of natural-language operation. missing for 10: details on MCP tool coverage for Connect operations, independent/hands-on validation of natural-language control, and confirmation beyond a bare 'documented at URL' probe.

   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Mangopay~partialprobed5/10

   Mangopay documents an official MCP server (mangopay-probe-3) and an llms.txt with agent-oriented instructions (mangopay-probe-1), which enables AI agents to invoke Mangopay's API via natural-language-mediated tool calls rather than raw SDK code. However there is no direct evidence of a natural-language command interface, chat-based operation, or hands-on confirmation that this works end-to-end. Missing for 10: evidence of actual NL command usage/testing, documentation of specific MCP tools exposed, and any user-facing chat/agent interface beyond the MCP endpoint declaration.

   • [probe] “official MCP server documented at https://docs.mangopay.com/_mcp/server”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mangopay.com/llms.txt # Mangopay docs ## Instructions for AI Agents - For clean Markdown of any p…”
   • [claimed-docs] “Get started in your language: Node.js PHP Python .NET Java Ruby”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Mangopay
   Stripe Connect—none0/10

   The evidence pack contains only docs.stripe.com guide pages, an llms.txt probe, CLI/MCP mentions, and a failed openapi.json probe (404 on all candidate paths) — nothing documents an interactive API reference page or runnable/try-it code examples for Connect. Since this is a fair expectation for an API-first product, absence of evidence yields 'none' rather than 'na'.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stripe.com/llms.txt # Stripe Documentation When installing Stripe packages, always check the npm r…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.stripe.com/connect.md # Platforms and marketplaces with Stripe Connect Build a SaaS platform or mar…”

   proof ↗⚑ flag

   Mangopay~partialprobed6/10

   Mangopay provides sandbox API access, a documented OpenAPI spec, and multi-language getting-started guides, indicating a functional API reference; there's no explicit evidence of an interactive 'try it now' console with runnable examples embedded in the docs UI. missing for 10: explicit interactive try-it-now console evidence, independent hands-on confirmation of runnable examples in the reference itself.

   • [claimed-docs] “Start calling the Sandbox API to explore all Mangopay's features”
   • [claimed-docs] “Get started in your language: Node.js PHP Python .NET Java Ruby”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mangopay.com/llms.txt # Mangopay docs ## Instructions for AI Agents - For clean Markdown of any p…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Mangopay
   Stripe Connect—none0/10

   The evidence pack shows a direct probe for OpenAPI/swagger spec files at all standard locations returning 404, and no other evidence item shows a downloadable machine-readable API spec (only markdown docs, an MCP server, and CLI are documented).

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stripe.com/openapi.json, https://docs.stripe.com/swagger.json, https://docs.stripe.com/…”

   proof ↗⚑ flag

   Mangopay✓fullprobed9/10

   A live probe confirms an OpenAPI JSON spec is served at https://docs.mangopay.com/openapi.json returning HTTP 200 with an "openapi" key, directly satisfying the machine-readable spec requirement. Missing for 10: independent third-party confirmation or documentation explicitly advertising the OpenAPI download link in the docs UI.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Mangopay
   Stripe Connect~partialclaimed6/10

   Docs explicitly cover testing the Connect integration (account creation, identity verification, payouts) before going live, implying a sandbox/test-mode workflow, but there's no explicit description of a dedicated 'sandbox environment' distinct from production, no mention of test API keys/test clocks, or how AI agents would interact with it. missing for 10: explicit sandbox/test-mode documentation separate from production, test data isolation details, and independent/hands-on confirmation of sandbox usage.

   • [claimed-docs] “Before going live, test your Connect integration for account creation, identity verification, and payouts.”
   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”

   proof ↗⚑ flag

   Mangopay✓fullclaimed8/10

   Mangopay docs explicitly describe a dedicated Sandbox API with simulated test payments, test payment methods (e.g., 3DS2 test cards), and accept/refuse payin simulation flows, allowing full testing without touching production data. Missing for 10: no independent/hands-on confirmation of sandbox-to-production parity or explicit data isolation guarantees beyond docs.

   • [claimed-docs] “Simulate a test payment to get funds on a Mangopay wallet”
   • [claimed-docs] “Start calling the Sandbox API to explore all Mangopay's features”
   • [claimed-docs] “The following card triggers a 3DS2 challenge flow, where SCA is required.”
   • [claimed-docs] “Select ***Accept the payin*** (or ***Refuse the payin***) and click ***Submit***.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Stripe Connect—none0/10

   The evidence pack contains no mention of API versioning, version headers, or a documented deprecation policy for Stripe Connect's APIs; all citations describe product features (onboarding, payouts, disputes, etc.) rather than API lifecycle/versioning practices. Missing for 10: any documentation of API version pinning, deprecation notices, changelog, or migration guides.

   ⚑ flag

   Mangopay—none0/10

   Evidence shows an OpenAPI spec and sandbox API docs, but there is no mention of API versioning scheme or a documented deprecation policy anywhere in the pack. missing for 10: explicit API version numbering/headers, changelog of breaking changes, documented deprecation timeline/policy.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Stripe Connect—none0/10

   Stripe Connect exposes per-resource APIs (accounts, payouts, balances) but nothing in the evidence pack describes bulk/batch operations across many connected accounts or transactions at once (e.g., batch create, bulk payout, multi-object update endpoints). Missing for 10: documented bulk/batch API endpoints, evidence of batch job or async bulk-processing tooling, and any AI-native automation examples operating on many items simultaneously.

   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”

   proof ↗⚑ flag

   Mangopay—none0/10

   Evidence covers individual API operations (wallets, payouts, disputes, webhooks) but no documentation of batch/bulk endpoints, multi-item transaction processing, or bulk automation tooling for AI-native workflows. Absence of evidence for this applicable capability yields none. missing for 10: bulk/batch API endpoints, batch payout or transfer operations, evidence of processing many items in a single call.

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Stripe Connect~partialclaimed5/10

   Stripe Connect supports event-driven automation via webhooks (e.g. listening for account, payout, dispute events) and built-in automatic/scheduled payouts, but these require the platform to write custom webhook handlers rather than a declarative 'if-this-then-that' rules engine; the only no-code rule configuration mentioned is for pricing strategies, not general event-action automation. Missing for 10: a documented no-code/rules-based automation builder for arbitrary event-to-action mappings, and evidence of AI-native rule definition tooling.

   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “Connect platforms and marketplaces can allow their connected accounts to access their balances immediately following a successful charge.”
   • [claimed-docs] “platforms can implement a range of pricing strategies for different payment processing use-cases, without the need to write any code”

   proof ↗⚑ flag

   Mangopay~partialclaimed5/10

   Mangopay provides webhooks that notify external systems on API object events, and documents 'custom logic to detect and mitigate fraud attempts', plus automatic fee/dispute deductions, showing some event-driven automation. However, there's no evidence of a native rules-definition interface or workflow engine letting users declare 'if event X then action Y' logic within Mangopay itself—automation is limited to webhook notifications that require external code to act. Missing for 10: a documented rules/workflow builder, conditional trigger-action configuration UI, and evidence of built-in automated actions beyond webhooks and fee/dispute processing.

   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”
   • [claimed-docs] “Define custom logic to detect and mitigate fraud attempts on your platform”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Stripe Connect—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Mangopay—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Embedded components

1. developerSeller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand

   weight 2 · round drawn
   Stripe Connect~partialclaimed6/10

   Stripe Connect exposes APIs for connected-account balances, payout scheduling/management, and transaction data (docs-7, docs-13, docs-18), and documents an embeddable onboarding component that lives inside the platform's own app (docs-4), supporting the general idea of white-labeled seller surfaces. However, the evidence pack only shows an embedded UI component for onboarding, not for balances, payouts, or transaction history themselves — those are described as raw APIs the developer must build UI around, not turnkey embeddable components. missing for 10: explicit documentation of embeddable balance/payout/transaction-history components (vs. only onboarding), and independent confirmation these render fully white-labeled inside a host app.

   • [claimed-docs] “You embed the Account onboarding component directly in your application and your connected accounts go through the onboarding flow without l…”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”

   proof ↗⚑ flag

   Mangopay~partialclaimed6/10

   Mangopay provides robust wallet, payout, and transaction APIs (docs-5, docs-6, docs-11, docs-18/19) that let developers build branded balance/payout/history experiences, plus webhooks for real-time updates (docs-14/15) — satisfying the 'APIs' half of the story. However, there is no evidence of prebuilt white-label UI components/widgets for embedding these surfaces directly, only raw API access and a dashboard for the platform itself. Missing for 10: documented drop-in UI components/widgets for balances/payouts/history, evidence of front-end SDKs for seller-facing embedding, and independent confirmation of embedding in production.

   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”
   • [claimed-docs] “Send funds locally and internationally in 24+ currencies”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”
   • [claimed-docs] “Mangopay always attempts to use the domestic rail if the currency and country correspond.”
   • [claimed-docs] “Mangopay applies a smart routing logic to always use the domestic rail if a local currency is sent, thereby optimizing routing costs and spe…”

   proof ↗⚑ flag

Omnichannel

1. founder with offline sellersIn-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments

   weight 2 · round drawn
   Stripe Connect—none0/10

   The evidence pack covers Connect's online payment splitting, onboarding, payouts, identity verification, and dashboard features, but contains no mention of Stripe Terminal, in-person/tap-to-pay hardware or SDKs, or how such in-person payments would settle into the same connected-account balances/reporting as online charges. This is an applicable axis for a payments platform (Stripe does offer Terminal separately), so absence of evidence here yields 'none' rather than 'na'.

   ⚑ flag

   Mangopay—none0/10

   Evidence pack covers wallets, payouts, FX, disputes, webhooks, and online payin testing, but there is no mention of physical POS terminals or tap-to-pay/in-person SDKs that settle into the same wallet/balance system as online payments. Missing for 10: any documentation of terminal hardware, in-person card-present SDKs, or unified online/offline settlement flows.

   ⚑ flag

Seller reporting

1. ops userSellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me

   weight 2 · round drawn
   Stripe Connect—none0/10

   The evidence only shows platform-level Dashboard management, balance API calls, and payout scheduling for connected accounts — all requiring developer/ops involvement, not self-serve seller statements, reconciliation reports, or bookkeeper-ready exports. No mention of an Express-style seller dashboard, downloadable statements, or export tooling that would let sellers or their bookkeepers close the books without contacting the platform ops team. Missing for 10: seller-facing statement/export UI, reconciliation report generation, bookkeeper self-serve documentation.

   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”

   proof ↗⚑ flag

   Mangopay—none0/10

   The evidence pack covers wallets, payouts, disputes, webhooks, and FX/routing infrastructure, but contains no mention of seller-facing statements, payout reconciliation reports, or bookkeeper-ready exports that would let sellers self-serve without contacting ops. This is a fair axis for a marketplace payments platform, but no supporting documentation or feature reference exists in the pack.

   ⚑ flag

Holds release

1. developerFunds 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

   weight 2 · round to Mangopay
   Stripe Connect~partialcommunity5/10

   Stripe Connect docs confirm the underlying primitives needed for escrow-like fund holding — connected-account balances can be checked via API (docs-18), payout timing can be scheduled or set to manual (docs-13), and dispute visibility exists in the Dashboard (docs-17) — meaning a developer can technically hold funds until a trigger and then release a payout on demand. However, there is no dedicated 'escrow' feature or documentation describing dispute-window-specific holds, delivery-triggered releases, or the compliance limits of doing so; a community thread even raises unresolved compliance concerns about using transfer holds to delay payouts (stripe-connect-comm-13), which is a caveat rather than a proven failure. missing for 10: explicit escrow/hold-until-trigger documentation, dispute-window-specific release mechanics, and clarified compliance limits for manually delaying payouts.

   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [claimed-docs] “Connect platforms and marketplaces can allow their connected accounts to access their balances immediately following a successful charge.”
   • [community] “Compliance concern raised: using a 'Special Case Transfer' to let money sit before payout 'seems non-compliant', asking when charges could a…”

   proof ↗⚑ flag

   Mangopay~partialclaimed7/10

   Mangopay's wallet infrastructure explicitly supports holding funds indefinitely ('as long as needed') and releasing them via API/webhook-triggered events, with dispute/chargeback mechanics documented separately, which together give escrow-like fund-holding and release-on-trigger behavior. However the evidence doesn't show a dedicated 'escrow' product or documented limits (max hold duration, fees for holding, delivery-window-specific triggers) as a unified concept. Missing for 10: explicit escrow/hold-duration limits documentation, a named delivery/dispute-window release mechanism, and independent verification of this workflow in practice.

   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”
   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”

   proof ↗⚑ flag

Negative balances

1. finance leadRefunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented

   weight 2 · round to Mangopay
   Stripe Connect—none0/10

   The evidence pack shows Connect supports viewing disputes (docs-17) and checking connected-account balances (docs-18), but nothing documents automatic debiting of future earnings or a connected account's bank account to cover refunds/chargebacks that exceed balance, nor any documented liability ordering. missing for 10: negative balance recovery/debit mechanics, bank-account debit fallback, documented liability order between platform and seller.

   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”

   proof ↗⚑ flag

   Mangopay~partialclaimed5/10

   Mangopay's dispute/e-wallet docs confirm that chargebacks trigger automatic fund deduction from the wallet and create a contestable dispute settled with Mangopay, showing some liability handling ([mangopay-docs-12], [mangopay-docs-13]). However, there is no documented mechanism for recovering shortfalls beyond wallet balance via automatic debits against future earnings or the seller's linked bank account, nor an explicit documented liability order/waterfall for such recovery. Missing for 10: explicit negative-balance recovery via future payouts, bank debit/clawback mechanics, and a documented liability order beyond the basic dispute-contest flow.

   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”

   proof ↗⚑ flag

Splits

1. developerSplit 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

   weight 3 · round to Stripe Connect
   Stripe Connect~partialclaimed7/10

   Docs clearly show charges can be split between platform and connected accounts as first-class API objects (docs-6, docs-7), with balances and payouts manageable per account (docs-18, docs-13). However, the evidence pack lacks explicit documentation of reversing or adjusting a split after the fact (e.g., reversing transfers or partial refunds tied to application fees), only touching disputes generally (docs-17). missing for 10: explicit reversal/adjustment API documentation, independent hands-on confirmation of split modification.

   • [claimed-docs] “Create a charge and split payments between your platform and your sellers or service providers.”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”

   proof ↗⚑ flag

   Mangopay~partialclaimed6/10

   Mangopay's wallet infrastructure explicitly supports receiving, holding, splitting and transferring funds across an unlimited number of wallets, with platform fees automatically routed to the platform's bank account, which enables multi-party fund routing and fee-taking (docs-5, docs-10, docs-11). However, evidence does not detail a first-class 'split payment' API object, nor explicit mechanisms to adjust or reverse a split after the fact beyond generic dispute/chargeback handling (docs-12, docs-13) which addresses refunds, not split adjustment. Missing for 10: explicit API object/documentation for defining a payment split across multiple recipients in one transaction, and documented reversal/adjustment of that split specifically (not just wallet transfers or chargebacks).

   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”

   proof ↗⚑ flag

Dispute handling

1. ops userDisputes 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

   weight 3 · round drawn
   Stripe Connect~partialclaimed5/10

   Docs confirm disputes are tracked per connected account and viewable in the Dashboard for both platform and connected accounts, supporting the 'right sub-merchant' targeting (stripe-connect-docs-17), and connected-account balance retrieval exists (stripe-connect-docs-18). However, the evidence pack lacks explicit documentation of submitting dispute evidence via API/dashboard for connected accounts or confirmation that dispute outcomes automatically adjust seller balances. missing for 10: dedicated evidence-submission API/dashboard flow for connected-account disputes, and explicit description of automatic balance reconciliation post-dispute-resolution.

   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”

   proof ↗⚑ flag

   Mangopay~partialclaimed5/10

   Docs confirm that disputes/chargebacks are tied to a wallet's user (i.e., per-seller) and that funds are automatically deducted and can be contested with proof (mangopay-docs-12, mangopay-docs-13), and wallets are per-platform-user (mangopay-docs-11), implying per-sub-merchant handling. However, there is no explicit documentation of an API or dashboard workflow for submitting dispute evidence, nor confirmation that outcomes automatically reconcile back into seller balances beyond the initial deduction. Missing for 10: explicit evidence-submission API/dashboard flow, confirmation of sub-merchant-specific dispute routing, and automatic balance reconciliation after outcome.

   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”

   proof ↗⚑ flag

Portfolio risk

1. ops userWatch 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

   weight 2 · round drawn
   Stripe Connect~partialclaimed4/10

   Docs confirm identity verification for risk reduction, a Dashboard to review/manage connected accounts and take action, and visibility into disputes across the platform — core building blocks for portfolio risk oversight. However there is no evidence of per-seller fraud/credit-risk scoring, automated anomaly alerts, or explicit payout-pause/offboarding workflows for bad actors. missing for 10: per-merchant fraud/credit-risk scoring, anomalous-seller alerting, explicit pause-payout/offboard tooling, independent evidence these risk tools work in practice.

   • [claimed-docs] “Use identity verification to reduce risk on your platform when using Connect.”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”

   proof ↗⚑ flag

   Mangopay~partialclaimed4/10

   Mangopay docs show custom fraud-detection logic, dispute/chargeback handling, and webhook event notifications that could support risk monitoring, but there is no evidence of a per-sub-merchant risk dashboard, anomaly alerts across a seller portfolio, or explicit tools to pause payouts/offboard bad actors. missing for 10: portfolio-level risk dashboard per sub-merchant, anomaly/alerting system for sellers, payout-pause or offboarding workflow.

   • [claimed-docs] “Define custom logic to detect and mitigate fraud attempts on your platform”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”
   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”

   proof ↗⚑ flag

Cross border

1. finance leadInternational sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires

   weight 2 · round to Mangopay
   Stripe Connect~partialcommunity3/10

   Docs confirm platforms can pay out to connected accounts, schedule payouts, and check connected-account balances, and one community comment praises Stripe Connect for enabling international marketplace payouts, but the pack contains no explicit documentation of local-currency payout rails, FX conversion mechanics, or settlement to local bank rails versus wires. An older community complaint even flags lack of international support as a pain point. missing for 10: dedicated docs on multi-currency payouts, FX conversion/fee transparency, and local bank-rail settlement for connected accounts.

   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [community] “Frustration over lack of international support: 'I love Stripe. Really I do. But until I can accept users from around the world, it seems pr…”
   • [community] “'current balanced customer who is soon to be a stripe convert. very thrilled about this and being able to payout internationally as a market…”

   proof ↗⚑ flag

   Mangopay✓fullclaimed7/10

   Docs explicitly describe local-currency payouts via domestic bank rails (smart routing prioritizing domestic rail over wire), multi-currency sends in 24+ currencies, and embedded FX conversion for global markets, directly matching the finance-lead story. missing for 10: no explicit documented FX rate/markup transparency or fee schedule, and no independent/hands-on confirmation of settlement times or local rail coverage per country.

   • [claimed-docs] “Mangopay always attempts to use the domestic rail if the currency and country correspond.”
   • [claimed-docs] “Mangopay applies a smart routing logic to always use the domestic rail if a local currency is sent, thereby optimizing routing costs and spe…”
   • [claimed-docs] “Send funds locally and internationally in 24+ currencies”
   • [claimed-docs] “Reach global markets by seamlessly embedding FX conversions in your workflow”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”

   proof ↗⚑ flag

Payout schedules

1. ops userPayouts 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

   weight 3 · round to Stripe Connect
   Stripe Connect✓fullclaimed8/10

   Docs explicitly cover configurable automatic payout scheduling per connected account (daily/weekly/monthly/manual) and instant payouts to cards/real-time rails where supported, matching the story's core requirements. Missing for 10: no explicit confirmation that schedule can be set independently per-seller at scale with concrete examples, and no independent/hands-on corroboration of the scheduling flexibility beyond docs.

   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “Connect platforms and marketplaces can allow their connected accounts to access their balances immediately following a successful charge.”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”

   proof ↗⚑ flag

   Mangopay—none0/10

   The evidence covers wallet infrastructure, payout routing rails (domestic vs cross-border), and platform fee wiring, but contains no mention of configurable payout schedules (daily/weekly/monthly/manual) per seller, nor instant payouts to cards or real-time rails. Missing for 10: any documentation of per-seller payout scheduling, manual vs automatic payout triggers, or instant/real-time payout options.

   • [claimed-docs] “Mangopay always attempts to use the domestic rail if the currency and country correspond.”
   • [claimed-docs] “Mangopay applies a smart routing logic to always use the domestic rail if a local currency is sent, thereby optimizing routing costs and spe…”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Stripe Connect
   Stripe Connect~partialprobed7/10

   Docs show Stripe Connect exposes nearly all platform operations (account creation, onboarding, charges, payouts, treasury, cards, balances, webhooks) via API, including an explicit 'API onboarding' path as an alternative to the embedded UI component (stripe-connect-docs-5), and CLI/MCP tooling further extend programmatic control (stripe-connect-probe-4, stripe-connect-probe-5). However, some capabilities like dispute review, account management, and no-code pricing tools are documented as Dashboard-centric (stripe-connect-docs-9, stripe-connect-docs-17, stripe-connect-docs-8) without explicit confirmation that every such action has a full API equivalent. Missing for 10: explicit documentation confirming 1:1 API parity for dispute resolution/dashboard review actions, and independent/hands-on confirmation that no UI-only feature exists.

   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [claimed-docs] “platforms can implement a range of pricing strategies for different payment processing use-cases, without the need to write any code”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Mangopay~partialprobed6/10

   Mangopay is API-first: docs show a full OpenAPI spec, sandbox API, and API-driven wallet, payout, dispute, and webhook management, suggesting broad functional parity. However, some flows (e.g., webhook setup, dispute proof submission) are documented via the Dashboard UI as an alternative path, and there is no explicit claim that all Dashboard actions are always mirrored in the API. Missing for 10: explicit statement of full UI/API parity, and evidence that dashboard-only admin actions (e.g., dispute contestation, account config) are fully API-accessible.

   • [claimed-docs] “Start calling the Sandbox API to explore all Mangopay's features”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”
   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”

   proof ↗⚑ flag

Graduation path

1. founderThere's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming

   weight 2 · round to Stripe Connect
   Stripe Connect~partialclaimed4/10

   Docs show Connect offers a spectrum of control—managed onboarding vs. custom API onboarding, unified identity with multiple account configurations (merchant/customer), and platform-level control over payouts, pricing, and balances—implying a platform can grow from a lighter-touch managed setup toward more direct control without switching providers. However, there is no explicit documentation of a formal path to registered payment-facilitator (PayFac) status, its licensing/economics implications, or how liability shifts as a platform matures. missing for 10: explicit PayFac registration/graduation path, documentation on liability shift and licensing requirements, case studies of platforms moving from managed to PayFac model without replatforming.

   • [claimed-docs] “Create a unified identity to represent each of your platform's connected accounts with one or more configurations, such as merchant or custo…”
   • [claimed-docs] “You embed the Account onboarding component directly in your application and your connected accounts go through the onboarding flow without l…”
   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”

   proof ↗⚑ flag

   Mangopay—none0/10

   No evidence describes a graduation path from managed/wallet model to registered payment-facilitator status with increased economics/control, nor any migration tooling or licensing tiers. Evidence only covers wallet infrastructure, payouts, disputes, and API onboarding — nothing about payfac-liability progression. Missing for 10: any mention of licensing tiers, BIN sponsorship, PF-of-record transition, or economics/control changes as platforms scale.

   ⚑ flag

Responsibility split

1. ops userThe 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

   weight 2 · round drawn
   Stripe Connect—none0/10

   The docs describe operational features (identity verification, dispute dashboards, payouts) but none explicitly lay out a responsibility matrix for who owns KYC/AML, card-network compliance, fraud losses, or seller misconduct — that allocation is left implicit or pushed to the underlying account agreement. Community evidence even shows a user unsure whether a specific payout pattern is compliant, underscoring the lack of a documented liability split.

   • [claimed-docs] “Use identity verification to reduce risk on your platform when using Connect.”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [community] “Compliance concern raised: using a 'Special Case Transfer' to let money sit before payout 'seems non-compliant', asking when charges could a…”

   proof ↗⚑ flag

   Mangopay—none0/10

   Docs mention compliance features (KYC guidance, fraud tooling, dispute/chargeback contestation) but nowhere is there an explicit ops-facing breakdown of who owns KYC/AML, card-network compliance, fraud losses, and seller misconduct versus Mangopay — it's scattered feature docs, not a liability-split reference.

   • [claimed-docs] “Manage your community of paying users in full compliance”
   • [claimed-docs] “Define custom logic to detect and mitigate fraud attempts on your platform”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”

   proof ↗⚑ flag

Tax forms

1. finance leadSeller tax reporting is handled — 1099-K thresholds tracked, forms generated, delivered, and filed, with the data corrections workflow documented

   weight 2 · round drawn
   Stripe Connect—none0/10

   The evidence pack covers onboarding, payments, payouts, disputes, identity verification, and treasury, but contains no mention of 1099-K tracking, tax form generation/delivery/filing, or a documented data corrections workflow for tax reporting.

   ⚑ flag

   Mangopay—none0/10

   No evidence in the pack references 1099-K thresholds, tax form generation/filing, or a tax data correction workflow; the docs cover wallets, payouts, disputes, webhooks, and FX but nothing about US tax reporting compliance. missing for 10: 1099-K threshold tracking, form generation/delivery/filing, corrections workflow documentation.

   ⚑ flag

Agent money ops

1. ai-native userAn agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces

   weight 2 · round drawn
   Stripe Connect~partialprobed7/10

   Stripe publishes concrete API-level surfaces an agent could use: retrieving a connected account's balance (stripe-connect-docs-18), managing/scheduling payouts (stripe-connect-docs-7, docs-13), viewing disputes (stripe-connect-docs-17), webhooks for investigating events (stripe-connect-docs-15), plus an official MCP server (stripe-connect-probe-4) and CLI (stripe-connect-probe-5) that give agents a documented, tool-callable interface rather than just human docs. However, the evidence only shows dispute *viewing* in the Dashboard, not an API/MCP-exposed workflow for drafting/submitting dispute evidence, and there's no hands-on proof of an agent actually chaining balance+payout+dispute calls to 'investigate a missing payout.' Missing for 10: documented dispute-evidence submission surface usable by an agent, and independent/hands-on evidence of an agent performing the described investigate-and-draft workflow via MCP/API.

   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”
   • [probe] “official CLI documented at https://docs.stripe.com/stripe-cli”

   proof ↗⚑ flag

   Mangopay~partialprobed7/10

   Mangopay ships genuinely agent-usable surfaces: a documented OpenAPI spec, llms.txt agent instructions, and an official MCP server, plus docs on wallets/balances, payouts (with domestic-rail routing details useful for investigating a delayed payout), and disputes/chargebacks (including contesting with proof, which maps to 'draft dispute evidence'). However there's no explicit example or endpoint description for reading balances/payout status programmatically or a worked 'investigate missing payout' or 'draft dispute evidence' agent workflow — these are inferred from adjacent guides rather than directly documented. Missing for 10: explicit balance/payout-status API examples, a documented dispute-evidence submission workflow, and independent/hands-on confirmation the MCP server actually exposes these operations.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.mangopay.com/_mcp/server”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “Mangopay always attempts to use the domestic rail if the currency and country correspond.”
   • [claimed-docs] “Mangopay applies a smart routing logic to always use the domestic rail if a local currency is sent, thereby optimizing routing costs and spe…”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”
   • [claimed-docs] “Send custom text to appear on the user's bank statement for a payment on your platform.”

   proof ↗⚑ flag

Agent onboarding

1. ai-native userAn 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

   weight 3 · round drawn
   Stripe Connect~partialprobed5/10

   Stripe Connect exposes full API surface for creating connected accounts, driving onboarding (embedded or API-based), and checking requirements via identity verification (docs-4, docs-5, docs-16), and Stripe documents an official MCP server (probe-4). However, there's no evidence the MCP server specifically exposes Connect account-creation/onboarding/requirements-due operations, nor any documentation of scoped credentials for agent-driven seller operations. Missing for 10: MCP tool list showing Connect account management functions, explicit scoped-credential/permission model for agents, and evidence of agents actually completing onboarding or resolving requirements-due states end-to-end.

   • [claimed-docs] “You embed the Account onboarding component directly in your application and your connected accounts go through the onboarding flow without l…”
   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Use identity verification to reduce risk on your platform when using Connect.”
   • [probe] “official MCP server documented at https://docs.stripe.com/mcp”

   proof ↗⚑ flag

   Mangopay~partialprobed5/10

   Mangopay exposes a full API (with OpenAPI) and an official MCP server, plus docs on managing users/accounts in compliance, which supports agent-driven seller operations in principle. However, no evidence explicitly documents onboarding completion flows, KYC 'requirements-due' status handling, or scoped/limited credentials for agent use via the MCP surface. missing for 10: explicit onboarding-completion workflow docs, requirements-due state handling, scoped-credential/permission model for agent access.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.mangopay.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.mangopay.com/_mcp/server”
   • [claimed-docs] “Manage your community of paying users in full compliance”
   • [claimed-docs] “Get started in your language: Node.js PHP Python .NET Java Ruby”

   proof ↗⚑ flag

Agentic commerce

1. developerThe 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

   weight 2 · round drawn
   Stripe Connect—none0/10

   Evidence covers standard Connect marketplace/split-payment functionality (charges, payouts, onboarding, balances) but contains no mention of agent-initiated checkout, agentic-commerce protocols, or delegated payment credentials for AI agent buyers. Missing for 10: any documentation of agent/AI buyer checkout support, delegated payment credential mechanisms, or agentic-commerce protocol integration with split funds.

   ⚑ flag

   Mangopay—none0/10

   No evidence of agent-initiated checkout, agentic-commerce protocols, or delegated payment credentials; documentation covers wallets, payouts, disputes, FX, and webhooks but nothing about AI/agent buyer flows integrated with split funds. Missing for 10: any mention of agent checkout protocols, delegated payment credential support, or agent-specific API/documentation tying to split funds flows.

   ⚑ flag

Funds custody

1. finance leadPlatform 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

   weight 2 · round to Stripe Connect
   Stripe Connect~partialcommunity4/10

   Docs show connected-account balance visibility, payout scheduling/instant payouts, and Treasury for holding funds and cash-back, giving a finance lead partial insight into where funds sit and payout timing. However there is no explicit documentation on how platform funds are legally segregated from Stripe's own accounts, nor clear policy on whether held balances earn yield/interest, and a community thread raises unresolved compliance questions about funds sitting via 'Special Case Transfer' before payout. missing for 10: explicit fund-segregation/custody disclosures, yield/interest policy on held balances, clear compliance answer to the raised concern.

   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Embed Treasury in your platform to allow your customers to hold funds, pay bills, earn cash back, and manage cashflow.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “Connect platforms and marketplaces can allow their connected accounts to access their balances immediately following a successful charge.”
   • [community] “Compliance concern raised: using a 'Special Case Transfer' to let money sit before payout 'seems non-compliant', asking when charges could a…”

   proof ↗⚑ flag

   Mangopay~partialclaimed3/10

   Docs confirm Mangopay's wallet infrastructure lets platforms hold, split and transfer funds and that platform fees are wired out monthly (mangopay-docs-5, mangopay-docs-10, mangopay-docs-11), giving some sense of where funds sit, but there is no evidence addressing regulatory fund segregation from Mangopay's own accounts or whether held balances earn yield. missing for 10: explicit safeguarding/segregation-of-client-funds statement, disclosure of interest/yield policy on wallet balances, third-party or regulatory confirmation of fund protection.

   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”

   proof ↗⚑ flag

Ledger visibility

1. finance leadThe 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

   weight 3 · round to Stripe Connect
   Stripe Connect~partialcommunity7/10

   Docs show core building blocks for ledger legibility: per-connected-account balance retrieval, charge splitting between platform and sellers, payout scheduling/management, and webhook events for tracking money movement, plus dispute visibility. However there's no explicit evidence of a dedicated reconciliation/reporting API or penny-level ledger export, and community threads flag real confusion over fee 'double dipping' and payout timing/compliance that complicate exact traceability. missing for 10: explicit reconciliation/reporting tooling (e.g. balance transaction reports), documented penny-accurate audit trail from charge→split→payout, and independent confirmation that finance teams can fully reconcile without extra tooling.

   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Create a charge and split payments between your platform and your sellers or service providers.”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “All Connect integrations should establish a webhook endpoint to listen for Connect events.”
   • [claimed-docs] “You can view all disputes filed against your platform and connected accounts in your Dashboard.”
   • [community] “User confusion over fee structure: 'If Stripe is charging 0.5% of funds paid out to managed accounts, does this mean you're "double dipping"…”
   • [community] “Compliance concern raised: using a 'Special Case Transfer' to let money sit before payout 'seems non-compliant', asking when charges could a…”

   proof ↗⚑ flag

   Mangopay~partialclaimed6/10

   Docs confirm wallet infrastructure supporting per-seller and platform fee wallets, automatic fee payout to bank, webhooks for event tracking (charge/payin, split/transfer, payout), and dispute/chargeback handling — the building blocks for traceability and reconciliation. However there is no explicit documentation of a unified ledger/reporting view, reconciliation reports, or per-penny audit trail tooling that a finance lead would use directly. Missing for 10: dedicated reconciliation/reporting API or dashboard view showing full charge-to-payout trace, statement/ledger export functionality, and independent confirmation that balances reconcile to the penny in practice.

   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “The funds are automatically deducted from this wallet and sent back to the user. A dispute is created which can be contested by the platform…”
   • [claimed-docs] “The platform may have the opportunity to contest the chargeback by providing proof prior to being requested to settle their credit to Mangop…”
   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”

   proof ↗⚑ flag

Recon exports

1. developerReconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule

   weight 2 · round to Stripe Connect
   Stripe Connect~partialclaimed4/10

   Docs show balance-per-account retrieval and payout scheduling APIs, which are building blocks for reconciliation, but there is no evidence of a dedicated reconciliation/reporting API, scheduled file exports, or rolled-up settlement reports designed for finance-stack consumption. Missing for 10: dedicated reporting/reconciliation API (e.g. Sigma or Reporting API), scheduled file delivery mechanism, explicit rolled-up multi-seller settlement report format, and any first-party or community evidence of automated reconciliation workflows.

   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [claimed-docs] “Schedule the frequency of automatic payouts”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”

   proof ↗⚑ flag

   Mangopay~partialclaimed3/10

   Mangopay's docs show wallet balances, automatic monthly fee wiring, and webhook event notifications that could feed a finance stack, but there is no explicit documentation of settlement/balance report files or scheduled per-seller reconciliation APIs. missing for 10: dedicated reconciliation/settlement report API or downloadable file exports, explicit per-seller rollup reporting, and evidence of scheduled delivery cadence.

   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”
   • [claimed-docs] “Mangopay provides a webhook feature to submit notifications to other applications whenever a specific event occurs for a specific API object…”
   • [claimed-docs] “If using the Dashboard, navigate to Developers > Webhooks > Add webhook, then select the event type and enter your URL.”

   proof ↗⚑ flag

Application fees

1. founderPayments 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

   weight 3 · round to Stripe Connect
   Stripe Connect~partialcommunity6/10

   Docs confirm the core mechanics of platform monetization: splitting charges to add an application fee (stripe-connect-docs-6), no-code pricing strategy tools for different sellers/use-cases (stripe-connect-docs-8), and balance/payout management per connected account (stripe-connect-docs-7, stripe-connect-docs-18). However, there is no explicit documentation of a dashboard or reporting view that separates platform application-fee revenue from Stripe's own processing costs, and community threads show real confusion over fee structure ('double dipping') rather than confirmation of clean revenue/cost separation. Missing for 10: explicit reporting/dashboard feature that isolates platform revenue vs. processing fees, and clearer documentation of per-seller custom pricing configuration beyond a general pricing-tools mention.

   • [claimed-docs] “Create a charge and split payments between your platform and your sellers or service providers.”
   • [claimed-docs] “platforms can implement a range of pricing strategies for different payment processing use-cases, without the need to write any code”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [community] “User confusion over fee structure: 'If Stripe is charging 0.5% of funds paid out to managed accounts, does this mean you're "double dipping"…”

   proof ↗⚑ flag

   Mangopay~partialclaimed5/10

   Mangopay's wallet infrastructure supports splitting funds and platforms have their fees automatically wired to their bank account monthly, which supports taking a fee/markup on transactions (mangopay-docs-5, mangopay-docs-10, mangopay-docs-11). However, there is no evidence of per-seller custom pricing configuration or of dashboard/reporting that separates fee revenue from processing costs. Missing for 10: per-seller/variable fee-setting documentation, dedicated revenue-vs-cost reporting/dashboard evidence, independent confirmation of fee mechanics in production.

   • [claimed-docs] “Leverage Mangopay's wallet infrastructure to receive, hold, split, and transfer funds”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”

   proof ↗⚑ flag

Buy rates

1. finance leadI 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

   weight 2 · round to Stripe Connect
   Stripe Connect~partialcommunity4/10

   Stripe Connect lets platforms split payments and set application/sell-side fees via 'platform pricing tools' and charge splitting, and Stripe's own processing rate is publicly documented, giving a documented buy rate and sell-rate freedom. However there is no evidence of interchange-level cost visibility or granular spread management — a community thread even shows confusion over Stripe's fee structure ('double dipping') rather than clear line-item interchange transparency. Missing for 10: interchange-level fee breakdown/reporting, documented spread/cost visibility tools, and evidence resolving the community confusion about fee stacking.

   • [claimed-docs] “Create a charge and split payments between your platform and your sellers or service providers.”
   • [claimed-docs] “platforms can implement a range of pricing strategies for different payment processing use-cases, without the need to write any code”
   • [claimed-docs] “To check the balance of a connected account, perform a retrieve balance call authenticated as the connected account.”
   • [community] “User confusion over fee structure: 'If Stripe is charging 0.5% of funds paid out to managed accounts, does this mean you're "double dipping"…”

   proof ↗⚑ flag

   Mangopay—none0/10

   The evidence shows only generic fee/wallet documentation (e.g., fees wired monthly, wallet infrastructure) but nothing about a documented buy rate, ability to set a sell rate, or interchange-level cost breakdown for spread management. Community comments merely speculate about overall pricing being surprisingly low, not about rate transparency or spread control tools.

   ⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Stripe Connect—none0/10

   No evidence in the pack mentions data residency, regional data storage, or configurable data location for Stripe Connect; the axis applies (payments platforms commonly address data residency for compliance) but no supporting documentation is present.

   ⚑ flag

   Mangopay—none0/10

   No evidence of data residency/region selection options in Mangopay's documentation or community reports; the evidence pack covers wallets, payouts, disputes, webhooks and testing but never mentions data storage location or residency choices.

   ⚑ flag

Global coverage

1. founderSellers 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

   weight 2 · round to Mangopay
   Stripe Connect—none0/10

   The evidence pack shows generic onboarding, identity-verification, and payout docs, but none of the citations reference a consolidated coverage map of supported onboarding countries, local payment methods, or local-currency settlement. In fact, community evidence points the other way: complaints about lack of international support and confusion between a blog post claiming broad country support and docs limiting it to US/Canada (comm-8, comm-10), suggesting coverage info is scattered rather than a single documented map. missing for 10: an explicit supported-countries list, a local-payment-methods matrix, and a local-currency settlement reference, plus confirmation these are unified rather than discovered piecemeal.

   • [community] “Frustration over lack of international support: 'I love Stripe. Really I do. But until I can accept users from around the world, it seems pr…”
   • [community] “Bug report: broken docs link for managed accounts showing 'An unexpected error occurred', and confusion between blog post saying managed acc…”

   proof ↗⚑ flag

   Mangopay~partialclaimed4/10

   Docs mention multi-currency payouts (24+ currencies), FX conversion, smart domestic-rail routing, and automated fee settlement, implying broad geographic/currency coverage, but there is no evidence of an explicit onboarding coverage map listing supported countries, KYC requirements per region, or local payment methods per market. Founders would still need to discover country-specific onboarding requirements piecemeal. missing for 10: a documented country/coverage map, list of supported local payment methods per country, explicit onboarding country list, independent confirmation of coverage claims.

   • [claimed-docs] “Send funds locally and internationally in 24+ currencies”
   • [claimed-docs] “Reach global markets by seamlessly embedding FX conversions in your workflow”
   • [claimed-docs] “Mangopay always attempts to use the domestic rail if the currency and country correspond.”
   • [claimed-docs] “Mangopay applies a smart routing logic to always use the domestic rail if a local currency is sent, thereby optimizing routing costs and spe…”
   • [claimed-docs] “Your fees are automatically wired to your bank account every month.”

   proof ↗⚑ flag

Onboarding api

1. developerOnboard 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

   weight 3 · round to Stripe Connect
   Stripe Connect✓fullcommunity8/10

   Docs explicitly describe both hosted onboarding (embeddable Account onboarding component) and full API onboarding for custom UIs, plus identity verification, bank account/external account linking, and payouts — covering KYC/KYB and bank linking needs without building forms. Community quotes (OAuth flow, webhooks) corroborate ease of onboarding, though some complaints about seller-facing friction and international limits reflect UX rather than capability gaps. Missing for 10: explicit mention of terms-of-service acceptance step in onboarding flow and more recent independent hands-on validation of the embedded components.

   • [claimed-docs] “You embed the Account onboarding component directly in your application and your connected accounts go through the onboarding flow without l…”
   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Use identity verification to reduce risk on your platform when using Connect.”
   • [claimed-docs] “Pay out to connected accounts: Manage payouts and external accounts for your connected accounts.”
   • [community] “'We've been using this for awhile for Zenbox... The implementation was straightforward, and it instantly made Stripe the easiest integration…”
   • [community] “'I implemented stripe connect on donat.io and it is awesome! The webhooks are great and the oauth flow is super simple too.'”

   proof ↗⚑ flag

   Mangopay—none0/10

   The evidence pack only vaguely references 'managing a community of paying users in full compliance' and wallet/payout infrastructure, but contains no documentation of KYB/KYC onboarding APIs, hosted onboarding flows, embeddable UI components, bank account linking, or terms-of-service acceptance mechanisms — the core elements of this story are entirely unevidenced.

   • [claimed-docs] “Manage your community of paying users in full compliance”

   proof ↗⚑ flag

Progressive requirements

1. ops userOnboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller

   weight 2 · round to Stripe Connect
   Stripe Connect~partialclaimed5/10

   Docs confirm flexible onboarding (embedded component or custom API-driven UI) and identity verification to reduce risk, which implies staged data collection, but no evidence explicitly describes tunable minimum-to-start thresholds or discrete 'requirements-due' states per seller. Missing for 10: explicit documentation of progressive/staggered requirement collection tied to payout thresholds, and clear surfacing of per-seller requirements-due status in the dashboard or API.

   • [claimed-docs] “You embed the Account onboarding component directly in your application and your connected accounts go through the onboarding flow without l…”
   • [claimed-docs] “API onboarding: You use the Stripe API to build your own customized onboarding UI.”
   • [claimed-docs] “Use identity verification to reduce risk on your platform when using Connect.”
   • [claimed-docs] “Manage connected accounts with the Dashboard: Review and take action on your connected accounts.”

   proof ↗⚑ flag

   Mangopay—none0/10

   The evidence only shows generic compliance and wallet/payout docs (e.g., mangopay-docs-4, mangopay-docs-11) but nothing about tiered/progressive KYC, minimum-to-start onboarding, or explicit requirements-due states tied to payout thresholds. Missing for 10: documentation of staged KYC levels, seller onboarding status states, and payout gating tied to verification completeness.

   • [claimed-docs] “Manage your community of paying users in full compliance”
   • [claimed-docs] “Platforms can create an unlimited number of wallets to hold funds as long as needed.”

   proof ↗⚑ flag