Agentspay
All posts

Stripe Agentic Commerce Pricing: ACP Shared Payment Token Fees, Country Availability and Machine Payment Costs

Agentspay · Aug 21, 2026 · 8 min read ·
Share
Agent Payments Console

Pick an agent

Payment intent

intent:

Policy evaluation

Human approval required

This spend is over your approval threshold. Approve it to issue a scoped card, or deny it.

Scoped virtual card issued

Agentspay

single-use

Wallet budget

spent of

Audit trail

Short answer: Stripe has published no separate rate card for agentic commerce or machine payments. The Agentic Commerce Suite announcement disclosed no fees, and the machine payments documentation discloses no surcharge. What Stripe does publish are two minimums that shape the build more than a price would: a card payment through a shared payment token has a floor of 0.50 USD, and a stablecoin payment has a floor of 0.01 USDC. If you are budgeting an agent payment stack, those numbers plus your ordinary Stripe processing rate are the parts you can actually pin down. Everything else quoted online belongs to a different line of the model.

This comes up constantly in planning conversations and it almost always goes the same way. Somebody has read that agentic commerce costs 4%, somebody else has read 2%, a third person is trying to work out whether they can charge a tenth of a cent per API call, and nobody can find a page on stripe.com that settles any of it. So here is the version that separates what is published from what is inferred, and what to put in the spreadsheet.

What Stripe does and does not publish

Stripe announced the Agentic Commerce Suite on December 11, 2025: a hosted endpoint for publishing product data to agents, a Checkout Sessions API that handles shipping and tax, Shared Payment Tokens as the payment primitive, and Radar extended with fraud signals specific to agent traffic. The announcement listed customers, listed platform partners, and listed no prices. Same story on the machine payments side, where an agent pays for an API or service programmatically over the Machine Payments Protocol or x402. Extensive documentation, no fee schedule.

The reasonable reading is that agentic transactions price as ordinary Stripe payments. Money settles in fiat into your Stripe balance, refunds run through the normal Refunds API, and reporting and multi-currency payouts behave exactly as they do for any other charge. Nothing in the docs suggests a separate product SKU with its own take rate. But since Stripe has not said so in writing, treat that as a working assumption to confirm with your account team rather than a quoted number, especially if you are at a volume where rates are negotiated anyway.

The two numbers that actually decide your architecture

Here is the part that matters more than the missing rate card, and it gets almost no coverage.

RailProtocolNetwork and currencyMinimum per transactionUS availability
Card via shared payment tokenMPPAny Stripe-supported currency0.50 USDAll US states
StablecoinMPPTempo, USDC.e0.01 USDCAll states except New York
StablecoinMPPSolana, USDC0.01 USDCAll states except New York
Stablecoinx402Base, USDC0.01 USDCAll states except New York

A fifty-cent floor on card payments sounds trivial until you try to meter something. If you want to charge per API call and a call is worth a fraction of a cent, the card rail simply cannot express your price. You have two ways out. Batch the calls into a settlement large enough to clear the floor, which means you are extending credit between settlements and carrying the risk that the agent disappears mid-window. Or move to stablecoins, where the floor drops fifty times to a cent and true per-call pricing becomes possible.

That is an architectural fork disguised as a pricing footnote, and the jurisdictional detail underneath it catches teams late. Shared payment tokens work for businesses in every US state. Stablecoin acceptance works in every US state except New York. If you sell to New York entities, or you are one, the stablecoin path has a hole in it and the card path with its fifty-cent floor is the only thing that covers your whole market. Find that out during architecture, not during legal review.

What does a Stripe ACP shared payment token cost?

Stripe publishes no separate fee for a shared payment token. An ACP shared payment token is a scoped credential, not a new pricing tier, so the transaction it authorizes is priced as an ordinary Stripe charge on whichever rail settles it. The only published numbers attached to the mechanism are floors: 0.50 dollars for a card charge made through a shared payment token, and 0.01 USDC for stablecoin settlement.

Anyone quoting you a 2% to 4% agentic commerce fee is quoting OpenAI's take rate on Instant Checkout orders, which is a merchant revenue share paid to the surface that sent the buyer. It is not a Stripe processing fee and it does not apply to your own agents transacting through your own account.

Which countries and US states support Stripe shared payment tokens?

Shared payment tokens are available to businesses in every US state. Stablecoin acceptance is available in every US state except New York. That single exclusion is the practical constraint, because it means the stablecoin path cannot cover a US-wide market on its own and the card path, with its 0.50 dollar floor, is the only rail that reaches every state.

Plan around that before you pick a settlement rail rather than after. If your agent volume is mostly sub-dollar and your buyers include New York entities, you will end up running both rails, and the routing logic between them is real engineering work that belongs in the cost model.

The 4% everyone quotes is not a Stripe fee

This is the single most common mix-up. The 4% figure attached to agentic commerce came from reporting on ChatGPT Instant Checkout, and it was a platform take rate charged by OpenAI on completed orders, on top of ordinary card processing. It was reported specifically in the context of Shopify merchants, Sam Altman has publicly referred to a rate closer to 2%, and OpenAI never published a rate card either. So the honest treatment is a 2% to 4% planning band, attributed, for that channel.

None of that is Stripe's pricing. It is the cost of distribution on one AI surface, and it belongs on a different line of your model, next to marketplace commissions and affiliate payouts rather than next to payment processing. It also may not survive: OpenAI deprioritized in-answer Instant Checkout in March 2026 and moved purchasing into merchant-branded apps, where the commercial arrangement is negotiated per app rather than set as a flat platform fee. If your business case depends on that number, it depends on the least stable input in the whole model.

The September 2026 update makes that clearer still. Shopify's published position on its Agentic Storefronts channel is that it carries no transaction fees beyond standard payment processing rates, and because ChatGPT-sourced buyers now typically complete on the merchant's own storefront, the platform take rate does not apply to most agentic orders at all. If you are modelling this for a Shopify catalog specifically, we break the arithmetic down order by order in what the Shopify ChatGPT sales fee actually costs, and the channel mechanics are in the Shopify agentic commerce guide.

How to actually model the cost

Five lines, in the order they bite:

  • Processing. Your ordinary Stripe rate on the settled amount. For most US businesses this is the number you already know and already negotiated.
  • Channel take rate. Zero if agents reach you directly through your own endpoints. Somewhere in the reported 2% to 4% band if you sell through an AI platform that charges for placement. Model both cases separately, because the second one is a distribution decision, not a payments decision.
  • The floor tax. If your unit price sits below the minimum for your chosen rail, the real cost is the batching machinery you have to build and the settlement risk you carry inside each window. This shows up as engineering time and bad debt, not as a fee, which is exactly why it gets left out of the first version of every model.
  • Integration. Stripe pitched the Suite against a status quo it described as taking up to six months per AI agent you support. Even collapsed to one integration, the product feed is real work: accurate identifiers, live inventory, current prices, shipping and returns terms, refreshed continuously. That feed is also the asset that carries over to whichever protocol wins, so it is the least wasted money on the list.
  • Governance. The one nobody budgets, covered below.

Does Stripe give you spending controls for the price?

No, and it is worth being precise about why, because this is not a gap you can close by reading the docs more carefully. A shared payment token is scoped to one seller, one maximum amount and one expiry. MPP settles a single call. An x402 challenge prices a single request. Each of those is a well-designed per-transaction authorization, and none of them keeps a running total. Nothing in the system knows that the agent holding this token already spent four thousand dollars this month across nine merchants and two rails, because nothing in the design was ever asked to.

Twenty individually valid authorizations still add up to a number nobody approved. That is the failure mode, and it is not unique to Stripe. It is equally true of Google's AP2, of the Agentic Commerce Protocol, and of x402, because a payment rail is scoped to authorize transactions rather than to govern budgets.

The evidence that this is a real operational gap rather than a vendor talking point is sitting in Stripe's own repository. An issue filed on April 6, 2026 against the Stripe Agent Toolkit asks for a governance layer: per-task spending ceilings beyond what an API key scope can express, merchant allowlists, human approval gates above a threshold, and a cryptographic audit trail tracing a payment back to the human who delegated the authority. It remains open. Someone building on Stripe hit exactly this wall and wrote it down.

The line item you will not see coming

The cost that surprises finance teams is not the processing rate. It is reconciliation. Agent purchases arrive with no session history, no requester, and a merchant descriptor nobody recognizes, three weeks after the fact. The same problem shows up wherever spending happens outside a procurement flow, which is why most teams already run some form of cloud and SaaS spend analysis to catch the subscriptions nobody remembers approving. Agent spend is that problem with a faster clock and no human to ask.

Budget for it as its own line. The question at close is never what Stripe charged. It is which agent spent this, who allowed it, under what rule, and can you prove it.

What to do with all of this

If you sell goods and want to be reachable from AI surfaces, the Agentic Commerce Suite is the shortest path and prices, as far as anyone can tell, like ordinary Stripe. Confirm that with your account team and move on. If you meter an API, the fifty-cent card floor versus the one-cent stablecoin floor is the decision that matters, and it should be made before you design the metering, not after. Check the New York exclusion against your customer base while you are there.

And if your company is on the buying side, running agents that spend rather than selling to them, none of this pricing is your actual problem. Your problem is that every rail here authorizes transactions one at a time and no rail totals them up. That control has to come from a layer above the rails, where each agent gets a hard budget it cannot structurally exceed, purchases above your threshold pause for human approval before money moves, and card spend, stablecoin settlement and metered API calls all land in one audit trail. For the fuller picture of what Stripe ships and where the edges are, see our breakdown of Stripe agentic commerce.

Try it in the sandbox

Give an agent a wallet, write a policy, and issue a scoped virtual card in an afternoon. Never moves money without policy.