01
What ACP is and who publishes it
Applies to marketplace onlyown storefronthybrid
ACP is maintained by OpenAI and Stripe and is currently published in beta, as dated snapshots with machine-readable interface definitions attached.1 Two of those documents cover the parts of a purchase this lesson describes: an agentic checkout specification defining the operations a merchant hosts,3 and a delegated payment specification defining how a payment credential reaches the merchant.4
The specification describes an interface rather than a service. The merchant side, or a platform acting on its behalf, exposes a set of operations, and the agent calls them. Item prices, discounts, tax, delivery charges, and totals are all computed by the merchant side and returned in the response.
The documents describe what an implementation looks like. Whether a particular surface sends requests to a particular merchant, and whether a hosting platform exposes the interface to the sellers it serves, are separate matters the specification does not settle.3 Those are covered later in this lesson.
02
The checkout operations a merchant hosts
Applies to marketplace onlyown storefronthybrid
The checkout specification defines five operations on a checkout session. Each one is a request the agent sends and the merchant answers.3
| Operation | What the specification defines it to do | Information in the response |
|---|---|---|
| Create session | Opens a checkout session for a specified cart | Line items with amounts, applicable discounts and tax, delivery options and their costs, an overall total, and a channel for buyer-facing messages |
| Update session | Applies new buyer information, such as a delivery address | The same fields, recomputed for the information now supplied |
| Get session | Returns the session as the merchant currently records it | The current status and the most recently computed amounts |
| Complete session | Submits payment and requests creation of the order | The resulting status, with a buyer-facing message where the request is not fulfilled |
| Cancel session | Ends the session without creating an order | The resulting status |
Each request carries an idempotency key. It exists so that a repeated call is treated as the same instruction rather than a new one, which is what stops a retried request from producing a second order when a network connection fails partway through.3
Two operations sellers often expect are absent. There is no operation to reserve or hold stock, and there is no operation for browsing a catalog. A session refers to items a buyer has already chosen, and product discovery happens through mechanisms outside this specification.
03
Session status values and what they record
Applies to marketplace onlyown storefronthybrid
A checkout session is not a single request. It carries a status that the merchant sets and the agent reads, and the specification defines four values for it.3
| Status | What it records | What typically moves a session into it |
|---|---|---|
| Not ready for payment | Required information is still missing, or an amount cannot yet be computed | A session created before a delivery address has been supplied |
| Ready for payment | The merchant has returned a complete set of amounts for the information supplied | An update that provides the remaining details |
| Completed | A completion request was accepted and an order was created | A successful completion |
| Canceled | The session ended without an order | A cancellation request |
Ready for payment records the amounts the merchant last computed. It is a statement about the quote, not a hold on inventory. Take the Meridian camera as the example: one 1978 body, listed in more than one place. Between the moment its session reaches ready for payment and the moment a completion request arrives, nothing in the specification stands between that body and a different buyer somewhere else. Managing that interval is the seller’s own removal process, not a protocol function.
The specification does provide for declining a completion. A completion request for an item that is no longer available can be answered with a failure and an explanation through the buyer-facing messages channel the response defines. Whether a given platform implements that behavior is a question for the platform rather than for the document.
04
Delegated payment and the limits on the credential
Applies to marketplace onlyown storefronthybrid
The second specification covers payment. Card details go to a payment provider or a compliant vault, which returns a scoped credential. The merchant receives that credential and the name of the provider that issued it, and does not receive raw card details.4
The credential carries explicit limits, described in the specification as an allowance.
| Limit recorded on the credential | What it constrains |
|---|---|
| Single use | The credential is valid for one charge |
| Maximum amount and currency | A charge cannot exceed the stated amount in the stated currency |
| Bound checkout session | The credential applies only to the session it was issued against |
| Expiry timestamp | The credential stops being valid after the stated time |
| Named merchant | Only the named merchant can present it |
At completion the merchant charges the credential through its own processor. What the specification sets out is a delegation model between an agent surface and a payment provider; whether a particular processor accepts a delegated credential is a commercial question about that provider, and the document does not answer it.4 That question is settled by the provider rather than by the specification, and the answer differs from one seller to the next.
05
Where settlement and disputes are placed
Applies to marketplace onlyown storefronthybrid
The delegated payment specification states that the agent surface is not the merchant of record. The seller keeps that role, and settlement, refunds, dispute handling, and the related compliance obligations stay where they already sat.4
In practice this means a charge created through an ACP checkout runs through the seller’s own processor account. A dispute raised afterwards arrives at that account, counts toward its dispute metrics, and is answered with the records the seller’s systems produced during the session. The agent surface presented the checkout and carried the buyer’s authorization; the specification does not move the financial exposure of the sale away from the seller.
| Responsibility | Where the specification places it |
|---|---|
| Computing prices, tax, and delivery costs | Merchant |
| Creating the order | Merchant |
| Holding raw card details | Payment provider or compliant vault |
| Charging the scoped credential | Merchant, through its own processor |
| Merchant of record | Merchant |
| Refunds and dispute handling | Merchant |
| Presenting the checkout to the buyer | Agent surface |
06
Specification, access, testing, and documented production use
Applies to marketplace onlyown storefronthybrid
A published specification and an available integration are different things, and keeping them apart changes how an announcement reads. This course records five categories of information separately.
| Category | What it establishes | What it does not establish |
|---|---|---|
| Announcement | That an organization stated something publicly on a date | Any technical detail beyond what the statement contains |
| Technical documentation | That an interface is defined and can be read and built against | That a seller can obtain access to it |
| Merchant or developer access | That a named party can enroll or be approved | That a working test environment is available to them |
| Testing availability | That requests can be exchanged in a test setting | That transactions take place in production |
| Publicly documented production use | That a source describes completed transactions | Volume, durability, or availability to other sellers |
These categories are not mutually exclusive. A single event usually fills more than one: publishing a dated ACP snapshot is both an announcement and technical documentation, and a platform launch can be an announcement that also opens merchant access. Separating them describes what an event establishes; it does not sort events into one box each.
Applied to ACP as the current source set reads: the checkout and delegated payment specifications are technical documentation, published in beta as dated snapshots.1 Merchant access runs through whichever platform, marketplace, or processor a seller already uses, so it varies by seller. The current sources do not include a documented production transaction attributed to a named small seller. That is a statement about the source set rather than about what has or has not happened commercially.
07
Protocol version compatibility and capability negotiation
Applies to marketplace onlyown storefronthybrid
A related specification, UCP, is published with its own dated version and keeps two things apart that are easy to conflate: compatibility between protocol versions, and negotiation of capabilities.2 The first establishes that two systems agree on which version they are speaking. The second establishes which optional features each side actually supports.
The distinction is useful when reading a conformance claim. A statement that a platform supports an agentic checkout standard describes the version implemented. It does not by itself describe which optional behaviors are present — for instance, how a completion request is handled for an item that has become unavailable. A behavior of that kind is confirmed by asking about the behavior, not by matching a protocol name.
Because ACP remains in beta and publishes its snapshots with dates,1 a conformance claim is easier to interpret when the snapshot date is recorded next to it.
08
Recording what applies to your own setup
Applies to marketplace onlyown storefronthybrid
Most sellers do not implement any of this directly. The checkout interface is hosted by a storefront platform or a marketplace, and the payment side depends on a processor. What remains useful is a short record of which layer is governed by which document, what the access condition is, and what each layer depends on. The table below shows that shape, filled in for a seller who reaches these layers through a platform.
| Layer | Governing source and version read | Access condition | Depends on |
|---|---|---|---|
| Checkout session hosting | ACP agentic checkout specification, with the snapshot date recorded on the day it was read | Hosted by the storefront platform; not implemented by the seller | The platform exposing the interface, and how it answers a completion for an unavailable item |
| Delegated payment | ACP delegated payment specification, with the same snapshot date recorded | Not established — depends on processor support | Whether the seller’s processor accepts delegated credentials |
| Marketplace automated access | The marketplace’s own policy pages, not a protocol document | Set by the marketplace for every seller trading on it | Policy text that can be amended without a version number attached |
| Publicly documented production use | Not in current sources | Not applicable | A published account describing completed transactions |
An entry reading “not established” records that the sources consulted do not answer the question. It is more useful than a guess, because it names the party who can answer. Recording the date each source was read serves a similar purpose: a beta specification and a live policy page can both change without notice, and a date makes it possible to check what moved instead of rereading everything.
The last column stays literal. A capability that holds only while a platform choice, a region, or a partner approval holds is conditional, and it ends when its condition does. Recording the condition alongside the capability is what makes the row re-checkable later.
09
Current summary
Applies to marketplace onlyown storefronthybrid
The ACP documents define an interface. The checkout specification sets out five operations a merchant hosts, the information each response carries, an idempotency key that makes a retried request safe, and four status values a session can hold. The delegated payment specification sets out a scoped credential with five recorded limits and keeps the merchant of record, settlement, refunds, and disputes with the seller.
The documents do not establish which surfaces send requests to a given merchant, which platforms expose the interface to their sellers, or whether a particular processor accepts a delegated credential. Platforms, marketplaces, and payment providers answer those questions, and the answers differ from one seller to the next.
The specification is in beta and its snapshots are dated, so anything taken from it is best stored with the date of the snapshot it came from. Where an entry in your own record is empty, it means the sources consulted do not provide that information.
10
Practice
Exercise
Record what applies to one of your items
- Write the five checkout operations as questions your own systems would have to answer for one item you hold a single unit of.
- Note how long that item typically sits quoted but unsold, and where else it is listed during that time.
- Ask your storefront platform how a completion request is answered for an item that has already sold elsewhere.
- Ask your payment provider whether it accepts delegated credentials, and record the answer with the date it was given.
Check yourself
Where do the amounts in an ACP checkout response come from?
The merchant side computes them. Each create or update call returns line items, discounts and tax, delivery options and costs, and a total for the information supplied so far, so a change of address produces recomputed amounts rather than a reused quote.
Does a session in the ready-for-payment status hold the item?
No. That status records the amounts the merchant last computed. The published operations include no way to reserve stock, so availability between the quote and the completion is managed by the seller rather than by the protocol.
Why does a retried checkout request not create a second order?
Each request carries an idempotency key, which lets the merchant recognize a repeated call as the same instruction and answer it with the original result.
What does a matching protocol version establish, and what does it leave open?
It establishes that two systems agree on the version they are speaking. Which optional capabilities each side supports is negotiated separately, so a version match does not confirm that a specific behavior is present.
Where does a dispute over an ACP order arrive?
At the seller. Delegated payment keeps the seller as merchant of record, so settlement, refunds, and disputes stay with the seller’s own processor account.
Progress is saved in this browser only. No account, nothing sent anywhere.
11
Common questions
Does supporting ACP mean an assistant can take items from my store automatically?
No. The merchant hosts the interface and answers each request. A session can be created and completed only where a merchant, platform, or marketplace has chosen to expose the interface, and every amount in it is computed by the merchant side.
Does the buyer’s card number reach me?
No. Card details go to a payment provider or a compliant vault, which returns a scoped credential. Your side receives that credential and the name of the issuing provider, then charges it through your own processor.
Should a small seller implement these specifications directly?
Most sellers reach these layers through a storefront platform, marketplace, or processor that implements them. For that seller the useful record is which party covers which layer and what the access condition is, rather than an implementation plan.
Does one protocol name describe an entire purchase?
No. Product discovery, checkout, payment, order status, and disputes can be governed by different documents and agreements, so a name covering one of them does not describe the others.
How often should these records be rechecked?
Set the interval from the fastest-changing entry. A beta specification publishing dated snapshots and a live policy page can both change between quarters, while a settled vocabulary changes far more slowly.
12
Research and sources
Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.
Claim evidence
- ACP is currently beta and publishes dated specification snapshots.
- technical requirement. Supported by Agentic Commerce Protocol repository and specification .
- UCP separates protocol-version compatibility from capability negotiation.
- technical requirement. Supported by Universal Commerce Protocol official specification .
- ACP checkout defines a merchant-hosted session that can be created, updated, retrieved, completed, and canceled, with responses carrying the computed line items, fulfillment options, totals, and buyer-facing messages.
- technical requirement. Supported by Agentic Checkout specification .
- A checkout session carries an explicit status: not ready for payment, ready for payment, completed, or canceled.
- technical requirement. Supported by Agentic Checkout specification .
- Checkout requests carry an idempotency key so a retried call is recognized as a repeat of an earlier instruction and does not create a duplicate order.
- technical requirement. Supported by Agentic Checkout specification .
- Delegated payment issues a scoped credential constrained by a single-use reason, a maximum amount and currency, a bound checkout session, an expiry, and a named merchant, so the merchant never receives raw card details.
- technical requirement. Supported by Delegated Payment specification .
- Delegated payment leaves the seller as merchant of record, so settlement, disputes, refund handling, and compliance obligations stay where they already were.
- technical requirement. Supported by Delegated Payment specification .
- Agentic Commerce Protocol repository and specification Agentic Commerce Protocol · Tier A · beta · 2026-04-17 stable snapshot; unreleased development tracked separately
ACP checkout, cart, feed, order, authentication, and extension models. Limit: A beta specification maintained by OpenAI and Stripe does not prove platform adoption, merchant access, conformance, or interoperability.
- Universal Commerce Protocol official specification Google · Tier A · published specification · 2026-04-08
UCP discovery, capability negotiation, shopping, fulfillment, and payment-handler models. Limit: The specification states interfaces and normative language; it does not prove that a particular merchant or surface implements them.
- Agentic Checkout specification OpenAI · Tier A · beta · published alongside the ACP checkout OpenAPI document
Merchant-hosted checkout session lifecycle, request and response payloads, session status values, headers, and error semantics. Limit: Documents the interface a merchant would implement; it does not establish that any surface will send requests to a given merchant, or that a platform exposes the interface to its sellers.
- Delegated Payment specification OpenAI · Tier A · beta · published alongside the ACP delegate-payment OpenAPI document
Scoped payment credential delegation, allowance constraints, provider support, and the merchant-of-record boundary. Limit: Describes a delegation model between an agent surface and a payment provider; provider support is a separate commercial question and is not established by the specification.