What Is the Agentic Checkout Spec in 2026?
The Agentic Checkout Spec is OpenAI's published contract for letting a shopper buy your product inside ChatGPT while the order, payment and compliance stay on your own commerce stack. You implement five REST endpoints that ChatGPT calls, you return an authoritative cart state on every call, you process payment with your existing payment service provider, and you send order events back to OpenAI by webhook. ChatGPT never becomes the shop. It becomes a front end calling yours.
Checkout sits on top of discovery. OpenAI states that onboarding product feeds in ChatGPT is currently available to approved partners, and its feed specification says checkout requires a separately enabled integration. This guide is the checkout spoke in our guide to the Agentic Commerce Protocol product feed.
In the published spec, the PaymentProvider object lists three possible providers, stripe, adyen and braintree, and one accepted payment method, card. The Delegated Payment Spec likewise states the only accepted credential type is card. There is no UPI, wallet or bank-transfer value in the current spec. For an Indian D2C brand whose customers pay mostly by UPI, that is the first fact to put in front of the business case.
How Does an Agentic Checkout Flow Work in 2026?
OpenAI describes the flow in six steps, and the direction of each call matters: ChatGPT calls you, and you call OpenAI only for webhooks. Every session response must return the full cart state, including items, pricing, taxes and fees, shipping, discounts, totals and status.
- Create session. ChatGPT calls your
POST /checkout_sessionswith cart contents and buyer context. - Update session. As the shopper changes items, shipping or discounts, ChatGPT calls
POST /checkout_sessions/{checkout_session_id}and you return the full cart again. - Order events. Your system publishes lifecycle events such as order created and order updated to the webhook OpenAI provides.
- Complete checkout. ChatGPT finalises with
POST /checkout_sessions/{checkout_session_id}/complete, and you confirm the order and return the final cart and order identifiers. - Cancel or retrieve. Optionally,
POST /checkout_sessions/{checkout_session_id}/cancelandGET /checkout_sessions/{checkout_session_id}. - Payments on your rails. You process payment with your existing PSP, accepting the delegated token if you use Delegated Payments.
OpenAI also notes that in the future the Agentic Checkout Spec will support MCP servers.
What Must Every Checkout Endpoint Handle in 2026?
Every endpoint must use HTTPS and return JSON, and every request from ChatGPT arrives with the same set of headers. Those headers are where most of the security and reliability work lives, because they carry authentication, the signature over the request body, the idempotency key, and the API version you must check.
| Header | What it carries | What you must do with it |
|---|---|---|
Authorization | API key used to make requests | Authenticate every request. |
Signature | Base64-encoded signature of the request body | Verify it before acting. |
Timestamp | RFC 3339 time | Use it as part of request validation. |
Idempotency-Key | Key ensuring requests are idempotent | Return the same result for safe duplicates; echo it in the response. |
Request-Id | Unique key for tracing | Log it and echo it in the response. |
API-Version | API version, for example 2025-09-12 | Confirm it is present and matches a supported version. |
Accept-Language | Preferred locale for messages and errors | Localise customer-facing messages. |
What Does the Cart State Have to Contain in 2026?
Your create, update, complete and cancel responses all return the same shape: an ID, a status, a currency, line items, fulfilment options, totals, messages and links, with buyer and address details where present. The status values are not_ready_for_payment, ready_for_payment, completed and canceled. Currency follows ISO 4217 in lower case.
The arithmetic is specified, not left to interpretation. A line item's subtotal must equal base_amount - discount, and its total must equal base_amount - discount + tax, with every amount an integer of zero or more. Totals use types such as items_base_amount, items_discount, subtotal, discount, fulfillment, tax, fee and total, expressed in minor units. If your platform rounds tax per order but the spec expects per-line values that sum, this is where a build discovers it.
POST Request to /checkout_sessions
{
"items": [
{
"id": "item_123",
"quantity": 1
}
]
}That is OpenAI's own first example: a session created with a single item and no fulfilment address, which therefore cannot yet be completed. One detail worth checking when you implement: the example response in the same document shows a status of in_progress, which is not among the four status values the response table lists. Confirm the expected value with OpenAI during onboarding rather than coding to either.
How Do Shipping, Messages and Errors Work in 2026?
Fulfilment options come in two types, shipping and digital. A shipping option needs a title, a subtitle describing the timeline, a carrier, earliest and latest delivery times in RFC 3339, and a subtotal, tax and total where total equals subtotal plus tax. OpenAI's production guide notes the protocol models a single shipping address and one selected shipping option per session, and advises consolidating split shipments into a single buyer-visible selection with aggregate totals.
Problems are surfaced to the shopper as messages, not just HTTP errors. An error message carries a code from missing, invalid, out_of_stock, payment_declined, requires_sign_in and requires_3ds, plus an RFC 9535 JSONPath such as $.line_items[1] pointing at the part of the session it concerns. When a request cannot succeed at all, you return an error object with a 4xx or 5xx status.
| Object | Key fields in 2026 | Constraint worth knowing |
|---|---|---|
Address | name, line_one, city, state, country, postal_code | line_one and city max 60 characters; state and country follow ISO 3166-1. |
Buyer | name, email, optional phone_number | Phone numbers follow E.164. |
Link | type and url | Types are terms_of_use, privacy_policy, seller_shop_policies. |
PaymentData | token, provider, optional billing_address | Provider is stripe, adyen or braintree. |
Order | id, checkout_session_id, permalink_url | Customers should reach the order by providing at most their email address. |
How Do Delegated Payments Work in 2026?
The Delegated Payment Spec lets OpenAI share payment details securely with you or your PSP. The shopper saves a payment method in ChatGPT, a single-use payload with an allowance is sent to your PSP or vault, the PSP returns a token scoped to that payment, and OpenAI forwards the token on the complete call. OpenAI is not the merchant of record, and settlement, refunds, chargebacks and compliance stay with you and your PSP.
Who should integrate directly is stated precisely: direct integration is only for PSPs or PCI DSS level 1 merchants using their own vaults. For everyone else, OpenAI points to Stripe's Shared Payment Token as the first compatible implementation. The allowance is tight by design, with a reason that must be one_time, a max_amount, a currency, the checkout session and merchant IDs, and an expires_at timestamp.
On PCI scope, OpenAI's production guide says the feed and checkout specs are deliberately kept out of PCI scope and do not transmit cardholder data. Using your PSP's implementation of delegated payments may avoid any change in scope, while forwarding APIs or direct integration involve cardholder data and will likely be in scope. OpenAI says it may require your attestation of compliance before enabling production access, and recommends consulting your PSP and Qualified Security Assessor.
What Do the Webhooks Have to Send in 2026?
You send OpenAI webhook events on order creation and update so the buyer's view stays in sync, signed with an HMAC signature in a request header. Event types are order_created and order_updated. Order status values are created, manual_review, confirmed, canceled, shipped and fulfilled, and each event carries a list of refunds typed as store_credit or original_payment.
OpenAI's production FAQs add the operational consequence: because you are the merchant of record, you handle refunds and chargebacks, and you should use the order update webhook to notify ChatGPT when a refund or chargeback status changes. Customers see your name on their card statement, as if they bought directly from your site.
Who Should Build Agentic Checkout in 2026?
Teams whose payments already run on Stripe, Adyen or Braintree, whose customers mostly pay by card, and whose products and market are within what OpenAI has confirmed for their integration. For many Indian D2C brands, at least one of those conditions fails today. That does not make the specification irrelevant: the feed work is reusable, and knowing exactly what checkout requires lets you decide when it becomes worth building rather than guessing.
| Readiness question for 2026 | If yes | If no |
|---|---|---|
| Accepted as an approved partner? | Proceed to integration planning. | Apply at chatgpt.com/merchants; prepare the feed meanwhile. |
| PSP is Stripe, Adyen or Braintree? | Use the PSP's delegated payment path. | Checkout is not buildable on the current spec. |
| Customers pay mostly by card? | Checkout matches demand. | Weigh demand before building; the spec accepts card only. |
| Can you compute per-line tax and totals that sum exactly? | Cart state is straightforward. | Fix pricing logic first. |
| Can you sign, verify, and handle idempotency? | Security work is incremental. | Plan engineering time for it. |
Our production checklist guide covers the certification tests OpenAI requires before launch.
What Are the Common Mistakes With Agentic Checkout in 2026?
- Scoping a build before checking the payment provider. The spec lists Stripe, Adyen and Braintree, and card only.
- Treating ChatGPT as the merchant of record. It is not. Refunds, chargebacks and compliance stay with you.
- Returning partial cart state. Every response must return the full cart, not a diff.
- Letting totals drift by rounding. Subtotal and total rules are arithmetic, not guidance.
- Skipping signature verification and idempotency. Both are required and both are tested before launch.
- Assuming direct delegated payments are simpler. Direct integration is for PSPs and PCI DSS level 1 merchants only.
- Coding to an example instead of the schema. Where they disagree, confirm with OpenAI.
Key Takeaways for 2026
- Five merchant-hosted endpoints: create, update, complete, cancel and retrieve a checkout session, all HTTPS and JSON.
- Every response returns the full, authoritative cart state with strict subtotal and total arithmetic.
- Payment providers in the spec are
stripe,adyenandbraintree, and the accepted method iscard. - Delegated payment tokens are single-use, capped by
max_amountandexpires_at. - You stay merchant of record, owning refunds, chargebacks and compliance, and syncing them by webhook.
- Direct delegated integration is for PSPs and PCI DSS level 1 merchants; others use their PSP's implementation.
Distk helps D2C and e-commerce teams in India and internationally work out whether agentic checkout is buildable on their current payment stack, scope the integration honestly, and prepare the product feed that has to exist first. If agentic checkout is on your 2026 roadmap, that assessment is where we start.