Rainforest vs Tilled

Agent access

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

   weight 2 · round to Rainforest
   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

   Tilled—none0/10

   No evidence of an llms.txt file, agent-oriented documentation, or any mention of AI agent-friendly docs; the evidence pack only shows standard developer documentation for payments/onboarding.

   ⚑ flag

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

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

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

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

   weight 3 · round drawn
   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

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

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

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

   weight 3 · round to Tilled
   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

   Tilled~partialclaimed7/10

   Tilled documents a public API with API keys, a quick-start guide, sandbox/test environment, and webhooks for event-driven use, indicating the product can be driven programmatically (tilled-docs-1, tilled-docs-2, tilled-docs-3, tilled-docs-4). However, the evidence pack lacks a full API reference/spec, SDK details, or independent developer corroboration of building an integration end-to-end. Missing for 10: comprehensive API reference/OpenAPI docs, SDK examples, and third-party/hands-on confirmation of programmatic control.

   • [claimed-docs] “API keys are required to access API. To generate API keys through the Dashboard”
   • [claimed-docs] “Check out everything Tilled has to offer and get a little test-happy in our sandbox environment.”
   • [claimed-docs] “To simulate a decline, pass-through the respective amount when Creating a Payment Intent”
   • [claimed-docs] “Webhooks provide real-time notifications to your application about events occurring on platform.”

   proof ↗⚑ flag

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

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

   Tilled—none0/10

   Evidence only shows basic API key generation for platform access; there is no mention of scoped, least-privilege, or role-restricted credentials suitable for delegating to an AI agent.

   • [claimed-docs] “API keys are required to access API. To generate API keys through the Dashboard”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   Tilled—none0/10

   The evidence pack covers API keys, sandbox testing, webhooks, merchant onboarding, and dashboard features, but contains no mention of official SDKs (e.g., language-specific libraries like Python, Node.js, Java) for developers to build against.

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Rainforest
   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

   Tilled~partialclaimed5/10

   Tilled documents webhooks that provide real-time event notifications, confirming basic webhook subscription support, but there is no evidence of event type filtering, subscription management API, signature verification, or retry/delivery configuration details. missing for 10: documented list of subscribable event types, webhook management/configuration API, signature verification details, independent/hands-on confirmation.

   • [claimed-docs] “Webhooks provide real-time notifications to your application about events occurring on platform.”

   proof ↗⚑ flag

Agentic features

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

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

   Tilled—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 drawn
   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

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

   Tilled—none0/10

   Evidence shows standard docs (quick-start, webhooks, testing, onboarding) but no mention of an interactive API reference or runnable code examples/sandbox console embedded in docs.

   ⚑ flag

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

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

   Tilled—none0/10

   No evidence pack item mentions an OpenAPI spec, Swagger file, or any downloadable machine-readable API specification; docs only describe API concepts and dashboard features.

   ⚑ flag

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

   weight 1 · round drawn
   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

   Tilled✓fullclaimed7/10

   Tilled explicitly offers a sandbox environment for testing, including simulating declines and mock card-present/terminal testing, without touching production data. Missing for 10: independent/hands-on corroboration beyond vendor docs, and no explicit mention of automated/agentic test workflows or CI integration.

   • [claimed-docs] “Check out everything Tilled has to offer and get a little test-happy in our sandbox environment.”
   • [claimed-docs] “To simulate a decline, pass-through the respective amount when Creating a Payment Intent”
   • [claimed-docs] “A mock card present provider, which allows for terminal creation and testing”

   proof ↗⚑ flag

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

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

   Tilled—none0/10

   No evidence pack items mention API versioning, version numbers, or a deprecation policy for Tilled's API; documentation covers keys, webhooks, onboarding, and dashboard features but not lifecycle/versioning practices.

   ⚑ flag

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

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

   Tilled—none0/10

   Tilled's evidence pack covers payments API, onboarding, disputes, payouts, and webhooks, but there is no mention of bulk/batch operations across many items (e.g., bulk payment creation, bulk merchant updates, batch API endpoints for multiple resources at once). The only 'batch' reference concerns settlement batch closing for a single store's transactions, not bulk operations across many items.

   ⚑ flag

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

   weight 3 · round to Rainforest
   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

   Tilled—none0/10

   Tilled offers webhooks for event notifications (tilled-docs-4) but there is no evidence of a rules engine or conditional trigger system that lets users define automated actions based on those events.

   • [claimed-docs] “Webhooks provide real-time notifications to your application about events occurring on platform.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

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

   Tilled~partialclaimed6/10

   Tilled explicitly offers white-labeling of API, onboarding, and reporting console under a partner's own domain, and documents building custom UIs on top of its API (payouts, disputes, subscriptions data are accessible via Dashboard/API). This supports embeddable seller-facing surfaces but the evidence doesn't detail specific pre-built components for balances/transaction history or give independent proof of embedding fidelity. Missing for 10: dedicated embeddable balance/transaction-history widget docs, explicit component-level white-label UI examples, and independent/hands-on confirmation of the white-label experience.

   • [claimed-docs] “Enterprise partners have the ability to host their API, merchant onboarding, and reporting console experiences on a domain that reflects the…”
   • [claimed-docs] “Customize and build your own UI”
   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”
   • [claimed-docs] “Merchants can manage disputes through the Dashboard.”
   • [claimed-docs] “Merchants and ISVs can now view and manage all of their subscriptions within their Dashboard.”

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

   Tilled~partialclaimed5/10

   Tilled docs mention card-present terminal creation/testing and batch closing so in-person transactions settle at shift end, implying integration with the same merchant account, but there's no explicit tap-to-pay SDK or documentation showing unified balance/reporting dashboards combining online and in-person payments. Missing for 10: tap-to-pay SDK details, explicit unified reporting/balance evidence combining online and card-present transactions, and independent corroboration of terminal hardware support.

   • [claimed-docs] “By closing a batch via API, a store can ensure their transactions are settled at time of close or end of shift”
   • [claimed-docs] “A mock card present provider, which allows for terminal creation and testing”

   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 drawn
   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

   Tilled~partialclaimed3/10

   Tilled's docs show merchants can view payout speed in a Dashboard (tilled-docs-10) and enterprise partners can white-label a 'reporting console' (tilled-docs-14), suggesting some self-serve payout visibility, but there is no evidence of per-seller statements, payout reconciliation reports, or bookkeeper-ready exports. missing for 10: per-seller statement generation, payout reconciliation report format/detail, CSV/export functionality for bookkeepers.

   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”
   • [claimed-docs] “Enterprise partners have the ability to host their API, merchant onboarding, and reporting console experiences on a domain that reflects the…”

   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 drawn
   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

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

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

   Tilled—none0/10

   Evidence only mentions that merchants can 'manage disputes' through the Dashboard, with no documentation of negative balance recovery, automatic debits against future earnings, bank account debits, or liability ordering for refunds/chargebacks exceeding balance.

   • [claimed-docs] “Merchants can manage disputes through the Dashboard.”

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

   Tilled—none0/10

   The evidence pack covers merchant onboarding, pricing templates, payouts, disputes, and webhooks, but nothing describes splitting a single charge across multiple parties, taking a platform cut, or reversing/adjusting such splits as API objects. Tilled's evidence centers on single-merchant payment processing and ISV platform fee/pricing templates, not multi-party charge splitting. Missing for 10: any mention of split payments, multi-party charge routing, application fees, or transfer/reversal objects for splits.

   • [claimed-docs] “Merchant pricing is managed using pricing templates, which serve as a repository of pricing information for a specific payment method.”
   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”

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

   Tilled~partialclaimed3/10

   Only one doc snippet confirms merchants can manage disputes via the Dashboard, implying per-merchant (sub-merchant) dispute handling, but there's no evidence of API-based evidence submission, explicit chargeback routing logic, or automatic reconciliation of outcomes into seller balances. missing for 10: API-based dispute evidence submission, explicit per-seller chargeback routing details, automatic balance reconciliation after dispute outcome.

   • [claimed-docs] “Merchants can manage disputes through the Dashboard.”

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

   Tilled—none0/10

   The evidence pack covers onboarding, payouts, disputes management, webhooks, and API testing, but contains no mention of fraud/credit-risk scoring per sub-merchant, anomaly alerts, or tools to pause payouts/offboard risky sellers.

   ⚑ 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
   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

   Tilled—none0/10

   The evidence pack covers merchant onboarding, payouts speed settings, disputes, and dashboard features, but contains no mention of international sellers, multi-currency support, FX handling, or local bank rail settlement outside the US. Tilled appears to be a US-focused payment facilitator platform with no documented cross-border/local-currency payout capability.

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

   Tilled~partialclaimed3/10

   Only one thin reference confirms that Tilled lets ops view a merchant's 'payout speed' in the Dashboard, implying some per-merchant payout timing configuration, but there is no documentation of specific schedule options (daily/weekly/monthly/manual) or instant payouts to cards/real-time rails. Missing for 10: explicit schedule types (daily/weekly/monthly/manual), instant payout to card support, real-time rails support, and confirmation that these are configurable per seller.

   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”

   proof ↗⚑ flag

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

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

   Tilled~partialclaimed4/10

   Tilled offers API access for core payment operations (payments, webhooks, batches, testing) but several UI-only functions like dispute management and payout speed viewing are explicitly documented as Dashboard-only, and merchant onboarding has a no-code Dashboard option alongside API options, suggesting UI and API are not fully at parity. missing for 10: evidence that disputes, payout configuration, and subscription management can be fully performed via API rather than only through the Dashboard, plus independent confirmation of full API/UI parity.

   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”
   • [claimed-docs] “Merchants can manage disputes through the Dashboard.”
   • [claimed-docs] “Merchants and ISVs can now view and manage all of their subscriptions within their Dashboard.”
   • [claimed-docs] “No-code option for software platforms to onboard a merchant.”
   • [claimed-docs] “By closing a batch via API, a store can ensure their transactions are settled at time of close or end of shift”

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

   Tilled—none0/10

   The evidence pack covers Tilled's managed PayFac features (onboarding, pricing templates, webhooks, dashboards, white-labeling) but contains no mention of a graduation path toward registered payment facilitation, economics changes, or control transitions without replatforming. Missing for 10: any documentation of a registered-PayFac upgrade path, economics/revenue-share changes at that tier, or migration mechanics that avoid replatforming.

   ⚑ 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
   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

   Tilled—none0/10

   The evidence pack contains only integration, onboarding, testing, and dashboard feature docs; none of it addresses an explicit documented split of liability for KYC/AML, card-network compliance, fraud losses, or seller misconduct between Tilled 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
   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

   Tilled—none0/10

   No evidence anywhere in the pack mentions 1099-K threshold tracking, tax form generation, delivery, filing, or a data-corrections workflow; the pack covers onboarding, payments, payouts, disputes, and dashboards but is silent on tax reporting entirely.

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

   Tilled~partialclaimed3/10

   Docs confirm a general API with keys and webhooks for real-time events, and payout speed/dispute management are documented, but they are explicitly described as Dashboard-based features rather than agent-callable API endpoints for reading balances, investigating payouts, or drafting dispute evidence. Missing for 10: explicit API endpoints/schemas for balances, payout investigation, and dispute evidence submission usable by an autonomous agent, plus any agent/automation-specific tooling or examples.

   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”
   • [claimed-docs] “Merchants can manage disputes through the Dashboard.”
   • [claimed-docs] “Webhooks provide real-time notifications to your application about events occurring on platform.”
   • [claimed-docs] “API keys are required to access API. To generate API keys through the Dashboard”

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

   Tilled~partialclaimed4/10

   Tilled's docs show API-driven merchant onboarding (create, pre-fill, and edit applications in `created`/`started` status) and dashboard progress tracking of onboarding steps, which supports part of the 'agent drives onboarding' story. However, there is no evidence of an MCP surface, no mention of scoped/restricted API credentials for agent use, and no explicit handling of 'requirements-due' states via API. missing for 10: MCP server/tool surface, scoped credential model for agents, explicit requirements-due state API.

   • [claimed-docs] “No-code option for software platforms to onboard a merchant.”
   • [claimed-docs] “Merchant applications with the `created` or `started` status can be pre-filled and edited on behalf of the merchant.”
   • [claimed-docs] “ISVs can see their progress item by item - creating API keys, submitting a merchant application, collecting a first payment, and more - righ…”
   • [claimed-docs] “API keys are required to access API. To generate API keys through the Dashboard”

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

   Tilled—none0/10

   No evidence pack items address fund segregation, custody of in-flight/held balances, yield on balances, or safeguarding from provider's own accounts; documentation covers API keys, payouts speed, disputes, and onboarding only. missing for 10: any mention of fund segregation/custody model, held-balance yield policy, or safeguarding disclosures.

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

   Tilled~partialclaimed4/10

   Docs show payout speed settings, merchant pricing templates, and dispute management, implying some money-tracking infrastructure, but there is no explicit documentation of per-seller balance views, platform fee account tracking, or charge-to-split-to-payout traceability/reconciliation. Missing for 10: explicit balance-by-seller/fee-account reporting, transaction-level traceability from charge through split to payout, and reconciliation tooling or statements.

   • [claimed-docs] “Merchant pricing is managed using pricing templates, which serve as a repository of pricing information for a specific payment method.”
   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”
   • [claimed-docs] “Merchants can manage disputes through the Dashboard.”

   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 drawn
   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

   Tilled~partialclaimed3/10

   Evidence shows settlement-related building blocks (batch closing/settlement per docs-5, payout visibility per docs-10, webhooks for event notifications per docs-4, and a hosted reporting console per docs-14) but nothing documents automated per-seller and rolled-up reconciliation reports, scheduled delivery, or finance-stack-consumable file/API exports. missing for 10: explicit reconciliation/settlement report generation, per-seller vs rolled-up aggregation, scheduled file exports or dedicated reporting API endpoints for finance systems.

   • [claimed-docs] “By closing a batch via API, a store can ensure their transactions are settled at time of close or end of shift”
   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”
   • [claimed-docs] “Webhooks provide real-time notifications to your application about events occurring on platform.”
   • [claimed-docs] “Enterprise partners have the ability to host their API, merchant onboarding, and reporting console experiences on a domain that reflects the…”

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

   Tilled~partialclaimed4/10

   Tilled documents per-seller pricing via merchant pricing templates (tilled-docs-9), which supports setting per-seller pricing, but there is no evidence of an application-fee/markup mechanism on transactions or of a dashboard/report that separates platform revenue from underlying processing costs. Missing for 10: explicit application fee or markup configuration per transaction, and a revenue-vs-processing-cost reporting view.

   • [claimed-docs] “Merchant pricing is managed using pricing templates, which serve as a repository of pricing information for a specific payment method.”

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

   Tilled~partialclaimed4/10

   Tilled's docs mention merchant pricing templates that let platforms set pricing per payment method, implying sell-rate control (tilled-docs-9), but there is no documented buy rate from Tilled or interchange-level cost visibility described anywhere in the evidence pack. missing for 10: explicit buy rate disclosure, interchange-level cost breakdown/visibility tools, and spread-management reporting.

   • [claimed-docs] “Merchant pricing is managed using pricing templates, which serve as a repository of pricing information for a specific payment method.”

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

   Tilled—none0/10

   No evidence pack item documents a coverage map of supported onboarding countries, local payment methods, or local-currency settlement; all citations relate to API/dashboard mechanics, merchant onboarding flow, and product journal updates rather than geographic/currency coverage. missing for 10: supported-country list, local payment method coverage, local-currency settlement documentation.

   ⚑ 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
   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

   Tilled~partialclaimed6/10

   Tilled's docs show a merchant onboarding API with multiple integration paths — a no-code hosted option and a fully custom API/UI option — plus white-labeled hosted onboarding for enterprise partners, matching the 'hosted flows and embeddable components' ask. However, the evidence never explicitly details KYC/KYB data collection, bank account linking steps, or terms-of-service acceptance as part of that flow. Missing for 10: explicit KYC/KYB field/process documentation, bank account linking API details, and terms acceptance mechanism.

   • [claimed-docs] “No-code option for software platforms to onboard a merchant.”
   • [claimed-docs] “Merchant applications with the `created` or `started` status can be pre-filled and edited on behalf of the merchant.”
   • [claimed-docs] “Customize and build your own UI”
   • [claimed-docs] “Enterprise partners have the ability to host their API, merchant onboarding, and reporting console experiences on a domain that reflects the…”

   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 Tilled
   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

   Tilled~partialclaimed4/10

   Tilled docs show merchant applications have progressive statuses (created/started) that can be pre-filled and edited over time, and ISVs get an item-by-item onboarding progress view in the Dashboard, suggesting some staged onboarding exists. However there is no explicit evidence of a tunable minimum-to-sell model gated by payout thresholds or clearly defined 'requirements-due' states per seller like a formal verification/eligibility system. Missing for 10: explicit documentation of minimum data required to start accepting payments, payout-threshold-triggered requirement escalation, and named per-seller requirements-due states.

   • [claimed-docs] “Merchant applications with the `created` or `started` status can be pre-filled and edited on behalf of the merchant.”
   • [claimed-docs] “ISVs can see their progress item by item - creating API keys, submitting a merchant application, collecting a first payment, and more - righ…”
   • [claimed-docs] “To view a merchant’s payout speed in the Dashboard”

   proof ↗⚑ flag