OpenID FAPI and OpenAI ACP: How API Security Meets Agent Checkout

Two specifications keep showing up in the same conversations about AI agents that buy things: the OpenID Foundation's FAPI 2.0 and OpenAI's Agentic Commerce Protocol (ACP). They are often mentioned together. They do not solve the same problem, and neither one was written to replace the other.

This post separates what each one documents, then sketches what a team has to design on its own to use them in one system.

What FAPI 2.0 solves

The FAPI 2.0 Security Profile is, in its own words, "an API security profile suitable for high-security applications based on the OAuth 2.0 Authorization Framework." It reached Final status in February 2025 (see the OpenID FAPI specifications page).

It constrains how a confidential client obtains and uses tokens:

Pushed Authorization Requests (PAR) for every authorization request
PKCE with the S256 method
Sender-constrained access tokens, using either mutual TLS or DPoP
Client authentication by mutual TLS or private_key_jwt
An iss parameter in authorization responses, which the client must verify

FAPI 2.0 says nothing about carts, prices, shipping, card credentials or settlement. It answers one question: is this client, holding this token, safely talking to this API?

What ACP solves

ACP is hosted in the agentic-commerce-protocol GitHub repository, which labels it beta, lists OpenAI and Stripe as founding maintainers, and shows versioned releases; the latest we found is 2026-04-17, which added cart, feed, orders, authentication and MCP compatibility. OpenAI's key concepts guide describes four roles: the buyer, the ChatGPT agent, the merchant, and the PSP. The checkout spec has the merchant implement REST endpoints to create, update, complete and cancel a checkout session, with session states moving from not_ready_for_payment to ready_for_payment to completed or canceled.

One scope note: CNBC reported that OpenAI ended ChatGPT's Instant Checkout in March 2026 to let merchants use their own checkout while it focuses on product discovery. That changes where ChatGPT fits, not the protocol documents themselves, which remain published. Treat any "ChatGPT checks out for you" scenario, including the roles in the key concepts guide, as the protocol's model rather than a statement about a live product.

The Delegated Payment Spec is the payment half. It describes a single-use payment credential bounded by an allowance (maximum amount, currency, checkout session, merchant, expiry) that is handed to a PSP, which returns a vault token the merchant can use. The spec states that direct integration is for PSPs and PCI DSS level 1 merchants using their own vaults.

ACP answers a different question: how does an agent move a purchase from cart to order without exposing raw payment credentials to everyone in the chain?

Side by side

	FAPI 2.0 Security Profile	OpenAI ACP (checkout + delegated payment)
Publisher	OpenID Foundation	OpenAI
Layer	OAuth API security	Commerce and payment-credential delegation
Core objects	Authorization requests, tokens, client keys	Checkout sessions, orders, allowances, vault tokens
Protects against	Token theft and replay, client impersonation, authorization-response mix-up	Credential exposure; use beyond the delegated amount, merchant or expiry
Does not cover	Checkout, payment processing, purchase approval	Whether the caller's API session met FAPI-level requirements
Documented status	Final (Feb 2025)	Beta per the GitHub repo; versioned releases, latest found 2026-04-17; OpenAI and Stripe as founding maintainers

A conceptual purchase sequence

Conceptual only. This is our architectural interpretation, not a flow defined by either specification. Nothing here establishes that FAPI 2.0 and ACP interoperate natively.

API access. An agent platform obtains tokens from an authorization server. If the team chose FAPI 2.0, this is PAR + PKCE + DPoP or mTLS.
Checkout. The agent calls the merchant's checkout endpoints (create session, update, mark ready).
Payment delegation. A delegated-payment request carrying an allowance goes to the PSP; a vault token comes back.
Merchant/PSP processing. The merchant completes the session with the token and runs its normal authorization and capture.
Transaction evidence. An order, a PSP transaction ID and later webhook events (the checkout spec lists order_created and order_updated) record what happened.

Steps 2 to 5 are ACP territory. Step 1 is where a team might apply FAPI 2.0, but ACP's documents we read do not mandate it, and FAPI 2.0 does not mention ACP. Wiring them together means deciding which APIs sit behind FAPI-grade tokens, who the authorization server is, and how an OAuth subject maps to the buyer in a checkout session. That is integration design, not a checkbox.

A note on AP2 and the OpenID mailing list

Google's Agent Payments Protocol (AP2) is a third, separate thing. A September 2025 post to the OpenID FAPI working group list discusses AP2's impact on FAPI. Separately, the OpenID Foundation has submitted comments on EMVCo's agentic payments framework draft, recommending among other things that agent identity be kept distinct from delegated authority. That is a response to EMVCo, not to ACP or AP2. A mailing-list discussion is not an OpenID specification, and it does not show that OpenID owns or endorses AP2. We found no public statement from OpenAI responding to an OpenID payment specification, and we make no claim either way.

Questions to answer before choosing protocols

Which layer are you actually missing: API client security, checkout, payment-credential delegation, or approval?
Who is the buyer of record in your system, and how is that identity carried into a checkout session?
Where is the spending limit enforced, and by which party? The Delegated Payment Spec does not say whether the PSP or vault enforces allowance constraints, so assume you must verify this with your PSP.
Which events become your evidence: token issuance, approval, session completion, PSP capture, fulfillment?
Are you a PSP or PCI DSS level 1 merchant with your own vault, or will you go through a PSP's shared-token product?

Where ContextIQ fits

ContextIQ's Agent Protocol Inspector scans a URL for MCP, A2A and ARD support and reports verdicts with evidence, including detection of OAuth-protected MCP servers. It does not scan for FAPI or ACP conformance today. The x402 Inspector analyzes the payment endpoint's 402 challenge; it does not analyze payment requests. These are inspection aids for endpoints, not authorization, enforcement or certification.