Finix vs Rainforest

Agent access

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

   weight 2 · round to Finix
   Finix✓fullprobed9/10

   Finix has a confirmed llms.txt endpoint returning HTTP 200 with a description of the docs, plus documented agent-oriented resources including an official MCP server for AI agents to query the API. This directly satisfies the story of pointing an agent at llms.txt or agent-oriented docs. Missing for 10: independent/community corroboration of actual agent usage against llms.txt or MCP server in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.finix.com/llms.txt # Finix Docs > Explore our documentation, guides, and APIs to start building yo…”
   • [probe] “official MCP server documented at https://docs.finix.com/additional-resources/developers/mcp-server”
   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”

   proof ↗⚑ flag

   Rainforest✓fullprobed8/10

   A probe confirms a live llms.txt file at docs.rainforestpay.com/llms.txt (HTTP 200) that explicitly documents the docs and notes pages can be fetched as .md, and multiple doc pages are indeed available with .md suffixes as referenced elsewhere in the pack. Missing for 10: no independent/third-party confirmation of agent usage with this llms.txt, and no evidence of a broader agent-oriented docs structure beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.rainforestpay.com/llms.txt # Rainforest Docs Documentation > Documentation for Rainforest Docs Ap…”
   • [claimed-docs] “Integrate Rainforest's low-code embeddable component into your platform, allowing me”
   • [claimed-docs] “Create a merchant with an initial merchant application.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Finix—none0/10

   Finix is a payments infrastructure API with developer docs, sandbox environments, and an MCP server for querying API docs, but there is no evidence of a CLI, SDK automation tool, or headless mode designed for CI/automation pipelines. missing for 10: CLI tool, CI/CD integration examples, headless automation documentation, evidence of running Finix operations in scripted/automated pipelines.

   ⚑ flag

   Rainforest—none0/10

   Rainforest exposes REST APIs and webhooks, which theoretically could be scripted, but there is no evidence of a CLI, headless mode, or CI-integration tooling — the docs focus on merchant onboarding, payment components, and pricing, not automation/agentic workflows. missing for 10: CLI or SDK for automation, explicit CI/headless usage examples, any agent/automation-oriented tooling.

   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

   weight 3 · round to Finix
   Finix✓fullprobed7/10

   Finix documents an official MCP server allowing AI agents to query the Finix API for accurate answers, confirmed by both docs and a probe hit on the dedicated mcp-server page. Missing for 10: no independent/hands-on corroboration of the MCP server working, and no detail on setup, transport, or tool coverage beyond the brief description.

   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”
   • [probe] “official MCP server documented at https://docs.finix.com/additional-resources/developers/mcp-server”

   proof ↗⚑ flag

   Rainforest—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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Finix—none0/10

   No evidence of an official CLI tool; Finix's docs cover APIs, Dashboard, and an MCP server but nothing about a command-line interface for developers.

   ⚑ flag

   Rainforest—none0/10

   No evidence of an official CLI tool anywhere in the docs or probes; the pack only covers REST API endpoints, webhooks, and embeddable components. Missing for 10: any mention of a CLI, its installation, or command reference.

   ⚑ flag

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

   weight 3 · round to Finix
   Finix✓fullprobed8/10

   Finix provides extensive documented public APIs for onboarding, payouts, disputes, subscriptions, and webhooks, plus a sandbox environment and an llms.txt discovery file for AI agents, showing clear support for programmatic/API-driven use. missing for 10: independent third-party hands-on confirmation of API usability, and more detail on API completeness/versioning beyond docs listing.

   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Use Finix's APIs to build your own custom onboarding experience for your sellers.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Webhooks let you receive notifications programmatically when your API resources are created or updated.”
   • [claimed-docs] “Finix provides separate Sandbox and Live accounts, along with the corresponding API credentials to access the Finix API.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.finix.com/llms.txt # Finix Docs > Explore our documentation, guides, and APIs to start building yo…”

   proof ↗⚑ flag

   Rainforest~partialprobed6/10

   Rainforest ships an extensive documented REST API (create/update merchant, webhooks, deposits, amount splits) with a reference doc site and an llms.txt for machine-readable docs access, showing a genuine public API surface. However, a probe for standard machine-discoverable API specs (OpenAPI/Swagger) returned 404s across all candidate paths, meaning there's no verified formal schema for automated/agentic API consumption. Missing for 10: a discoverable OpenAPI/Swagger spec, SDK/client library evidence, and explicit agent-tooling integration guidance.

   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.rainforestpay.com/llms.txt # Rainforest Docs Documentation > Documentation for Rainforest Docs Ap…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Finix—none0/10

   Finix docs mention separate Sandbox/Live API credentials but give no evidence of scoped or least-privilege credential issuance (e.g., role-based keys, permission scopes) for agent use cases; the MCP server doc is about querying API docs, not credential scoping.

   • [claimed-docs] “Finix provides separate Sandbox and Live accounts, along with the corresponding API credentials to access the Finix API.”
   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”

   proof ↗⚑ flag

   Rainforest—none0/10

   Rainforest is a payments-processing platform; evidence covers merchant onboarding, payments, webhooks, and pricing but no mention of scoped or least-privilege API credential issuance for agents, API key management, or permission scoping.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Finix—none0/10

   The evidence pack repeatedly references Finix's APIs, dashboard, and an MCP server for AI agents to query documentation, but never mentions official SDKs (e.g., Python, Node, Java client libraries) for developers to build against. Missing for 10: any mention of official SDKs, supported languages, or SDK documentation/repos.

   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Use Finix's APIs to build your own custom onboarding experience for your sellers.”
   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”
   • [probe] “official MCP server documented at https://docs.finix.com/additional-resources/developers/mcp-server”

   proof ↗⚑ flag

   Rainforest—none0/10

   Evidence only shows REST API reference docs, webhooks, and embeddable components, with no mention of official client SDKs in any language; the OpenAPI probe even returned 404s for spec endpoints. Missing for 10: any documented SDK (e.g., Node/Python/Java client libraries), package registry listing, or SDK quickstart guide.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”
   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “Detailed guides and walkthroughs, full end-to-end sandbox testing, realtime API logs, and more.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Finix✓fullclaimed7/10

   Finix has documented webhook support for programmatic notifications when API resources are created/updated, matching the core subscribe-to-events story. missing for 10: no detail on payload schema/signature verification, no independent/hands-on corroboration of webhook reliability, and no explicit AI-agent-specific webhook consumption examples.

   • [claimed-docs] “Webhooks let you receive notifications programmatically when your API resources are created or updated.”

   proof ↗⚑ flag

   Rainforest✓fullclaimed7/10

   Rainforest's docs explicitly describe a webhooks/notifications system where you can subscribe to events for a list of resources, directly matching the story. missing for 10: no independent/hands-on corroboration or details on payload signing/retry semantics beyond the doc listing.

   • [claimed-docs] “You can subscribe to events for the following resources”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round drawn
   Finix—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

   Rainforest—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

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

   weight 2 · round to Finix
   Finix~partialprobed5/10

   Finix documents an official MCP server that lets an AI agent 'ask questions about the Finix API to get accurate, current answers' (finix-docs-21, finix-probe-2), showing some agentic/natural-language interface exists, but the evidence describes it as a Q&A/documentation lookup tool rather than a way to actually issue commands (e.g., create payouts, onboard sellers) via natural language. Missing for 10: evidence that natural-language commands can trigger real API actions (payouts, onboarding, disputes) rather than just answer questions, and any independent confirmation of this working end-to-end.

   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”
   • [probe] “official MCP server documented at https://docs.finix.com/additional-resources/developers/mcp-server”

   proof ↗⚑ flag

   Rainforest—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

Api quality

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

   weight 2 · round drawn
   Finix—none0/10

   Evidence shows Finix has documentation, sandbox/live environments, and an MCP server, but nothing describes an interactive API reference with runnable/executable examples (e.g., no mention of embedded code sandboxes, 'try it' consoles, or in-docs request execution). Missing for 10: evidence of an interactive/runnable API reference tool, any 'try it' console feature, or runnable code snippets in docs.

   • [claimed-docs] “Finix provides separate Sandbox and Live accounts, along with the corresponding API credentials to access the Finix API.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.finix.com/llms.txt # Finix Docs > Explore our documentation, guides, and APIs to start building yo…”

   proof ↗⚑ flag

   Rainforest—none0/10

   The evidence pack shows conventional API reference pages (e.g., create_merchant.md) and general docs, but nothing describes an interactive, runnable API console or live code execution; the OpenAPI/swagger probe returned 404s, suggesting no standard interactive spec is exposed. missing for 10: evidence of a 'try it' console, runnable code samples, or OpenAPI-based interactive explorer.

   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Finix—none0/10

   No evidence of a downloadable OpenAPI spec or machine-readable API schema; docs mention guides, an llms.txt file, and an MCP server, but nothing about an OpenAPI/Swagger spec download.

   ⚑ flag

   Rainforest—none0/10

   Rainforest exposes a documentation site with reference pages for its API, but a direct probe for standard OpenAPI/Swagger spec locations (openapi.json, swagger.json, etc.) returned 404 across all candidates, and no other evidence shows a downloadable machine-readable spec (only an llms.txt for markdown docs).

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.rainforestpay.com/llms.txt # Rainforest Docs Documentation > Documentation for Rainforest Docs Ap…”

   proof ↗⚑ flag

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

   weight 1 · round to Finix
   Finix✓fullclaimed8/10

   Finix explicitly documents separate Sandbox and Live accounts with distinct API credentials, and a dedicated test environment that simulates live payments (test cards, fee schemas, payout schedules) without touching production data. missing for 10: independent/hands-on confirmation from a developer using the sandbox, and explicit detail on data isolation guarantees between sandbox and production.

   • [claimed-docs] “Finix provides separate Sandbox and Live accounts, along with the corresponding API credentials to access the Finix API.”
   • [claimed-docs] “Finix’s test environment allows you to simulate a live payments experience. Test card payments, configure fees schemas, set payout schedules…”

   proof ↗⚑ flag

   Rainforest✓fullclaimed7/10

   Rainforest explicitly documents a sandbox environment for testing payments with dedicated test cards/accounts that don't touch production, plus 'full end-to-end sandbox testing' mentioned as a platform feature. Missing for 10: independent/hands-on corroboration of sandbox fidelity, and more detail on data isolation guarantees beyond card-decline behavior.

   • [claimed-docs] “Any card number *not* included in any list below will result in a generic **Declined** payment in the sandbox environment.”
   • [claimed-docs] “Detailed guides and walkthroughs, full end-to-end sandbox testing, realtime API logs, and more.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Finix—none0/10

   No evidence pack item mentions API versioning scheme or a documented deprecation policy; docs cover product features, sandbox/live environments, webhooks, and an MCP server but nothing about version lifecycle or deprecation commitments.

   ⚑ flag

   Rainforest—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes returned 404s and docs only cover functional payment integration topics, not API lifecycle/versioning commitments.

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Finix—none0/10

   Finix's evidence covers payments/payouts/onboarding APIs and an MCP server for querying API docs, but there is no mention of bulk operations, batch endpoints, or multi-item processing capabilities for AI-native automation.

   ⚑ flag

   Rainforest—none0/10

   Rainforest is a payments processing API/platform; evidence covers merchant onboarding, payments, deposits, webhooks, and pricing, but nothing describes bulk operations across many items (e.g., batch payment processing, bulk merchant creation, or batch API endpoints). No evidence of any bulk/batch capability.

   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “Process online payments”
   • [claimed-docs] “You can subscribe to events for the following resources”

   proof ↗⚑ flag

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

   weight 3 · round to Rainforest
   Finix—none0/10

   Finix offers webhooks to receive event notifications, but there is no evidence of a rules engine or automation layer that lets users define conditional triggers/actions on those events—webhooks only push data, requiring external logic to act on it.

   ⚑ flag

   Rainforest~partialclaimed3/10

   Rainforest offers webhook subscriptions for resource events (e.g., merchant, payment status changes), which provides a basic event-trigger mechanism, but there is no documented rules engine or conditional 'if event X then action Y' automation layer for defining custom logic. missing for 10: rule/condition definition syntax, built-in action execution (not just external webhook delivery), examples of automated workflows triggered by rules.

   • [claimed-docs] “You can subscribe to events for the following resources”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Finix
   Finix~partialclaimed4/10

   Finix documents recurring billing via Subscriptions and configurable payout schedules in its test environment, which are forms of recurring financial jobs, but there is no evidence of a general-purpose workflow/automation scheduler, cron-like triggers, or AI-agent-driven recurring task orchestration beyond these payment-specific features. Missing for 10: generic recurring workflow/automation engine, scheduling API beyond payouts/subscriptions, AI-agent orchestration of recurring tasks.

   • [claimed-docs] “Bill your customers and buyers using Finix's Subscriptions.”
   • [claimed-docs] “Finix’s test environment allows you to simulate a live payments experience. Test card payments, configure fees schemas, set payout schedules…”
   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”

   proof ↗⚑ flag

   Rainforest—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
   Finix~partialclaimed6/10

   Finix documents APIs to build custom onboarding, payout, and dispute experiences under the platform's own brand (finix-docs-9, finix-docs-10, finix-docs-12, finix-docs-17) plus dashboard-based reporting (finix-docs-24), suggesting sellers' financial data/actions can be surfaced via API in a host product. However, there is no explicit mention of pre-built white-label UI components/widgets (e.g., embeddable balance or transaction-history widgets) — only APIs and Finix's own hosted Dashboard/forms are described. missing for 10: explicit embeddable/white-label UI component library for balances/transaction history, evidence of branding customization on hosted components, independent confirmation of embedding experience.

   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Use Finix's APIs to build your own custom onboarding experience for your sellers.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “Save time onboarding sellers by using our Onboarding Forms.”

   proof ↗⚑ flag

   Rainforest~partialclaimed6/10

   Rainforest explicitly offers pre-built embeddable components for payments, reporting, chargebacks, and merchant onboarding, plus a 'payment component studio' for designing branded embedded components for platform integration, supporting white-labeled seller-facing surfaces like transaction/payment history [rainforest-docs-15, rainforest-docs-4, rainforest-docs-11]. However, deposits/payouts are only exposed via API endpoints (e.g., updating deposit frequency) with no explicit mention of a dedicated embeddable balances or payouts UI component, and no evidence of granular white-label branding controls beyond the component studio. Missing for 10: explicit embeddable balance/payout UI components, documented white-label branding/customization API for these surfaces, and independent/hands-on confirmation of branding flexibility.

   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”
   • [claimed-docs] “Integrate Rainforest's low-code embeddable component into your platform, allowing me”
   • [claimed-docs] “Head over to the [payment component studio] to start designing the embedded payment component for your platform integration.”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”

   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 to Rainforest
   Finix—none0/10

   The evidence pack covers Finix's online payments, payouts, onboarding, disputes, and reporting APIs, but there is no mention of in-person/card-present capabilities such as terminals, tap-to-pay SDKs, or POS hardware integrations that settle into the same seller balances as online payments. Without any documentation of card-present/terminal support, this applicable capability is unevidenced.

   ⚑ flag

   Rainforest~partialclaimed5/10

   Rainforest documents both online payments and 'Process payments with a device' (terminal-style in-person processing) under the same merchant/API model, implying shared merchant balances and reporting infrastructure (deposits, webhooks). However, there is no explicit documentation of a tap-to-pay SDK or an explicit statement confirming that in-person device payments settle into the exact same balance/reporting pipeline as online payments. missing for 10: explicit tap-to-pay SDK support, explicit confirmation that device/terminal payments unify with online payments in settlement and reporting, independent corroboration of in-person hardware integration.

   • [claimed-docs] “Process payments with a device”
   • [claimed-docs] “Process online payments”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”

   proof ↗⚑ 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 to Finix
   Finix~partialclaimed4/10

   Finix documents a Payouts Dashboard and >10 automated report types (transactions, disputes, fees) plus seller-payout management tools, which could support reconciliation and reporting, but there's no explicit evidence of a seller-facing self-serve statement/export portal that sellers or their bookkeepers can access directly without going through the platform's ops team. Missing for 10: seller-facing self-serve statement/export UI, explicit reconciliation report for bookkeeper close-out, and any confirmation that sellers (not just the platform) can pull these reports themselves.

   • [claimed-docs] “Learn how to manage your payout activity using the Payouts Dashboard.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”

   proof ↗⚑ flag

   Rainforest~partialclaimed3/10

   Rainforest advertises a pre-built embeddable 'reporting' component alongside payments, chargebacks, and onboarding, implying some seller-facing financial visibility, but the docs pack contains no specifics on per-seller statements, payout reconciliation reports, or bookkeeper-ready exports. Missing for 10: documentation of statement generation, reconciliation report format/fields, and export capabilities (CSV/PDF) for bookkeepers.

   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”

   proof ↗⚑ 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 Finix
   Finix~partialclaimed5/10

   Finix documents controlling seller payouts on your own schedule via Dashboard or API and topping up/holding a platform balance before disbursing funds (finix-docs-12, finix-docs-13, finix-docs-15), which supports delaying seller payouts, and it has dispute-handling workflows (finix-docs-17, finix-docs-18). But there is no dedicated 'escrow' feature description — no documented hold-until-delivery mechanism, dispute-window-linked release triggers, or stated limits on how long funds can be held. Missing for 10: explicit escrow/hold-fund mechanics tied to delivery or dispute windows, documented release triggers/automation, and stated limits or edge cases of such holds.

   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”
   • [claimed-docs] “Top up your Finix balance with ACH or wire transfers before sending payouts.”
   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “Upload evidence and submit a response to challenge a Dispute.”

   proof ↗⚑ flag

   Rainforest—none0/10

   The evidence covers payment processing, deposits/payout frequency, amount splits, and webhooks, but nothing describes holding seller funds in escrow until delivery or dispute windows pass, nor programmable release triggers or documented limits for such a mechanism — missing for 10: escrow/hold-funds primitive, delivery/dispute-window release logic, and documented limits on hold duration or amounts.

   • [claimed-docs] “You can implement amount splits in three steps”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”

   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 drawn
   Finix—none0/10

   Evidence covers disputes monitoring/response, payouts, and balance top-ups, but nothing describes automatic debiting of a seller's future earnings or bank account to recover chargeback/refund losses, nor any documented liability waterfall/order. missing for 10: documentation of automatic negative-balance recovery, debit reversal against future payouts or linked bank account, and liability order documentation.

   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “Upload evidence and submit a response to challenge a Dispute.”
   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”
   • [claimed-docs] “Top up your Finix balance with ACH or wire transfers before sending payouts.”

   proof ↗⚑ flag

   Rainforest—none0/10

   The pack only shows a generic mention of a 'chargebacks' component (rainforest-docs-15) among Rainforest's embeddable features, but there is no documentation describing automatic debits against future earnings, bank account debits for negative balances, or a documented liability order for recovering losses. Missing for 10: any doc on negative-balance recovery mechanics, reserve/liability sequencing, or bank-account debit process.

   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”

   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 drawn
   Finix~partialclaimed5/10

   Finix's platform-payments docs show sellers can be onboarded and paid out, and platforms can 'monetize' payments and customize fees, which implies a split between seller and platform, but no evidence describes a first-class 'split' object spanning multiple sellers on one charge, nor mechanisms to reverse or adjust splits after the fact. missing for 10: explicit multi-party split/transfer API object, ability to route one charge to several sellers simultaneously, and reversal/adjustment of splits post-charge.

   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Finix allows you to easily monetize your payments. We offer out of the box customizability, efficiency, and revenue growth tools.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Some of the fee customizations available are: International charges, Transaction volume discounts, Applying fees per payment method, Acceler…”

   proof ↗⚑ flag

   Rainforest~partialclaimed5/10

   Rainforest documents an 'amount splits' feature implemented via API steps (rainforest-docs-6), supporting the core idea of routing a charge across parties, but there is no evidence of split objects being adjustable or reversible after the fact, no detail on how many parties can be split among, and no confirmation these splits are exposed as standalone first-class API objects rather than a payment-creation parameter. Missing for 10: adjustable/reversible split objects, multi-party routing detail, explicit object model documentation, and independent corroboration.

   • [claimed-docs] “You can implement amount splits in three steps”

   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 to Finix
   Finix~partialclaimed5/10

   Finix documents general dispute management (monitor/act via Dashboard or API, upload evidence, submit response) and separately documents platform/seller-based architecture (onboarding sellers, seller payouts, sub-merchant balances), implying disputes could be tied to sub-merchants, but no docs explicitly confirm chargebacks are routed per-seller or that outcomes automatically adjust seller balances. missing for 10: explicit documentation of chargebacks landing against the correct sub-merchant, and automatic balance reconciliation after dispute resolution.

   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “Upload evidence and submit a response to challenge a Dispute.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”

   proof ↗⚑ flag

   Rainforest~partialclaimed3/10

   Rainforest advertises a pre-built 'chargebacks' component alongside merchant onboarding and payments, implying dispute handling exists in a submerchant-based platform, but the evidence never details per-seller/sub-merchant dispute routing, API-based evidence submission, or automatic balance reconciliation of outcomes. missing for 10: documentation on chargeback-to-submerchant assignment, evidence submission API/dashboard specifics, and how dispute outcomes update seller balances.

   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”

   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 to Finix
   Finix~partialclaimed4/10

   Finix documents dispute monitoring/response tools, payout dashboards, and automated reports covering transactions/disputes/fees, which partially support portfolio oversight and dispute handling. However there is no evidence of fraud or credit-risk scoring per sub-merchant, anomaly alerts on sellers, or explicit tools to pause payouts or offboard bad actors. missing for 10: fraud/credit-risk signal scoring per sub-merchant, anomaly detection alerts, explicit payout-pause/offboarding controls, independent validation of these risk tools.

   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “Upload evidence and submit a response to challenge a Dispute.”
   • [claimed-docs] “Dispute Management Tools”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “Learn how to manage your payout activity using the Payouts Dashboard.”

   proof ↗⚑ flag

   Rainforest—none0/10

   Evidence covers merchant onboarding, payments processing, deposits, webhooks, and pricing, but nothing addresses fraud/credit-risk monitoring, anomaly alerts, or tools to pause payouts/offboard sellers as portfolio risk-management features for ops users.

   ⚑ 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 drawn
   Finix—none0/10

   Finix's documented payouts focus on US rails (ACH, wire, card, real-time bank payouts) and its only international-related mention is a fee customization for 'International charges' (finix-docs-25), not multi-currency payout support, FX handling, or local settlement rails. No evidence describes local-currency payouts to international sellers or settlement via local bank networks.

   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”
   • [claimed-docs] “Top up your Finix balance with ACH or wire transfers before sending payouts.”
   • [claimed-docs] “Some of the fee customizations available are: International charges, Transaction volume discounts, Applying fees per payment method, Acceler…”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”

   proof ↗⚑ flag

   Rainforest—none0/10

   Rainforest's docs describe US-centric payment processing, merchant onboarding, deposits, and payouts, but there is no mention of multi-currency support, FX handling, local-currency payouts, or settlement to local bank rails in other countries — the product appears scoped to US card/ACH processing only.

   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “Facilitate payments from users to your customers via card, PayPal, Venmo, PayPal Pay Later, ACH, and Apple Pay.”
   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”

   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 Finix
   Finix~partialclaimed6/10

   Finix docs confirm real-time payouts to bank accounts or cards, payout links, top-up via ACH/wire, and a test environment where you can 'set payout schedules,' plus per-seller payout management via Dashboard or API. However, there's no explicit documentation of configurable daily/weekly/monthly/manual cadence options per seller or instant-payout-to-real-time-rails distinctions beyond cards. missing for 10: explicit per-seller schedule configuration UI/API (daily/weekly/monthly/manual options), documentation of real-time rail support beyond cards, and independent/hands-on confirmation of scheduling flexibility.

   • [claimed-docs] “Make a payout to a recipient's credit or debit card.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”
   • [claimed-docs] “Top up your Finix balance with ACH or wire transfers before sending payouts.”
   • [claimed-docs] “Finix’s test environment allows you to simulate a live payments experience. Test card payments, configure fees schemas, set payout schedules…”

   proof ↗⚑ flag

   Rainforest~partialclaimed5/10

   Docs confirm per-merchant deposit frequency can be configured and updated via the API (rainforest-docs-7), supporting scheduled payouts per seller, but there is no evidence of instant/real-time payouts to cards or push-to-card rails, nor explicit mention of daily/weekly/monthly/manual options as distinct settings. missing for 10: instant payouts to cards or real-time rails, explicit enumeration of daily/weekly/monthly/manual schedule options, and any confirmation of per-seller instant payout support.

   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”

   proof ↗⚑ flag

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

   weight 2 · round to Finix
   Finix~partialclaimed6/10

   Docs repeatedly note dual access via 'Dashboard or API' for payouts, seller payouts, disputes, and onboarding (finix-docs-6,7,8,12,17), indicating most core operations are API-accessible, and a Sandbox/Live environment plus webhooks support programmatic workflows (finix-docs-19,20). However, some UI-only surfaces like reporting/dashboard analytics and pricing/fee customization tools are described only in dashboard terms (finix-docs-22,24,25) without explicit API parity confirmation. Missing for 10: explicit API equivalents for dashboard reporting/analytics and fee-customization UI, and independent/hands-on confirmation that no UI action is API-inaccessible.

   • [claimed-docs] “Learn how to onboard your sellers with Finix's APIs.”
   • [claimed-docs] “Make a payout to a recipient's credit or debit card.”
   • [claimed-docs] “Learn how to create payout links on the Finix Dashboard and via API”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “Webhooks let you receive notifications programmatically when your API resources are created or updated.”
   • [claimed-docs] “Finix provides separate Sandbox and Live accounts, along with the corresponding API credentials to access the Finix API.”
   • [claimed-docs] “Dispute Management Tools”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”

   proof ↗⚑ flag

   Rainforest~partialclaimed4/10

   Rainforest's docs show a broad set of API endpoints (create/update merchant, deposits, splits, webhooks, payments) covering most core functionality, and it is fundamentally API-first with embeddable UI components layered on top rather than a separate full UI. However, there is no explicit statement or evidence mapping every UI capability (e.g., the payment component studio design flow) to an equivalent API call, so full parity is unconfirmed. Missing for 10: explicit parity documentation or changelog confirming API/UI feature equivalence, and evidence that studio/dashboard-only actions can be performed purely via API.

   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “You can implement amount splits in three steps”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [claimed-docs] “Head over to the [payment component studio] to start designing the embedded payment component for your platform integration.”

   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 drawn
   Finix—none0/10

   Evidence shows Finix's platform-payments features (seller onboarding, payouts, monetization, disputes) but nowhere describes a staged path from a managed/PayFac-as-a-service model to full registered payment facilitation, nor any assurance that such a transition avoids replatforming. This specific payfac-liability graduation story is unaddressed in the pack.

   ⚑ flag

   Rainforest—none0/10

   Evidence describes Rainforest's managed payfac model, pricing control, and onboarding components, but there is no mention of a defined path or product mechanism to graduate from Rainforest's managed platform toward becoming a registered/independent PayFac without replatforming. missing for 10: any documentation of a registered-PayFac graduation path, migration tooling, or sponsor-bank transition process.

   • [claimed-docs] “We lead with a buy-rate, interchange-plus pricing model, and have no revenue split. See how much money you could save versus a flat rate mod…”
   • [claimed-docs] “Yes! You totally control how much you bill your merchants. And with our buy-rate model, any optimization to pricing or interchange costs goe…”
   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”

   proof ↗⚑ 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
   Finix—none0/10

   Evidence pack shows only feature-level docs (onboarding, payouts, disputes, tokenization) with no explicit documentation splitting liability for KYC/AML, card-network compliance, fraud losses, or seller misconduct between Finix and the platform/ops user. Community items are unrelated commentary about branding/positioning, not liability allocation.

   ⚑ flag

   Rainforest—none0/10

   The evidence pack covers onboarding, payments, deposits, webhooks, and pricing docs, but nothing explicitly documents a liability/responsibility split for KYC/AML ownership, card-network compliance, fraud losses, or seller misconduct between Rainforest and the platform.

   ⚑ 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
   Finix—none0/10

   No evidence in the pack mentions 1099-K thresholds, tax form generation/filing, delivery to sellers, or any data-correction workflow for tax reporting; coverage is limited to payouts, onboarding, disputes, and reporting on transactions/fees.

   ⚑ flag

   Rainforest—none0/10

   No evidence in the pack addresses 1099-K threshold tracking, tax form generation/delivery/filing, or a data correction workflow; evidence only covers payments, onboarding, deposits, webhooks, and pricing.

   ⚑ 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 to Finix
   Finix~partialprobed6/10

   Finix documents API/dashboard surfaces for reading payouts, diagnosing failed payouts, and uploading dispute evidence (finix-docs-7,12,13,16,17,18), and it ships an official MCP server so agents can query API documentation (finix-docs-21, finix-probe-2). However, the MCP server is explicitly for answering questions about the API, not for performing agent actions like reading live balances or drafting/submitting dispute evidence directly — that still requires building against the REST API. Missing for 10: evidence of an agent actually executing balance/payout reads or dispute-evidence actions via the MCP server or an agent SDK, and independent/hands-on confirmation of agent usability.

   • [claimed-docs] “Make a payout to a recipient's credit or debit card.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”
   • [claimed-docs] “Diagnose and resolve payouts that fail before funds reach the recipient.”
   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”
   • [claimed-docs] “Upload evidence and submit a response to challenge a Dispute.”
   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”
   • [probe] “official MCP server documented at https://docs.finix.com/additional-resources/developers/mcp-server”

   proof ↗⚑ flag

   Rainforest~partialprobed4/10

   Rainforest documents merchant, deposit and webhook APIs (e.g. deposit frequency, event subscriptions) that touch payout mechanics, and its docs are markdown-fetchable via llms.txt for agent consumption, but there is no documented endpoint for reading balances, investigating a missing payout, or drafting dispute/chargeback evidence, and the probe found no OpenAPI spec for structured agent access. missing for 10: explicit balance/payout read endpoints, dispute-evidence drafting API, and a machine-readable OpenAPI spec.

   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.rainforestpay.com/llms.txt # Rainforest Docs Documentation > Documentation for Rainforest Docs Ap…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”

   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
   Finix~partialprobed4/10

   Finix has API-based seller onboarding (create accounts, onboarding forms, API onboarding flows) and an official MCP server for the docs/API, but the MCP server is documented as a Q&A assistant ('ask an AI agent questions about the Finix API') rather than an actionable surface for agents to create accounts, drive onboarding, or query/answer requirements-due states. No evidence of scoped credentials for agent-driven actions or of onboarding-status/requirements-due endpoints being exposed via MCP. missing for 10: evidence that the MCP server supports actionable operations (account creation, onboarding progression) rather than just Q&A, documentation of requirements-due/onboarding-status API endpoints, and evidence of scoped/agent-specific credentialing.

   • [claimed-docs] “Learn how to onboard your sellers with Finix's APIs.”
   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Use Finix's APIs to build your own custom onboarding experience for your sellers.”
   • [claimed-docs] “Ask an AI agent questions about the Finix API to get accurate, current answers.”
   • [probe] “official MCP server documented at https://docs.finix.com/additional-resources/developers/mcp-server”
   • [claimed-docs] “Finix provides separate Sandbox and Live accounts, along with the corresponding API credentials to access the Finix API.”

   proof ↗⚑ flag

   Rainforest~partialprobed4/10

   Rainforest exposes a REST API for creating merchant accounts, driving onboarding via embeddable components, and webhook notifications for status/requirements changes (rainforest-docs-5, rainforest-docs-4, rainforest-docs-8, rainforest-docs-10), which could plausibly be driven by an agent. However there is no evidence of an MCP server/surface, no mention of scoped or agent-specific credentials, and the openapi probe returned 404s suggesting no discoverable machine-readable API spec for agent tooling. missing for 10: MCP server/tool surface, scoped/agent-specific API credentials, explicit agent-orchestration documentation, discoverable OpenAPI spec.

   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “Integrate Rainforest's low-code embeddable component into your platform, allowing me”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [claimed-docs] “Your Rainforest integration includes three primary phases.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.rainforestpay.com/openapi.json, https://docs.rainforestpay.com/swagger.json, https://do…”

   proof ↗⚑ 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 drawn
   Finix—none0/10

   The evidence pack covers payouts, onboarding, disputes, and dashboard reporting, but contains no mention of where held/in-flight funds are custodied, whether balances earn yield, or how platform funds are segregated from Finix's own accounts — a standard and expected disclosure for a payments/platform-ledger product. missing for 10: any documentation of fund custody/segregation structure, statements on yield/interest on held balances, and disclosure of banking partner or FBO account arrangements.

   • [claimed-docs] “Top up your Finix balance with ACH or wire transfers before sending payouts.”
   • [claimed-docs] “Use Payouts to send funds directly to a recipient's bank account or card in real-time.”

   proof ↗⚑ flag

   Rainforest—none0/10

   The evidence covers merchant onboarding, payment processing, and deposit frequency settings, but nothing addresses where in-flight/held funds are custodied, whether balances earn yield, or how funds are segregated from Rainforest's own accounts. This is a fair question for a payments/payfac platform, so the axis applies, but no evidence supports it.

   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”

   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 Finix
   Finix~partialclaimed6/10

   Finix provides fee/monetization tooling, a Payouts Dashboard, 10+ automated report types (transactions, disputes, fees), sandbox/live environments and webhooks for tracking resource state changes, which together support financial visibility and reconciliation workflows. However, there is no explicit documentation of a unified ledger view showing per-seller balances alongside platform fee-account balances, or a single traceable charge→split→payout audit trail guaranteed to reconcile to the penny. Missing for 10: dedicated seller-balance/fee-account balance dashboard, explicit charge-to-payout traceability/audit-trail documentation, penny-level reconciliation guarantees or tooling.

   • [claimed-docs] “Learn how to manage your payout activity using the Payouts Dashboard.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Top up your Finix balance with ACH or wire transfers before sending payouts.”
   • [claimed-docs] “Webhooks let you receive notifications programmatically when your API resources are created or updated.”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “Some of the fee customizations available are: International charges, Transaction volume discounts, Applying fees per payment method, Acceler…”
   • [claimed-docs] “Finix’s test environment allows you to simulate a live payments experience. Test card payments, configure fees schemas, set payout schedules…”

   proof ↗⚑ flag

   Rainforest~partialclaimed5/10

   Rainforest documents amount splits, payout/deposit scheduling, merchant creation, and webhooks for payment-lifecycle events, plus a generic 'reporting' embeddable component, which together imply some traceability from charge to payout. However there is no explicit documentation of a ledger, seller-level balance views, fee-account tracking, or penny-level reconciliation tooling. Missing for 10: dedicated ledger/balance reporting docs, explicit reconciliation guarantees, fee-account balance visibility, and any independent confirmation of reconciliation accuracy.

   • [claimed-docs] “You can implement amount splits in three steps”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”

   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 Finix
   Finix~partialclaimed5/10

   Finix docs mention automated dashboard reports (10+ report types covering transactions, disputes, fees) and webhooks for programmatic event notifications, plus seller payout management via API, which together support some reconciliation workflows. However, there is no explicit documentation of scheduled file delivery, per-seller vs rolled-up settlement/balance report APIs, or a dedicated reconciliation/reporting API for finance-stack consumption. Missing for 10: explicit scheduled report export (files/API), per-seller vs aggregate balance reconciliation endpoints, and confirmation of finance-stack integration patterns.

   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”
   • [claimed-docs] “Webhooks let you receive notifications programmatically when your API resources are created or updated.”
   • [claimed-docs] “Monitor and act on Disputes through the Finix Dashboard or API.”

   proof ↗⚑ flag

   Rainforest~partialclaimed3/10

   Rainforest mentions a pre-built 'reporting' embeddable component and webhooks/events for merchant and payment resources, plus deposit frequency settings per merchant, which are adjacent to reconciliation, but there is no explicit documentation of settlement/balance reports per seller and rolled up, nor of scheduled file or API delivery for a finance stack. missing for 10: dedicated settlement/balance report docs, per-seller and rollup reconciliation reports, scheduled file exports, finance-system API integration details.

   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”
   • [claimed-docs] “You can subscribe to events for the following resources”
   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”

   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 Finix
   Finix✓fullclaimed8/10

   Finix explicitly documents platform monetization: per-seller fee customization (international charges, volume discounts, per-method fees), a dedicated 'Monetizing Payments' guide, and dashboard reporting that separates transactions, disputes, and fees across 10+ automated report types. This directly supports application fees/markup, per-seller pricing, and distinct revenue reporting. Missing for 10: no independent/hands-on verification of the revenue-vs-cost reporting split or real-world confirmation that markup fees appear as distinct line items in the dashboard.

   • [claimed-docs] “Finix allows you to easily monetize your payments. We offer out of the box customizability, efficiency, and revenue growth tools.”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “Some of the fee customizations available are: International charges, Transaction volume discounts, Applying fees per payment method, Acceler…”
   • [claimed-docs] “Finix’s test environment allows you to simulate a live payments experience. Test card payments, configure fees schemas, set payout schedules…”
   • [claimed-docs] “Dispute Management Tools”

   proof ↗⚑ flag

   Rainforest~partialclaimed6/10

   Rainforest supports buy-rate/interchange-plus pricing with full control over what founders bill merchants, meaning markup/margin capture is real and per-merchant pricing is possible (rainforest-docs-12, rainforest-docs-13), and amount splits let platforms take a fee on each transaction (rainforest-docs-6). However, evidence does not show a dedicated 'platform revenue' reporting view that separates markup/application-fee revenue from underlying processing costs — reporting docs focus on merchant/transaction data, not platform P&L separation. missing for 10: explicit per-seller/per-merchant custom pricing configuration UI or API field, and a distinct revenue-vs-cost reporting/dashboard feature for the platform itself.

   • [claimed-docs] “We lead with a buy-rate, interchange-plus pricing model, and have no revenue split. See how much money you could save versus a flat rate mod…”
   • [claimed-docs] “Yes! You totally control how much you bill your merchants. And with our buy-rate model, any optimization to pricing or interchange costs goe…”
   • [claimed-docs] “You can implement amount splits in three steps”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”

   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 Rainforest
   Finix~partialclaimed5/10

   Finix documents platform monetization tools — fee customization (international charges, volume discounts, per-payment-method fees), configurable fee schemas in test/sandbox, and dashboard reports covering transactions, disputes, and fees — which supports setting a sell rate and viewing cost data. However there is no explicit documentation of a 'buy rate' contract from Finix itself or interchange-level cost breakdowns for spread management. Missing for 10: documented buy rate/cost-plus pricing terms, interchange-level line-item visibility, and independent confirmation of spread transparency.

   • [claimed-docs] “Finix allows you to easily monetize your payments. We offer out of the box customizability, efficiency, and revenue growth tools.”
   • [claimed-docs] “From transactions to disputes and fees, more than 10 report types are automated and available in your personal dashboard”
   • [claimed-docs] “Some of the fee customizations available are: International charges, Transaction volume discounts, Applying fees per payment method, Acceler…”
   • [claimed-docs] “Finix’s test environment allows you to simulate a live payments experience. Test card payments, configure fees schemas, set payout schedules…”

   proof ↗⚑ flag

   Rainforest✓fullclaimed8/10

   Vendor docs explicitly state a buy-rate, interchange-plus pricing model with no revenue split, and confirm platforms fully control the sell rate charged to merchants, with pricing optimizations flowing directly to the platform's margin. Missing for 10: independent/third-party corroboration of actual interchange-level cost breakdowns in the dashboard/API and real customer confirmation of spread visibility.

   • [claimed-docs] “We lead with a buy-rate, interchange-plus pricing model, and have no revenue split. See how much money you could save versus a flat rate mod…”
   • [claimed-docs] “Yes! You totally control how much you bill your merchants. And with our buy-rate model, any optimization to pricing or interchange costs goe…”

   proof ↗⚑ 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 drawn
   Finix—none0/10

   Evidence covers merchant onboarding mechanics (forms, APIs) but there is no documented coverage map of supported onboarding countries, local payment methods, or local-currency settlement — nothing resembling a country/currency/payment-method matrix appears anywhere in the pack.

   ⚑ flag

   Rainforest—none0/10

   The evidence pack shows Rainforest's payment methods (card, PayPal, Venmo, ACH, Apple Pay) and onboarding/merchant creation flows, but nothing documents a coverage map of supported onboarding countries, local payment methods per country, or local-currency settlement — ACH and the overall feature set suggest a US-centric product with no cross-border documentation provided.

   • [claimed-docs] “Facilitate payments from users to your customers via card, PayPal, Venmo, PayPal Pay Later, ACH, and Apple Pay.”
   • [claimed-docs] “Integrate Rainforest's low-code embeddable component into your platform, allowing me”
   • [claimed-docs] “Create a merchant with an initial merchant application.”

   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 Rainforest
   Finix~partialclaimed6/10

   Finix docs clearly describe API-based seller onboarding (finix-docs-6, finix-docs-9, finix-docs-10) and hosted 'Onboarding Forms' to save developers from building UI (finix-docs-5), plus general merchant onboarding guidance (finix-docs-4). However, the evidence pack never explicitly details KYC/KYB data collection, bank account linking, or terms-of-service acceptance steps, nor confirms an embeddable (non-hosted-redirect) component distinct from the hosted forms. Missing for 10: explicit KYC/KYB field documentation, bank-account-linking flow details, terms-acceptance step, and confirmation of embeddable UI components (vs. only hosted forms).

   • [claimed-docs] “If you are a platform, you can quickly onboard merchants to Finix.”
   • [claimed-docs] “Save time onboarding sellers by using our Onboarding Forms.”
   • [claimed-docs] “Learn how to onboard your sellers with Finix's APIs.”
   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Use Finix's APIs to build your own custom onboarding experience for your sellers.”

   proof ↗⚑ flag

   Rainforest✓fullclaimed8/10

   Docs explicitly describe API-driven merchant creation (KYB/KYC via merchant application), embeddable low-code onboarding components, and pre-built components for merchant onboarding as an alternative to building forms; deposit/webhook docs suggest bank account linking is part of merchant setup. missing for 10: explicit mention of terms/e-sign acceptance flow and dedicated bank-linking API endpoint documentation, plus independent/hands-on corroboration.

   • [claimed-docs] “Integrate Rainforest's low-code embeddable component into your platform, allowing me”
   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “Start processing payments in days, not months. Reduce development time and get to revenue faster with our pre-built, embeddable components f…”
   • [claimed-docs] “Head over to the [payment component studio] to start designing the embedded payment component for your platform integration.”
   • [claimed-docs] “For **Active** merchants, the deposit frequency can be updated by setting the new deposit frequency on the [Update merchant] endpoint.”

   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 Finix
   Finix~partialclaimed5/10

   Finix docs show onboarding forms and APIs for onboarding sellers, plus dashboard/API controls for seller payouts, implying some flexibility in what's collected before payout, but there's no explicit documentation of a tunable 'minimum to start selling then collect more before payout thresholds' workflow or explicit per-seller requirements-due states. missing for 10: explicit documentation of configurable onboarding requirement tiers, requirements-due state tracking per seller, and evidence of payout-threshold gating tied to progressive data collection.

   • [claimed-docs] “Save time onboarding sellers by using our Onboarding Forms.”
   • [claimed-docs] “Learn how to onboard your sellers with Finix's APIs.”
   • [claimed-docs] “With Finix, you can easily onboard your sellers to start processing their payments and payouts.”
   • [claimed-docs] “Use Finix's APIs to build your own custom onboarding experience for your sellers.”
   • [claimed-docs] “You can manage how sellers get paid out using the Finix Dashboard or our API.”

   proof ↗⚑ flag

   Rainforest—none0/10

   Evidence covers merchant creation, onboarding components, and going-live phases, but nothing describes staged/tunable onboarding requirements, minimum-to-start thresholds, or per-seller 'requirements-due' states tied to payout limits.

   • [claimed-docs] “Integrate Rainforest's low-code embeddable component into your platform, allowing me”
   • [claimed-docs] “Create a merchant with an initial merchant application.”
   • [claimed-docs] “Your Rainforest integration includes three primary phases.”

   proof ↗⚑ flag