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 owns the decisive numbers 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. It says Shared Payment Tokens are available in the United States and Canada, while examples for some granted-token operations still select the 2026-04-22.preview API version.
The allowance constrains use to details such as the merchant, maximum amount, currency, checkout session, purpose, and expiry. 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.
Current ACP RFC material requires Idempotency-Key on POST operations and scopes keys to the authenticated identity plus endpoint path. 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.
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.
/.well-known/acp.json is proposed, not released ACP conformance
The supplied readiness check expects /.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.
That distinction changes the readiness verdict. The path isn't an unrelated invention anymore, but a scanner still shouldn't treat its absence as failure against released ACP. 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.
TARE isn't sold here as a checkout item
TKOResearch is product-first around TARE, its LabSecOps platform. This website publishes TARE information, engineering articles, and private client service descriptions. It has no product feed, cart, checkout-session API, delegated payment endpoint, or order webhook surface.
The contact form begins scoping. It doesn't quote an authoritative total, reserve an item, accept payment, or create an order. Wrapping that form in ACP would misdescribe the engagement process and introduce delegated credentials where the customer gains no transaction benefit. ACP discovery should keep returning 404.
Build the merchant system before discovery
A future transactional TARE offering would first need stable feed records and item identifiers tied to authoritative availability. Seller responses would own price, tax, discounts, fees, shipping, currency, and expiry. The checkout API would implement authenticated create, update, retrieve, complete, and cancel operations with stable errors and durable idempotency.
Payment design would choose handlers and a delegated-token provider, then enforce allowance, processor, capture, reconciliation, and any required authentication step. The same merchant system would connect checkout sessions to orders, delivery updates, customer support, cancellations, returns, refunds, partial-order treatment, and disputes.
Production review would then follow the transaction from feed freshness through session mutation, idempotent replay, payment attempt, order creation, webhook delivery, and fulfillment. Security controls would cover bearer-token scope, request integrity, delegated credentials, personal data, fraud, session access, idempotency storage, rate limits, and dependency changes.
Only after that path works should the team revisit the released ACP snapshot and ask whether the discovery proposal has reached stable status. The release trigger is a merchant-owned checkout that survives retries and declined payments, then gives support staff a reliable order record.