ACP Delegated Payment Flow Explained
> ACP delegated payment is the model by which an AI agent collects a buyer's payment token — via a supported PSP — and relays it to the merchant's ACP checkout endpoint to complete a purchase, without the buyer's raw card credentials ever being stored by or exposed to the agent.
---
What Is Delegated Payment in ACP?
Delegated payment is the mechanism that makes programmatic purchasing possible within AI surfaces like ChatGPT. In a traditional e-commerce flow, the buyer enters their card details on a merchant's checkout page; the merchant's PSP tokenises those details and processes the payment. In the agentic model, the buyer is not on the merchant's page at all — they are inside a chat interface. The question of how payment credentials move securely from the buyer to the merchant through an AI agent is exactly what the ACP delegated payment model resolves.
The answer is delegation via tokenisation. The buyer does not hand their raw card number to the AI agent. Instead, the AI surface collects payment details through a PSP-hosted interface — one that the merchant's PSP public key enables — and generates a single-use payment token. That token is what the agent relays to the merchant. The merchant processes the token through their existing PSP account, settles the payment, and creates the order. At no point does the agent store, decrypt, or have access to the buyer's underlying payment credentials.
This design means the agent is a credential relay, not a payment processor. The trust and settlement responsibility stays with the merchant and their PSP.
---
How the Delegated Payment Flow Works
The delegated payment flow is embedded in the ACP Checkout Session lifecycle. It works across four connected steps:
Step 1: Merchant declares PSP in checkout session creation response. When the AI agent calls `POST /checkout_sessions` to initiate a purchase, the merchant's response includes a `payment_provider` object. This object declares two values: the `type` (the PSP identifier — `stripe`, `adyen`, or `braintree`) and the `public_key` (the merchant's public key for that PSP account). These two values tell the agent exactly which PSP to use and how to tokenise the buyer's payment credentials for this specific merchant.
Step 2: Agent tokenises buyer payment credentials using the merchant's PSP public key. The agent presents a PSP-hosted payment collection interface to the buyer within the chat surface. The buyer enters their card or authorises a saved payment method. The PSP SDK generates a single-use payment token tied to the merchant's public key — meaning it can only be used for this merchant's PSP account. The raw payment credentials never leave the PSP-secured environment.
Step 3: Agent relays the payment token in the `complete` request. Once the buyer confirms the purchase, the agent calls `POST /checkout_sessions/{id}/complete`. The request body includes a `payment_data` object containing:
- `type` — the PSP identifier (e.g., `stripe`)
- `token` — the single-use payment token from the PSP
- `billing_address` — the buyer's billing address (optional)
- `payment_method_details` — optional PSP-specific object for additional payment context
Step 4: Merchant processes the token and creates the order. The merchant's backend receives the `complete` request, extracts the `token` from `payment_data`, and passes it to their PSP for processing — exactly as they would process any tokenised payment through their existing integration. The PSP authorises and settles the charge. The merchant creates the order in their OMS and responds to the agent with the completed session state, including the `order` object containing the order ID, session ID, status (`created`), and a permalink URL for the buyer to track the order.
---
Buyer Consent and Control
The ACP delegated payment model is built on explicit buyer consent at the point of purchase. The buyer authorises the transaction within the AI interface — they see the full cart state, including line items, fulfillment option, cost breakdown (items, subtotal, tax, fulfillment, total), and the merchant's terms of service and privacy policy URLs, all of which are returned in the checkout session object. The buyer must actively confirm the purchase before the agent calls the `complete` endpoint.
The `links` object in the checkout session response — containing `terms_of_service` and `privacy_policy` URLs — is the mechanism by which the merchant's purchase terms are surfaced to the buyer within the agent interface before confirmation. Merchants must include these URLs in every checkout session response. This is not optional: it is part of the conformance requirements merchants must pass before going live.
The buyer also has a clear cancellation path at any point before completion. The agent can call `POST /checkout_sessions/{id}/cancel` to terminate the session without processing any payment.
---
Roles in the Delegated Payment Flow
| Actor | Role in Delegated Payment | |---|---| | Buyer | Expresses purchase intent; confirms cart; authorises payment via PSP-hosted interface | | AI agent | Presents cart to buyer; collects PSP token; relays token to merchant `complete` endpoint | | PSP (Stripe / Adyen / Braintree) | Tokenises buyer payment credentials using merchant public key; processes token on merchant's account | | Merchant | Declares PSP and public key in session response; processes token; creates order; emits webhook events |
---
Security Considerations
Several design choices in the ACP delegated payment model protect all parties:
Tokenisation by merchant's own PSP. The payment token is generated by the same PSP the merchant uses for all their other transactions. The token is tied to the merchant's public key, making it non-transferable to another merchant account. This limits the blast radius of any interception.
Single-use tokens. Payment tokens in the PSP tokenisation model are typically single-use — valid for one authorisation attempt. Even if intercepted, a replayed token would be rejected by the PSP.
Signature verification on all requests. Every ACP request from the agent to the merchant includes a `Signature` header (Base64 encoded HMAC of the request body) and a `Timestamp`. Merchants must verify both on every request to detect tampering and replay attacks.
Idempotency enforcement. Every request includes an `Idempotency-Key`. Merchants must store and check this key to ensure that a retried `complete` request — for example after a network timeout — does not create a duplicate charge or duplicate order.
---
Why It Matters for Merchants
The delegated payment model removes the fear of ceding payment control that many merchants initially have when considering agentic commerce. The merchant's PSP remains the payment processor of record. The merchant's bank receives the settlement. The merchant's fraud rules apply. The merchant's PCI compliance scope does not expand because the tokenisation is handled by the merchant's existing PSP integration, not by a new party.
What changes is only the originating channel. An ACP-initiated payment arrives at the merchant's PSP in the same tokenised format as a payment originating from the merchant's own website checkout. From the PSP's perspective, it is a standard token-based charge authorisation.
This means merchants do not need to negotiate new PSP contracts, change payment processors, or build new settlement flows to support ACP. If they already use Stripe, Adyen, or Braintree, the path to ACP delegated payment support is an incremental integration effort, not a foundational infrastructure change.
---
FeedBridge Relevance
FeedBridge supports the pre-checkout product data layer that feeds into the ACP delegated payment flow. The product data in FeedBridge's ACP-compliant JSON-LD feed — specifically, item IDs, pricing, availability, and variant structure — is what the agent uses to construct the `POST /checkout_sessions` request that initiates the session where the merchant declares their PSP and public key. If this data is stale or inconsistent with the merchant's checkout endpoint, the session will return mismatched pricing, which undermines buyer confidence before the payment step is ever reached.
FeedBridge does not handle payment credential relay or PSP integration — those are the merchant's responsibility. FeedBridge's role ends at delivering a clean, accurate, complete product data layer that makes the pre-checkout evaluation reliable enough for a buyer to commit to the delegated payment step.
---
Frequently Asked Questions
Q: What PSPs does ACP support for delegated payment? A: ACP's delegated payment model supports three PSPs: Stripe, Adyen, and Braintree. Merchants must be integrated with at least one of these three to support Instant Checkout in ChatGPT via ACP.
Q: Does the buyer need to enter their card details every time they use Instant Checkout? A: This depends on the AI platform's implementation and the PSP's saved payment method support. The ACP specification defines the token relay mechanism; the specific buyer-facing payment experience within ChatGPT is managed by OpenAI and the PSP's client-side integration.
Q: Can a merchant decline a payment after the agent submits the `complete` request? A: A merchant can return an error in the `complete` response if the payment fails (e.g., PSP returns `payment_failed`) or if the order cannot be fulfilled. The agent surfaces the failure to the buyer. If a merchant wants to hold an order for review before confirming it, they should create the order with `manual_review` status and transition it via the webhook system.
Q: Does delegated payment affect chargebacks or disputes? A: No. Chargebacks and disputes are handled by the merchant's PSP under their existing agreements. The originating channel (ACP vs. web) does not change the PSP's dispute resolution process. The merchant receives the buyer's email in the `buyer` object, which can support post-purchase customer service.
Q: What happens if the PSP token expires before the `complete` request is sent? A: PSP tokens have a validity window. If the token expires before the merchant processes it, the PSP will return an error and the `complete` request will fail. The agent should present the payment collection interface again so the buyer can generate a fresh token.
---
Related Topics
Parent hub: ACP Checkout
Related concepts:
- What Is ACP?
- ACP Instant Checkout in ChatGPT Explained
- ACP Checkout API Overview
- ACP Certification and Production Readiness
Breadcrumb:
---
Source Documentation
| Claim | Source | Source Class | Reference | |---|---|---|---| | ACP `payment_provider` object: type and public_key in checkout session response | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | `payment_data` object in `complete` request: type, token, billing_address | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | Supported PSPs: Stripe, Adyen, Braintree | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | Buyer consent: cart state, terms_of_service and privacy_policy links in session | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | Signature, Idempotency-Key, Timestamp headers — merchant verification requirements | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | FeedBridge ACP JSON-LD feed and product data layer | FeedBridge Platform Capabilities April 2026 v2.0 | T1 – FeedBridge Internal | FeedBridge-Platform-Capabilities-April2026.md |