MENU
Stripe Connect provides payment infrastructure for marketplaces and software platforms that need to onboard businesses, accept customer payments, route funds, and manage payouts across multiple parties. Its current architecture supports configurable connected accounts, embedded financial interfaces, several funds-flow models, risk and identity workflows, and platform-controlled payment pricing.
The surrounding payments landscape has also changed. Stripe now operates agentic-commerce products outside Connect, including Shared Payment Tokens, machine payments through x402 and MPP, an MCP server, and tools for AI-enabled checkout. For platforms evaluating agentic payments infrastructure, the relevant question is therefore not whether Stripe supports agents at all, but how Connect's platform-payment model fits with the authorization, metering, pricing, and settlement requirements of autonomous AI services.
Stripe Connect is designed for businesses that facilitate payments between multiple parties. A marketplace can collect money from a buyer and route proceeds to sellers, while a software platform can let its business customers accept payments through accounts connected to the platform.
Connected accounts determine who receives funds, who pays Stripe fees, who is responsible for negative balances, and which party manages onboarding requirements. Stripe's newer Accounts v2 API makes those responsibilities more configurable by allowing accounts to receive merchant, customer, or recipient functionality as needed.
Connect covers several core platform-payment requirements:
Connect can therefore cover much of the financial relationship between a platform and the businesses operating through it.
Standard, Express, and Custom accounts remain part of Stripe's v1 account model, but they no longer describe every available Connect configuration.
Stripe now recommends controller properties for more flexible v1 integrations and Accounts v2 for newer configurable account structures. Accounts v2 can assign merchant functionality for accepting payments, customer functionality for paying the platform, and recipient functionality for receiving transfers without requiring every account to follow one predefined account type.
This matters for new implementations because choices around dashboards, fee responsibility, negative-balance liability, and requirement collection should be modeled around the platform's actual operating responsibilities rather than selected solely from the three legacy labels.
Stripe Connect pricing now depends significantly on who controls pricing for connected accounts.
When Stripe handles pricing, Stripe collects processing fees directly from connected accounts and the platform does not incur additional Connect account, payout-volume, tax-reporting, or per-payout fees under that model. Platforms can also choose to control pricing themselves, in which case Stripe charges the platform and allows it to set payment pricing for its users.
For U.S. platforms that handle pricing, Stripe currently lists:
An account counts as active in a month when a payout is sent to its bank account or debit card. Pricing varies by country and configuration, so international platforms should use the rates applicable to the entities and markets involved.
This makes total cost dependent on more than transaction volume. Connected-account activity, payout frequency, charge structure, geography, payment methods, and whether the platform or Stripe controls pricing can all affect the economics.
Connect supports several approaches to moving funds between the platform, customer, and connected account.
The correct structure depends on which entity creates the payment, which party should appear as the business of record, and whether funds need to be divided among several recipients.
Three common Connect funds flows are:
Separate charges and transfers are useful when several recipients need to share proceeds from one customer payment or when the final recipients are not known when the charge is created.
The tradeoff is additional platform responsibility. Refunds, disputes, fee allocation, balance availability, and transfer reversals behave differently depending on the chosen flow, so platforms need to model those responsibilities before implementation.
Connect can schedule payouts automatically, trigger manual payouts, or provide eligible connected accounts with Instant Payouts. Standard payouts typically arrive after submission according to the banking and regional schedule, while Instant Payouts are designed to reach eligible accounts much faster.
Platforms can also control payout timing for relevant account configurations and retain funds in the platform balance when using certain charge structures.
For autonomous applications, the related governance question becomes broader than payout timing. Groups and budgets illustrate how machine spending can also be bounded before a transaction occurs, rather than managed only after funds have entered the platform-payment flow.
Connect is not a standalone replacement for every Stripe payment product. It coordinates platform and connected-account relationships while Stripe Payments, Checkout, Elements, Radar, Billing, and other products provide additional payment capabilities.
That modular structure lets platforms select the user interface, payment method, risk model, and funds flow that fit their use case.
Within the wider Stripe stack, a Connect platform can use capabilities such as:
PCI DSS remains an important consideration whenever payment credentials are handled. Businesses should evaluate how hosted, embedded, or custom collection changes their own PCI scope rather than assuming every Connect integration carries the same compliance responsibility.
Implementation complexity depends heavily on how much of the experience the platform wants to control.
A platform using Stripe-hosted onboarding and prebuilt payment interfaces can offload more front-end and compliance work. Fully embedded or highly customized implementations require more decisions around account configuration, webhooks, payment flows, disputes, payouts, risk, and user-facing financial interfaces.
There is no reliable universal implementation timeline. Marketplace structure, jurisdictions, account configurations, payout rules, tax requirements, and existing application architecture can change the amount of work substantially.
For paid machine-accessible services, working payment integration examples can provide a narrower implementation path when the requirement is to protect an API, MCP tool, or digital resource rather than construct a complete marketplace.
Stripe's position in agentic commerce has changed materially since early comparisons of Connect with agent-payment infrastructure.
Stripe now documents agent-first development tooling, an MCP server, Shared Payment Tokens, machine payments through x402 and MPP, Agentic Commerce Protocol support, and usage-based billing for LLM tokens and API calls.
This makes it inaccurate to describe Stripe as purely human-centric payment infrastructure.
Shared Payment Tokens let an agent receive scoped authority to use a customer's payment method for a transaction. Usage controls can include a maximum amount and expiration window, while the seller receives a limited payment credential rather than the original payment method. The feature is currently in public preview and subject to regional availability.
Stripe also supports machine payments through x402 for stablecoin transactions and MPP for machine-readable HTTP 402 payment flows. Its x402 implementation currently uses stablecoin payments and an external facilitator for verification and on-chain settlement, while MPP supports Shared Payment Tokens and stablecoin payment paths.
Stripe's MCP server allows AI agents and development environments to interact with Stripe resources through tool calls. Connect platforms can make MCP calls in the context of connected accounts using restricted access keys and the relevant account header.
The broader ecosystem is developing quickly. Google's Agent Payments Protocol introduces payment mandates for agent-led commerce, while A2A has grown to participation from more than 150 organizations. These standards sit alongside x402, MPP, MCP, and other approaches to machine commerce.
Connect remains most directly focused on the relationship between platforms and connected accounts.
Agentic Commerce Suite, Shared Payment Tokens, machine-payment protocols, and AI billing extend Stripe into agent-led transactions, but these capabilities are separate pieces of the broader Stripe stack rather than one Connect-specific agent-payment layer. Some are also currently in public, private, or frontier preview stages.
For AI businesses, the architecture therefore needs to account for two distinct questions:
Connect directly addresses the first. The second increasingly involves Stripe's newer agentic products or a purpose-built machine-payment layer.
Stripe Connect remains relevant for marketplaces and software platforms managing payments across many participating businesses, but several implementation decisions deserve particular attention.
Account architecture: New teams should evaluate Accounts v2 and controller-based configurations rather than assuming Standard, Express, or Custom is the only design choice.
Cost structure: Connect pricing changes according to who controls payment pricing, account activity, payouts, funds routing, geography, and optional services.
Operational responsibility: The chosen charge flow determines how refunds, disputes, negative balances, and transfers affect the platform and connected accounts.
Agentic product maturity: Stripe now supports several agent-payment standards and primitives, but some current capabilities remain preview products with geographic or payment-method constraints.
Teams planning autonomous AI products should therefore evaluate Connect as part of the wider payments architecture rather than treating marketplace orchestration and agent-payment execution as the same requirement.
Nevermined focuses specifically on the transaction lifecycle for AI agents and monetized machine-accessible services. The platform combines payment authorization, workload pricing, metering, delegated spending, settlement, and organization-level controls within an agent-focused architecture.
Nevermined provides first-class support for the x402 payment protocol.
A protected API, MCP tool, agent, or digital resource can return an HTTP 402 response with payment requirements. The caller supplies a payment authorization, the facilitator verifies it before processing, and settlement occurs after successful work.
This puts the economic check in the same lifecycle as the workload. Expensive model calls, research jobs, data access, and tool executions do not need to run before payment permission is established.
AI services can use different economic units without forcing every workload into a flat transaction amount.
Nevermined documents variable and usage-based pricing for tokens, request complexity, elapsed time, and usage tiers. The final amount can therefore reflect the work performed while remaining connected to payment verification and settlement.
This is particularly useful for workloads where the final consumption cannot be known precisely before execution.
Agents acting as buyers need spending authority that is narrower than unrestricted access to a user's payment card.
Users can delegate a spending budget with an explicit amount, duration, optional transaction limit, API-key scope, and revocation. Card information is tokenized through supported payment providers rather than handed directly to the agent.
Nevermined supports both nvm:erc4337 and nvm:card-delegation x402 schemes. The former uses ERC-4337 UserOperations and session keys for crypto transactions, while the latter supports delegated card payments through Stripe, Braintree, or Visa.
Individual agent limits become harder to manage as deployments expand across teams.
Nevermined's groups and budgets let organizations centralize funding while applying separate spending ceilings to groups. Its observability and monitoring tools connect payment activity with request, usage, cost, and performance information.
These controls let financial policy remain outside the agent's own reasoning while agents continue to transact inside defined boundaries.
Nevermined publicly documents ISO 27001 certification, SOC 2 Type II auditing, PCI SAQ-D compliance, and GDPR controls through its security and compliance resources. Card data is captured and tokenized before it enters Nevermined systems, and raw PANs are not stored.
For teams moving agent-payment infrastructure through security and procurement review, those controls provide a documented baseline for the payment layer.
Nevermined's documentation provides a working payment integration in five minutes for an agent API, MCP tool, or protected resource. Teams can begin with payment validation and settlement, then add workload-specific pricing, card delegation, budgets, and observability as the service expands.
Nevermined currently charges 1–2% of settled transaction volume, with no setup fees or minimums. The free plan includes up to 20 agents and 10 payment plans, while paid organization tiers add higher limits and operating tools.
For AI products where the transaction itself belongs to an agent, Nevermined keeps authorization, pricing, metering, spending controls, and settlement connected to the machine workflow.
Stripe Connect is primarily used by marketplaces and software platforms that need to manage payments involving multiple businesses or recipients. It supports connected-account onboarding, payment acceptance, funds routing, platform fees, and payouts. Its newer account APIs also give platforms more flexibility over responsibilities such as fees, losses, dashboards, and account functionality.
Standard, Express, and Custom remain supported within Stripe's v1 account model, but they are no longer the only way to structure a Connect integration. Stripe now supports controller properties and Accounts v2 configurations that define capabilities and responsibilities more granularly. New platforms should evaluate the current account model against their specific onboarding, risk, dashboard, and funds-flow requirements.
Stripe now provides several agentic-commerce capabilities, including Shared Payment Tokens, x402, MPP, an MCP server, and agent-commerce tooling. Availability and maturity vary by product, with several features currently offered through public, private, or frontier previews. For teams that need payment verification and settlement tied directly to monetized AI workloads, the transaction architecture should be evaluated separately from marketplace account orchestration.
Agent spending controls should be enforced by the payment infrastructure rather than relying only on model instructions. A useful control set includes explicit spending limits, expiration, transaction boundaries, revocation, and auditable activity. Teams can delegate a spending budget when card-funded agents need reusable purchasing authority within those limits.
AI platforms should evaluate how each workload is priced, how payment authority is verified before execution, how consumption is metered, and how settlement occurs after successful work. They should also consider agent spending controls, payment rails, organization-level budgets, protocol interoperability, and transaction observability. Agentic payments infrastructure becomes relevant when those requirements need to operate directly inside autonomous machine workflows.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
