Task-market agents can discover a job, check the reward, accept, submit, and settle.
The part most payment-primitive discussions still hide is the provider choice: why this payment backend, for this route, under this budget and refund policy?
Rhumb scores 1,038 services across 20 dimensions for agent compatibility. For this payment-provider cut, the useful artifact is not a generic leaderboard. It is a planner-readable provider_profile_receipt that sits beside the wallet, escrow, or settlement proof.
provider_profile_receipt = {
provider: "stripe",
rhumb_score: 8.1,
execution_score: 9.0,
access_score: 6.6,
confidence: 0.90,
route_class: "software_task_market_checkout",
selected_because: ["webhook_contract", "refund_path", "usage_billing", "high_confidence_docs"],
rejected_neighbors: ["paypal: buyer-trust constraint absent", "adyen: enterprise-acquirer setup not needed"],
retry_policy: "idempotency_key_required",
evidence_version: "rhumb-scorecard-2026-05-27"
}
Ranked payment APIs for agent task markets
| Rank | Provider | Rhumb score | Execution | Access | Confidence | Receipt field | Best route |
|---|---|---|---|---|---|---|---|
| 1 | Adyen | 8.8 | 8.9 | 8.5 | 61% | enterprise_acquiring_required |
Enterprise marketplaces with acquiring, risk controls, regional methods, and payout machinery. |
| 2 | Braintree | 8.3 | 8.5 | 8.0 | 56% | paypal_ecosystem_constraint |
PayPal-adjacent card processing where the account model is already binding. |
| 3 | Stripe | 8.1 | 9.0 | 6.6 | 90% | software_native_default |
Software-native checkout, invoices, usage billing, webhooks, and refunds. |
| 4 | Lemon Squeezy | 6.8 | 7.1 | 6.2 | 52% | merchant_of_record_selected |
Small software-product markets where merchant-of-record simplicity beats orchestration depth. |
| 5 | Square | 6.3 | 7.3 | 5.2 | 92% | physical_commerce_constraint |
Markets touching locations, catalogs, inventory, appointments, or physical-world commerce. |
| 6 | PayPal | 4.9 | 5.9 | 3.7 | 95% | buyer_trust_constraint |
Markets where buyer trust, wallet demand, or payout expectations explicitly require PayPal. |
The practical default
For a new autonomous task market, default to Stripe when the market is software-native and web-delivered.
Promote Adyen when enterprise acquiring, regional coverage, and risk operations become binding.
Use Braintree or PayPal when PayPal ecosystem demand is explicit.
Use Square only when the task market has physical-commerce objects.
Use Lemon Squeezy when merchant-of-record packaging matters more than payment orchestration depth.
That is not a brand preference. It is the current result of Rhumb's scored service index: 1,038 services across 92 categories, evaluated on agent execution, access readiness, confidence, and failure-mode surfaces.
The receipt matters more than the ranking
A task-market settlement receipt proves money moved. It does not prove the route was sane.
A provider-profile receipt should answer:
- Why was this payment API selected for the route class?
- Which nearby providers were rejected, and why?
- What confidence level backs the selection?
- What retry/idempotency rule has to hold before funds move?
- Which webhook/refund/account-state failure modes should the agent expect?
- Does onboarding require dashboard-only setup that should make the agent refuse or price in setup risk?
For open task markets, the score becomes a pre-acceptance filter. If a task requires a provider with weak access readiness, the agent should price in setup risk or reject the job before settlement is attempted.
For framework adapters, expose provider selection as metadata, not hidden plumbing. LangChain, AutoGen, and CrewAI agents need a planner-readable denial reason when the payment backend is wrong for the route.
Full canonical version with service links: https://rhumb.dev/blog/task-market-payment-provider-profiles
