Agentic Commerce Protocol Checkout
How ACP connects product feeds, merchant checkout state, delegated payment tokens, idempotency, and order fulfillment without displacing the seller.
The seller supplies the authoritative values in an ACP purchase: current price, tax, available inventory, payment outcome, and final order. An agent can present products and collect the buyer's choices, but it doesn't become the merchant or replace the merchant's systems.
Agentic Commerce Protocol carries that state between an agent-run buying interface and the seller. It supplies a structured transaction path for systems that already calculate checkout, accept or decline payment, fulfill orders, process returns, and support customers.
The official ACP repository is maintained by OpenAI and Stripe and labels the specification beta. It identifies 2026-04-17 as the latest stable date-based snapshot while keeping current development under unreleased. Participant availability is narrower than the repository label: Stripe's current agentic-commerce overview lists seller integrations as supported while agent-side integration remains a private preview. Pin the ACP snapshot, then check the status of the exact participant surface.
Product feeds identify what an agent can offer
A product feed gives the agent merchant-provided catalog records before checkout. Current ACP materials cover product and variant identifiers, titles, descriptions, prices, availability, media, seller details, categories, canonical URLs, and policy links. The checkout-compatible item identifier is especially important. Scraping a product page rarely tells an agent which SKU or variant ID the merchant API will accept.
Feeds are allowed to age. Suppose an indexed feed says a blue instrument case costs $80 and remains in stock. Ten minutes later, the last unit sells. The agent can still use that feed to find the item, but the seller's checkout response must return current availability and price. The buyer acts on that authoritative response.
This division also protects merchant control over representation. The feed states which image, title, condition, and seller should be shown. An agent should retain the canonical product URL and recheck feed freshness before starting a purchase, while avoiding claims that checkout hasn't confirmed.
A feed alone doesn't implement ACP checkout. It can't accept a shipping address, calculate tax, select fulfillment, or create an order. Readiness requires the transaction path too.
Checkout sessions remain merchant-owned state
The Agentic Checkout API centers on a seller-hosted session. A client creates it with item identifiers and quantities. The seller returns a complete current view that can include line items, integer totals in minor units, fulfillment options, messages, payment handlers, policy links, and a status.
The client updates the same session as the buyer changes quantity, address, or fulfillment. Each response replaces the agent's prior view of checkout state. An agent shouldn't recalculate the total from an earlier response or assume that a shipping option remained valid after the destination changed.
Completion submits payment data to the seller and, on success, produces an order reference. Cancellation tells the seller that the buyer exited so reserved inventory and related state can be released where policy allows. Retrieval supports recovery when the agent loses a response.
The merchant remains the system of record throughout. OpenAI's ACP launch explanation says orders, payments, and fulfillment are handled by the merchant using its existing systems. The merchant also keeps the customer relationship as Merchant of Record, including returns and support.
That means the seller API must authorize every session access. A random session ID cannot be enough. Bind sessions to the authenticated agent integration and merchant account, use unguessable identifiers, limit personal data in responses, and expire abandoned sessions.
Delegated payment tokens narrow credential exposure
ACP can use delegated payment credentials so an agent doesn't send a reusable card number through each merchant integration. The agent or payment partner obtains a token with an allowance, then supplies that token during checkout completion. Stripe's current seller-specific Shared Payment Token documentation describes receiving a token scoped to a Stripe profile and using it with a PaymentIntent. As checked September 9, 2026, it lists availability in the United States, Canada, and select European countries, while some granted-token examples still select 2026-04-22.preview. Eligibility needs to be checked for the exact seller, customer, and agent countries.
The chosen payment handler defines its actual allowance fields and enforcement. Merchant or business-profile scope, usage limits, and expiry narrow credential use; the seller must still bind the payment attempt to its own checkout record. Don't assume every provider token carries the same session or purpose fields. The seller redeems the delegated credential through its payment processor. A token within its allowance can still be declined by the processor, rejected by merchant policy, or require an authentication step.
Scope validation belongs at redemption. Confirm the expected merchant, session, currency, amount ceiling, expiry, token status, and payment handler before capture. Don't log the credential. Make it single-purpose where possible, and prevent a support operator from copying it into another transaction.
Delegation reduces the number of parties that handle durable payment credentials. It doesn't remove PCI, privacy, fraud, refund, or dispute responsibilities from the merchant and its providers. The merchant still decides whether the order can proceed.
Idempotency protects capture and inventory from retries
A network timeout after payment capture is ordinary distributed-systems failure. If the client repeats POST /checkout_sessions/{id}/complete, the seller must return the first outcome rather than charge the buyer again.
The current ACP checkout design document specifies Idempotency-Key on POST operations and scopes keys to the authenticated identity plus endpoint path. Its changelog marks the expanded Section 6 rules as unreleased, so review the pinned stable schema separately when assessing released conformance. The following behavior is the current design guidance and a useful recovery target. The same key with the same semantic request body returns the stored response. Reusing it with a different body produces a conflict. An in-flight duplicate gets a retryable response, while a server error isn't cached as a successful operation.
Implement the key store next to the business mutation. The idempotency record and local state change should commit atomically. External effects, such as processor authorization, need recovery checkpoints so a retry can resume from a known stage instead of starting over.
Preserve the difference between an absent field and null in update requests. ACP's current idempotency text treats those bodies differently because omission means leave the value unchanged while null can mean clear it. SDK serialization must not erase that intent.
I would test a completion timeout by looking up the existing processor result before repeating any financial action. The API's stored response and the processor's state need to agree. An idempotency table that says only “request started” cannot resolve a capture that succeeded just before the application crashed.
The same discipline applies before completion. Repeating a create request shouldn't reserve inventory twice. Repeating an update shouldn't append a quantity change as if it were new. Record request fingerprints and original responses for the supported retention window.
Discovery remains separate from the stable snapshot
Some readiness checks expect /.well-known/acp.json with a protocol name and version, API base URL, transports, and services. The latest stable ACP snapshot, 2026-04-17, does not define that document as a conformance requirement.
There is a current official-repository proposal named Agentic Checkout Discovery. It describes that exact well-known path and a closely related shape. Its header says Status: Proposal and Version: unreleased.
The distinction matters when deciding whether a merchant conforms to a particular release. A scanner shouldn't treat that path's absence as failure against the stable snapshot. An implementer experimenting with the proposal must label it provisional, pin the proposal revision, and keep session-level capability negotiation authoritative.
Do not publish the file ahead of a service. It would expose an API base URL and capabilities that agents could attempt to use, creating a public contract without checkout behind it.
Establish the merchant workflow
ACP fits a purchase with an authoritative price, payment decision and order lifecycle. A service inquiry that still needs scoping has not reached that point. Keep it as an inquiry until the business can define and fulfill the transaction.
Before integrating, follow one item from its feed record through checkout, payment and order creation. Check that price, tax, fees, inventory and expiry come from the seller's current state. Connect the order to fulfillment, support, cancellations, refunds and disputes; checkout success is only one stage of that responsibility.
Test the purchase that does not complete cleanly
Exercise a stale feed item, a changed total, a declined payment and a lost response after completion. A retry should not duplicate capture or inventory changes. Support staff need a durable order or failure record that can be reconciled with the payment provider.
Review session access, delegated-token limits, personal data and fraud controls against that workflow. Pin the released ACP snapshot and check participant availability. Revisit discovery separately when its proposal status changes; the merchant's transaction and recovery behavior remain the first integration requirements.