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 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, which still shows API-Version: 2025-09-29, and the Delegate Payment OpenAPI schema 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 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 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, 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_carddifferently fromservice_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 validates the 402 challenge a paid endpoint returns. If you are comparing agent payment approaches, the x402 payment checklist 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.