Rank #5 of 6 in Marketplace & Platform Payments
Try itExperimental
See what an agent can do with Rainforest before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$curl -sL https://docs.rainforestpay.com/llms.txt | head -3recorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Embedded experience — stories about embedded experience in this arenaEmbedded experienceevidence →
Stories about embedded experience in this arena
Funds routing — stories about funds routing in this arenaFunds routingevidence →
Stories about funds routing in this arena
Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputesevidence →
Stories about marketplace disputes in this arena
Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payoutsevidence →
Stories about marketplace payouts in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Payfac liability — stories about payfac liability in this arenaPayfac liabilityevidence →
Stories about payfac liability in this arena
Platform agent access — stories about platform agent access in this arenaPlatform agent accessevidence →
Stories about platform agent access in this arena
Platform ledger — stories about platform ledger in this arenaPlatform ledgerevidence →
Stories about platform ledger in this arena
Platform monetization — stories about platform monetization in this arenaPlatform monetizationevidence →
Stories about platform monetization in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
n/a
Seller onboarding — stories about seller onboarding in this arenaSeller onboardingevidence →
Stories about seller onboarding in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where Rainforest stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
~6/10
unlocks → Official SDKs · Scoped API keys · MCP server · Machine-readable spec · Versioning policy · Official CLI · Headless / CI
Subscribe to events via webhooks
✓7/10
Build against official SDKs
—0/10
Issue scoped/least-privilege API credentials for an agent
—–
Connect an agent via an official MCP server
—–
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
—0/10
Test against a sandbox environment without touching production data
✓7/10
unlocks → Headless / CI
Explore an interactive API reference with runnable examples
—0/10
Docs for agents
Point an agent at llms.txt or agent-oriented docs
✓8/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
n/an/a
Operate the product with natural-language commands
—–
Plug MCP servers into this product so it can use their tools
n/an/a
Get AI-generated insights and suggestions from my data inside the product
n/an/a
Set up automations that run autonomously in the background
—–
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Embedded experience — stories about embedded experience in this arenaEmbedded experience
Stories about embedded experience in this arena
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand
~6/10
In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments
~5/10
Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me
~3/10
Funds routing — stories about funds routing in this arenaFunds routing
Stories about funds routing in this arena
Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented
—0/10
Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented
—0/10
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects
~5/10
Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputes
Stories about marketplace disputes in this arena
Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically
~3/10
Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actors
—–
Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payouts
Stories about marketplace payouts in this arena
International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires
—0/10
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller
~5/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Payfac liability — stories about payfac liability in this arenaPayfac liability
Stories about payfac liability in this arena
There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming
—0/10
The responsibility split is explicit — who owns KYC/AML, card-network compliance, fraud losses, and seller misconduct between me and the provider, in the docs rather than the contract's fine print
—–
Seller tax reporting is handled — 1099-K thresholds tracked, forms generated, delivered, and filed, with the data corrections workflow documented
—–
Platform agent access — stories about platform agent access in this arenaPlatform agent access
Stories about platform agent access in this arena
An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
~4/10
An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
~4/10
The platform is ready for agent buyers — documented support for agent-initiated checkout on marketplace transactions (agentic-commerce protocols, delegated payment credentials) that works with split funds flows
n/an/a
Platform ledger — stories about platform ledger in this arenaPlatform ledger
Stories about platform ledger in this arena
Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accounts
—0/10
The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny
~5/10
Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
~3/10
Platform monetization — stories about platform monetization in this arenaPlatform monetization
Stories about platform monetization in this arena
Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
~6/10
I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread
✓8/10
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Seller onboarding — stories about seller onboarding in this arenaSeller onboarding
Stories about seller onboarding in this arena
Sellers can join from where they are — supported onboarding countries, local payment methods, and local-currency settlement documented as a coverage map, not discovered ticket by ticket
—0/10
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
✓8/10
Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller
—0/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | partial | 6/10 | Tprobed | |
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | untested | none yet | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | n/a | untested | none yet | |
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Cclaimed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | n/a | untested | none yet | |
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | full | 7/10 | Cclaimed | |
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms C Onboarding api | developer | Seller onboarding — stories about seller onboarding in this arenaSeller onboarding | 3 | full | 8/10 | Cclaimed | |
Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs G Application fees | founder | Platform monetization — stories about platform monetization in this arenaPlatform monetization | 3 | partial | 6/10 | Cclaimed | |
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller C Payout schedules | ops user | Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payouts | 3 | partial | 5/10 | Cclaimed | |
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects C Splits | developer | Funds routing — stories about funds routing in this arenaFunds routing | 3 | partial | 5/10 | Cclaimed | |
The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny C Ledger visibility | finance lead | Platform ledger — stories about platform ledger in this arenaPlatform ledger | 3 | partial | 5/10 | Cclaimed | |
An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials C Agent onboarding | ai-native user | Platform agent access — stories about platform agent access in this arenaPlatform agent access | 3 | partial | 4/10 | Tprobed | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | partial | 3/10 | Cclaimed | |
Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically C Dispute handling | ops user | Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputes | 3 | partial | 3/10 | Cclaimed | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | n/a | untested | none yet | |
I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread G Buy rates | finance lead | Platform monetization — stories about platform monetization in this arenaPlatform monetization | 2 | full | 8/10 | Cclaimed | |
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand C Embedded components | developer | Embedded experience — stories about embedded experience in this arenaEmbedded experience | 2 | partial | 6/10 | Cclaimed | |
In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments C Omnichannel | founder with offline sellers | Embedded experience — stories about embedded experience in this arenaEmbedded experience | 2 | partial | 5/10 | Cclaimed | |
An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces C Agent money ops | ai-native user | Platform agent access — stories about platform agent access in this arenaPlatform agent access | 2 | partial | 4/10 | Tprobed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | partial | 4/10 | Cclaimed | |
Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule C Recon exports | developer | Platform ledger — stories about platform ledger in this arenaPlatform ledger | 2 | partial | 3/10 | Cclaimed | |
Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me C Seller reporting | ops user | Embedded experience — stories about embedded experience in this arenaEmbedded experience | 2 | partial | 3/10 | Cclaimed | |
Funds can wait — hold seller funds in a balance until delivery or dispute windows pass, release on my schedule or trigger, with the escrow-like mechanics and their limits documented C Holds release | developer | Funds routing — stories about funds routing in this arenaFunds routing | 2 | none | 0/10 | ||
International sellers get paid properly — local-currency payouts, documented FX handling, and settlement to local bank rails rather than expensive wires C Cross border | finance lead | Marketplace payouts — stories about marketplace payouts in this arenaMarketplace payouts | 2 | none | 0/10 | ||
Onboarding friction is tunable — collect the minimum to start selling and gather the rest before payout thresholds, with clear requirements-due states per seller C Progressive requirements | ops user | Seller onboarding — stories about seller onboarding in this arenaSeller onboarding | 2 | none | 0/10 | ||
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | 0/10 | ||
Platform funds have a home — clarity on where in-flight and held funds sit, whether balances earn yield, and how money is segregated from the provider's own accounts C Funds custody | finance lead | Platform ledger — stories about platform ledger in this arenaPlatform ledger | 2 | none | 0/10 | ||
Refunds and chargebacks that exceed a seller's balance are recoverable — automatic debits against future earnings or their bank account, with the liability order documented C Negative balances | finance lead | Funds routing — stories about funds routing in this arenaFunds routing | 2 | none | 0/10 | ||
Sellers can join from where they are — supported onboarding countries, local payment methods, and local-currency settlement documented as a coverage map, not discovered ticket by ticket C Global coverage | founder | Seller onboarding — stories about seller onboarding in this arenaSeller onboarding | 2 | none | 0/10 | ||
There's a path up the stack — start on the managed model and graduate toward registered payment facilitation with more economics and control, without replatforming C Graduation path | founder | Payfac liability — stories about payfac liability in this arenaPayfac liability | 2 | none | 0/10 | ||
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | n/a | untested | none yet | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | n/a | untested | none yet | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | untested | none yet | |
Seller tax reporting is handled — 1099-K thresholds tracked, forms generated, delivered, and filed, with the data corrections workflow documented C Tax forms | finance lead | Payfac liability — stories about payfac liability in this arenaPayfac liability | 2 | none | untested | none yet | |
The platform is ready for agent buyers — documented support for agent-initiated checkout on marketplace transactions (agentic-commerce protocols, delegated payment credentials) that works with split funds flows C Agentic commerce | developer | Platform agent access — stories about platform agent access in this arenaPlatform agent access | 2 | n/a | untested | none yet | |
The responsibility split is explicit — who owns KYC/AML, card-network compliance, fraud losses, and seller misconduct between me and the provider, in the docs rather than the contract's fine print C Responsibility split | ops user | Payfac liability — stories about payfac liability in this arenaPayfac liability | 2 | none | untested | none yet | |
Watch risk across my seller portfolio — fraud and credit-risk signals per sub-merchant, alerts on anomalous sellers, and tools to pause payouts or offboard bad actors C Portfolio risk | ops user | Marketplace disputes — stories about marketplace disputes in this arenaMarketplace disputes | 2 | none | untested | none yet | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | n/a | untested | none yet |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 36 stories with headroom
What would move Rainforest’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productConnect an agent via an official MCP server
nonemoves agent-readyimpact 45
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".
Agenticness — how well agents can access and operate the productSet up automations that run autonomously in the background
nonemoves Built-in AIimpact 30
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".
Agenticness — how well agents can access and operate the productRun the product headlessly / in CI for automation
nonemoves agent-readyimpact 30
Missing: cLI or SDK for automation, explicit CI/headless usage examples, any agent/automation-oriented tooling.
Agenticness — how well agents can access and operate the productOperate the product with natural-language commands
nonemoves Built-in AIimpact 30
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".
Agenticness — how well agents can access and operate the productUse an official CLI
nonemoves agent-readyimpact 30
Missing: any mention of a CLI, its installation, or command reference.
Agenticness — how well agents can access and operate the productIssue scoped/least-privilege API credentials for an agent
nonemoves agent-readyimpact 30
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.
Agenticness — how well agents can access and operate the productBuild against official SDKs
nonemoves agent-readyimpact 30
Missing: any documented SDK (e.g., Node/Python/Java client libraries), package registry listing, or SDK quickstart guide.
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
Missing: evidence of a 'try it' console, runnable code samples, or OpenAPI-based interactive explorer.
Showing the top 8 of 36 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map7 surfaces · 19 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
docs17 stories
- Point an agent at llms.txt or agent-oriented docs
- Drive the product through a documented public API
- Subscribe to events via webhooks
- Test against a sandbox environment without touching production data
- Define rules that trigger actions automatically on events
- Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand
- In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online payments
- Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me
- Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objects
- Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per seller
- Do everything through the API that I can do in the UI
- An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
- An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
- The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny
- Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
- Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
- Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
rainforestpay.com7 stories
- Test against a sandbox environment without touching production data
- Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brand
- Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting me
- Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automatically
- The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the penny
- Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedule
- Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
API reference6 stories
- Point an agent at llms.txt or agent-oriented docs
- Drive the product through a documented public API
- Do everything through the API that I can do in the UI
- An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
- An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
- Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the forms
llms.txt3 stories
OpenAPI spec3 stories
- Drive the product through a documented public API
- An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfaces
- An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentials
Pricing docs2 stories
- Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costs
- I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spread
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$curl -sL https://docs.rainforestpay.com/llms.txt | head -3reproduced$ curl -sL https://docs.rainforestpay.com/llms.txt | head -3 # Rainforest Docs Documentation > Documentation for Rainforest Docs
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
0 of 11 testable claims verified · 0 contradicted → integrity 0/100
15 distinct capability claims found in Rainforest’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
0
Verified
11
Unverified
0
Contradicted
8
Undersold
Unverified (15)
“Processes payments in person via a physical device”
In-person works on the same stack — terminals or tap-to-pay SDKs that settle into the same seller balances and reporting as online paymentspartialproof ↗
“Embeds a low-code payment component directly into a platform's UI”
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brandpartialproof ↗
“Creates a merchant account via an initial merchant application”
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the formsfullproof ↗
“Splits a single payment amount across multiple parties in a few API steps”
Split one charge among any set of parties — route funds to multiple sellers, take my cut, and reverse or adjust the split later, all as first-class API objectspartialproof ↗
“Updates a merchant's deposit/payout frequency via the API”
Payouts run on the schedule each seller needs — daily, weekly, monthly, or manual, plus instant payouts to cards or real-time rails where supported, configurable per sellerpartialproof ↗
“Lets integrators subscribe to webhook events for various resources”
“Provides sandbox test card numbers that simulate specific payment outcomes”
Test against a sandbox environment without touching production datafullproof ↗
“Offers a visual studio to design the embedded payment component”
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brandpartialproof ↗
“Uses buy-rate, interchange-plus pricing with no revenue split taken by Rainforest”
I control the economics — a documented buy rate from the provider and freedom to set the sell rate my sellers see, with interchange-level cost visibility to manage the spreadfullproof ↗
“Lets platform set its own merchant pricing, keeping any interchange savings”
Payments are a revenue line — take an application fee or markup on every transaction, set per-seller pricing, and see my payments revenue reported distinctly from processing costspartialproof ↗
“Provides pre-built embeddable components for payments, reporting, chargebacks, and onboarding”
Seller-facing surfaces are embeddable — white-label components or APIs for balances, payouts, and transaction history that live inside my product under my brandpartialproof ↗
“Provides pre-built embeddable components for payments, reporting, chargebacks, and onboarding”
Sellers can self-serve their money questions — per-seller statements, payout reconciliation reports, and exports that let their bookkeeper close the month without contacting mepartialproof ↗
“Provides pre-built embeddable components for payments, reporting, chargebacks, and onboarding”
Disputes are managed per seller — chargebacks land against the right sub-merchant, evidence is submitted via API or dashboard, and outcomes flow back into seller balances automaticallypartialproof ↗
“Provides pre-built embeddable components for payments, reporting, chargebacks, and onboarding”
Onboard a seller through the API — KYB and KYC, bank account linking, and terms acceptance — with hosted flows and embeddable components when I don't want to build the formsfullproof ↗
“Offers full end-to-end sandbox testing with realtime API logs”
Test against a sandbox environment without touching production datafullproof ↗
Undersold (8)
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Drive the product through a documented public APIpartialproof ↗
Define rules that trigger actions automatically on eventspartialproof ↗
Do everything through the API that I can do in the UIpartialproof ↗
An agent can work the money side — read balances and payouts, investigate a seller's missing payout, draft dispute evidence — against documented, agent-usable surfacespartialproof ↗
An agent can run seller operations — create accounts, drive onboarding to completion, and answer requirements-due states through the API or an MCP surface with scoped credentialspartialproof ↗
The platform's money is legible — balances by seller and by my own fee accounts, every movement traceable from charge through split to payout, reconcilable to the pennypartialproof ↗
Reconciliation is automatable — settlement and balance reports per seller and rolled up, delivered as files or APIs my finance stack consumes on schedulepartialproof ↗
Claims outside our story set (3)
Real capability claims found in Rainforest’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Processes online payments”
source ↗“Stores payment methods for later use”
source ↗“Supports card, PayPal, Venmo, PayPal Pay Later, ACH, and Apple Pay as payment methods”
source ↗
Business model
Buy-rate interchange-plus with no revenue share — volume-tiered roughly 0.20-0.30% + $0.20-$0.30 per card transaction and $0.20 per ACH item; the pricing page is a calculator that hands off to sales at higher volume.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
