Inside OpenAI’s Delegated Payment Spec

OpenAI's Delegated Payment Spec, part of the Agentic Commerce Protocol and maintained with Stripe, defines a Delegate Payment API in which a payment credential is delegated with an allowance carrying max_amount in minor units, currency, merchant_id, checkout_session_id and expires_at, and returns a single-use vault token. The developers.openai.com page still shows API-Version: 2025-09-29 while the Delegate Payment OpenAPI schema in the ACP GitHub repository is release 2026-04-17 (beta), and the spec says direct integration is "only for PSPs or PCI DSS level 1 merchants using their own vaults," with Stripe holding the first compatible implementation. The write-up flags that the spec does not state which party enforces the allowance limits or define an explicit revocation mechanism after first use.

Inside OpenAI’s Delegated Payment Spec The Agentic Commerce Protocol's Delegate Payment API: allowance fields max amount in minor units, currency, merchant id, checkout session id, expires at , single-use semantics, vault tokens, idempotency, PSP duties. OpenAI's Delegated Payment Spec https://developers.openai.com/commerce/specs/payment is the part of the Agentic Commerce Protocol that deals with payment credentials. Its premise: instead of handing a card to every party in the chain, a credential is delegated with limits attached. This post walks through what the spec documents and flags what it leaves open. Two sources are involved: the developers.openai.com page https://developers.openai.com/commerce/specs/payment , which still shows API-Version: 2025-09-29 , and the Delegate Payment OpenAPI schema https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate payment.yaml in the ACP GitHub repository release 2026-04-17, beta, maintained by OpenAI and Stripe . Where they differ, we say so. Who the spec is for The spec says direct integration with OpenAI through it is "only for PSPs or PCI DSS level 1 merchants using their own vaults." Others are pointed to a PSP's shared-token product. The key concepts guide https://developers.openai.com/commerce/guides/key-concepts says Stripe has the first Delegated Payment Spec-compatible implementation. Reading the public spec does not mean you can call it: access is a separate matter, and this post covers only what is public. A fictional purchase A buyer asks an AI agent to order a $42.00 desk lamp from a made-up merchant, merchant lamps demo . Checkout session cs demo 123 is ready for payment . CNBC reported https://www.cnbc.com/2026/03/24/openai-revamps-shopping-experience-in-chatgpt-after-instant-checkout.html that OpenAI ended ChatGPT's Instant Checkout in March 2026, so read this as an illustration of the protocol, not of a live ChatGPT feature. The agent platform sends the PSP a request to POST /agentic commerce/delegate payment . The payment method details are omitted here deliberately; a real request carries card data a network token or a card number , and none belongs in logs, examples or tickets. The allowance : { "allowance": { "reason": "one time", "max amount": 4200, "currency": "usd", "checkout session id": "cs demo 123", "merchant id": "merchant lamps demo", "expires at": "2026-10-08T12:30:00Z" } } The PSP responds with 201 and a vault token: {"id": "vt demo abc", "created": "...", "metadata": {...}} . The allowance fields | Field | What the spec says | Notes | |---|---|---| | reason | Only current value: one time | Not to be used for other flows | | max amount | Integer. The GitHub schema: "Maximum charge amount in minor units e.g. 100 cents for $1.00 or 100 for ¥100 " | The developers.openai.com page does not state units; the schema does, so 4200 above is $42.00 | | currency | ISO 4217, lower case | | | checkout session id | Reference to the checkout session | | | merchant id | Merchant identifying descriptor, max 256 chars | | | expires at | Timestamp. The web page says RFC 3339; the GitHub schema says ISO 8601 | Send an RFC 3339 UTC timestamp, which satisfies both | Other required request pieces include risk signals type, score, and an action of blocked , manual review or authorized and metadata . Single use: who enforces it? The spec states "the delegated payment is single-use and set with allowances," and that the resulting token is restricted by the maximum amount and expiry. The GitHub schema describes merchant id as the merchant "authorized to use this token." What we did not find is a sentence saying which party enforces the limits, or an explicit revocation mechanism after first use. Sensible reading: the PSP that issued the vault token is positioned to enforce it, since it holds the vault. That is our interpretation. If you are the PSP, write the enforcement down as your own requirement and test it: charge below max, charge above max, charge after expiry, charge a second time. Token handoff Per the key concepts guide, the token goes from the PSP to the merchant. In the checkout spec https://developers.openai.com/commerce/specs/checkout , the merchant receives it in PaymentData token , provider , optional billing address on POST /checkout sessions/{id}/complete , and "accept s the token and apply ies your normal authorization/capture flow." OpenAI is not the merchant of record: the merchant and PSP own transaction processing, settlement, refunds, chargebacks and compliance. Idempotency and errors Requests carry an Idempotency-Key , plus Request-Id , Timestamp , Signature and API-Version headers. Reusing a key with different parameters returns 409 . The GitHub schema recommends a UUID v4 key max 255 characters, scoped to the authenticated identity and adds codes for a missing key and for a request still in flight. The error body has type , code , message and an optional param pointing at the offending field. Documented codes include invalid request , invalid card , idempotency conflict , rate limit exceeded , processing error and service unavailable ; the schema also lists idempotency key required and idempotency in flight . Practical implications: - Retry a timed-out request with the same key and body; never with a changed body. - Store the vault token ID against the checkout session, so a replay cannot create a second credential for one purchase. - Treat invalid card differently from service unavailable : one is a decision, the other is retryable. Responsibility summary | Party | Documented responsibility | |---|---| | Agent platform OpenAI in the original design | Sends delegated-payment request; forwards token at completion; not merchant of record | | PSP | Issues vault token for the allowance | | Merchant | Completes session, authorizes and captures, fulfills, refunds | | Your application if you sit above this | Decides whether the purchase should be attempted at all | Where ContextIQ fits ContextIQ does not implement or inspect the Delegated Payment Spec, and it does not look at payment requests. Its payment tooling is for x402 endpoints: the x402 Inspector https://contextiq.trango-compute.com/x402-inspector validates the 402 challenge a paid endpoint returns. If you are comparing agent payment approaches, the x402 payment checklist https://contextiq.trango-compute.com/blog/x402-payment-checklist-what-ai-agents-verify-before-signing covers a different protocol with a different model. Sources Follow Trango Compute on LinkedIn We post updates on new tools, context engineering patterns, and LLM cost research. Follow on LinkedIn https://www.linkedin.com/company/trango-compute