{"slug": "inside-openais-delegated-payment-spec", "title": "Inside OpenAI’s Delegated Payment Spec", "summary": "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.", "body_md": "# Inside OpenAI’s Delegated Payment Spec\n\nThe 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.\n\nOpenAI'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.\n\n## Who the spec is for\n\nThe 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.\n\n## A fictional purchase\n\nA 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.)\n\nThe 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`:\n\n```\n{\n  \"allowance\": {\n    \"reason\": \"one_time\",\n    \"max_amount\": 4200,\n    \"currency\": \"usd\",\n    \"checkout_session_id\": \"cs_demo_123\",\n    \"merchant_id\": \"merchant_lamps_demo\",\n    \"expires_at\": \"2026-10-08T12:30:00Z\"\n  }\n}\n```\n\nThe PSP responds with `201` and a vault token: `{\"id\": \"vt_demo_abc\", \"created\": \"...\", \"metadata\": {...}}`.\n\n## The allowance fields\n\n| Field | What the spec says | Notes | \n|---|---|---|\n| `reason` | Only current value: `one_time` | Not to be used for other flows | \n| `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 | \n| `currency` | ISO 4217, lower case |  | \n| `checkout_session_id` | Reference to the checkout session |  | \n| `merchant_id` | Merchant identifying descriptor, max 256 chars |  | \n| `expires_at` | Timestamp. The web page says RFC 3339; the GitHub schema says ISO 8601 | Send an RFC 3339 UTC timestamp, which satisfies both | \n\nOther required request pieces include `risk_signals` (type, score, and an action of `blocked`, `manual_review` or `authorized`) and `metadata`.\n\n## Single use: who enforces it?\n\nThe 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.\n\n## Token handoff\n\nPer 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.\n\n## Idempotency and errors\n\nRequests 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`.\n\nPractical implications:\n\n- Retry a timed-out request with the *same* key and body; never with a changed body.\n- Store the vault token ID against the checkout session, so a replay cannot create a second credential for one purchase.\n- Treat `invalid_card` differently from`service_unavailable` : one is a decision, the other is retryable.\n\n## Responsibility summary\n\n| Party | Documented responsibility | \n|---|---|\n| Agent platform (OpenAI in the original design) | Sends delegated-payment request; forwards token at completion; not merchant of record | \n| PSP | Issues vault token for the allowance | \n| Merchant | Completes session, authorizes and captures, fulfills, refunds | \n| Your application (if you sit above this) | Decides whether the purchase should be attempted at all | \n\n## Where ContextIQ fits\n\nContextIQ 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.\n\n## Sources\n\nFollow Trango Compute on LinkedIn\n\nWe post updates on new tools, context engineering patterns, and LLM cost research.\n\n[Follow on LinkedIn](https://www.linkedin.com/company/trango-compute)", "url": "https://wpnews.pro/news/inside-openais-delegated-payment-spec", "canonical_source": "https://contextiq.trango-compute.com/blog/inside-openai-delegated-payment-spec", "published_at": "2026-10-08 00:00:00+00:00", "updated_at": "2026-10-09 00:17:18.155432+00:00", "lang": "en", "topics": ["agent-protocols", "ai-agents", "ai-products"], "entities": ["OpenAI", "Stripe", "Agentic Commerce Protocol", "Delegated Payment Spec", "Delegate Payment API", "ChatGPT", "CNBC"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/inside-openais-delegated-payment-spec", "markdown": "https://wpnews.pro/news/inside-openais-delegated-payment-spec.md", "text": "https://wpnews.pro/news/inside-openais-delegated-payment-spec.txt", "jsonld": "https://wpnews.pro/news/inside-openais-delegated-payment-spec.jsonld"}}