When an AI agent buys something from your store, you are still the merchant of record, you still choose the payment provider, and you still own every refund and dispute that follows. What changes is the credential. Instead of a card number you receive a single-use token that names your store, carries a maximum amount and stops working at a timestamp. OpenAI's documentation is blunt about the division of labour: "OpenAI is not the merchant of record in the Agentic Commerce Protocol. Merchants are expected to bring their own PSP and handle payments just as they do for accepting any other digital payment" (opened 29 July 2026). Read that as good news about control and a warning about liability, then read the token's fields, because they forbid things your checkout probably does today.
Who does what, once an agent is in the loop
The Agentic Commerce Protocol, an open standard Stripe describes as created by Stripe, OpenAI and Meta, splits a purchase across three parties. This table is built from the duties the OpenAI documentation assigns explicitly.
| Duty | Agent (ChatGPT) | You (merchant) | Your PSP |
|---|---|---|---|
| Discovering the product | Reads your feed | Supplies a sample feed and daily snapshots | - |
| Rendering checkout | Yes | Supplies prices, options, availability | - |
| Validating the buyer and address | - | Yes | - |
| Calculating and charging sales tax | - | Yes | - |
| Risk scoring, accept or decline | - | Yes | Provides signals |
| Holding the card credential | Requests a scoped grant | Not unless PCI DSS level 1 with its own vault | Yes |
| Refunds and disputes | - | Yes | Processes them |
| Fulfilment | - | Yes | - |
Every row where the middle column says yes is a row where the money comes out of your account when it goes wrong. Nothing in the specification moves dispute liability to the agent. If you have been treating agentic commerce as a channel that arrives with somebody else's fraud team attached, it does not.
What is actually inside the token
The Delegated Payment Spec (opened 29 July 2026) states it plainly: "The delegated payment is single-use and set with allowances." The allowance object carries these fields, and each one removes a behaviour you may currently rely on.
| Field | What it does | What it stops |
|---|---|---|
max_amount | "Max amount the payment method can be charged for" | Charging more than the quoted total: no post-checkout shipping correction, no weight-based adjustment |
expires_at | RFC 3339 timestamp after which the grant is dead | Delayed capture on a slow manual review, or charging when stock arrives |
currency | ISO-4217 code | Settling the order in a different currency than quoted |
merchant_id | Scopes the grant to one merchant, 256 characters maximum | Reuse across your other storefronts or brands |
checkout_session_id | Binds the token to the session that created it | Detaching payment from the cart it was approved for |
reason | Enum, currently only one_time | Saving it on file: no subscriptions, no repeat billing, no split shipment charged twice |
Stripe's implementation is tighter still. Its shared payment token documentation (opened 29 July 2026) says "An SPT is a scoped grant to use the customer's payment method. The agent grants SPTs to your Stripe profile, each with usage and expiration limits," and then removes the ambiguity about headroom: "The agent sets the maximum amount to match the total amount of the transaction." Not the total plus a buffer. The total.
The three retail habits that break first
Adjusting the order after checkout. If your fulfilment team routinely adds four dollars of shipping when the parcel turns out heavier, that charge has nowhere to go. The token is capped at the amount the buyer approved. Your options are to quote shipping correctly at checkout or to absorb the difference.
Charging when the item ships. Plenty of small stores authorise at order and capture at dispatch, days later. An expiry timestamp turns that into a race. Decide your capture window before you enable the channel, not after a backordered item misses it.
Anything recurring. With reason limited to one_time, a subscription cannot start from an agent checkout on this rail. If your product is a subscription, the agent can sell the first period only if you model it as a single purchase, and you will need a separate consented path for the renewals.
Charging the token, and who may hold it
There is a fork here that decides most of the work. The specification says: "Directly integrating with OpenAI via the Delegated Payment Spec is only for PSPs or PCI DSS level 1 merchants using their own vaults." If that is not you, and for an independent store it almost certainly is not, you use a provider's implementation and never touch the raw credential.
On Stripe that means one API call. You create a PaymentIntent with payment_method_data[shared_payment_granted_token] set to the spt_ identifier, plus amount, currency and confirm=true. The usage limits arrive as a usage_limits object containing currency, expires_at and max_amount. Geography matters: Stripe states that shared payment tokens "are available to agents, customers, and sellers in the US and Canada." Outside those two countries this rail is not open to you yet, whatever your feed says.
If you do build the delegation endpoint yourself, it is a POST to /agentic_commerce/delegate_payment carrying Authorization, Signature, Timestamp, Idempotency-Key, Request-Id, Content-Type, Accept-Language, User-Agent and API-Version headers, returning HTTP 201 with a token id prefixed vt_. Reuse an idempotency key with different parameters and you get HTTP 409 with idempotency_conflict. That error is a feature: an agent retrying a network timeout must not create a second order.
The order to do this in
- Fix the feed first. No feed, no agent, no payment. The identifiers, pricing, inventory and fulfilment attributes are the same hygiene Google Shopping has always demanded, and OpenAI asks for a sample feed for validation plus daily snapshots.
- Confirm your PSP supports the rail in your country. For Stripe today that means a US or Canadian seller account.
- Audit your capture timing. Write down the longest gap between order and capture in the last 90 days. If it exceeds a few hours, fix it before enabling anything.
- Audit your shipping quotes. Any workflow that adjusts the total after checkout has to become a workflow that quotes correctly at checkout.
- Decide your decline rules. You accept or decline the order, so write the rule now: which addresses, which order values, which product categories get a human look.
- Read the terms you are agreeing to. Stripe gates shared payment tokens behind its agentic commerce seller services preview terms. Preview means the terms can change.
- Price the downside. Stripe's published US card cost is 2.9% plus 30 cents, with 15 dollars per dispute received. Agentic orders do not come with a discount on either.
Here is the arithmetic that decides whether this is worth your afternoon. A 90 dollar order through this rail costs the same to process as a 90 dollar order through your existing checkout, and carries the same 15 dollar dispute exposure, but arrives from a buyer who never saw your site, never joined your list and never met your return policy in their own words. That is not a reason to skip it. It is a reason to treat it as a marketplace channel rather than as your own storefront, which means watching its dispute rate separately from the rest of your book from the first order, using the same defence plan you run everywhere else. And if the compliance load of being merchant of record in every jurisdiction an agent can reach is what worries you, that is the older question of whether to be the merchant of record at all, asked by a new channel.
Discussion
Sign in with Google or just a name. No email link, no password to remember.