ACP Certification and Production Readiness
> ACP production readiness requires passing conformance checks across four areas — schema correctness, error code standards, rate limit handling, and webhook delivery reliability — before a merchant can support Instant Checkout in ChatGPT; the ACP specification is open to all implementers, though the ChatGPT Instant Checkout channel currently operates through an approved partner program.
---
What Is ACP Certification?
ACP certification is the process by which a merchant validates that their implementation of the Agentic Commerce Protocol meets the conformance requirements needed to go live on ACP-powered AI surfaces. It is not a credential issued by a standards body — it is a conformance verification process, typically run against a defined checklist of technical requirements, that confirms the merchant's ACP endpoints behave correctly and safely under real-world conditions.
The ACP specification is open to all implementers. Building with the protocol is unrestricted — any merchant, developer, or platform can implement the five Checkout Session endpoints and integrate with a supported PSP. However, to appear as a purchasing option within ChatGPT Instant Checkout specifically, a merchant's integration must be approved through the current partner program operated by OpenAI. This distinction matters: open specification, gated distribution channel.
Certification readiness is therefore the state in which a merchant's implementation is technically correct and conformance-verified, making it eligible for submission to whatever approval process the target AI platform operates.
---
The Four Conformance Areas
1. Schema Correctness
All five ACP endpoints must return responses in the exact schema defined by the ACP specification. This includes:
- All required fields present and correctly typed (e.g., `cost.total` is numeric, not a string)
- Enum values matching the defined set exactly (e.g., `status` must be one of `open`, `completed`, `canceled`, `expired`; order status must be one of `created`, `manual_review`, `confirmed`, `canceled`, `shipped`, `fulfilled`)
- Nested objects fully populated where required (e.g., `cost` object must include `items`, `subtotal`, `tax`, `fulfillment`, and `total`)
- `links` object present in all session responses with `terms_of_service` and `privacy_policy` URLs
- `payment_provider` object present in the initial session creation response with valid `type` and `public_key`
ACP defines standard error codes for known failure scenarios. Merchants must return these exact codes — not custom error messages or generic HTTP errors — so that the AI agent can correctly surface the failure reason to the buyer:
- `out_of_stock` — item is unavailable
- `item_not_found` — item ID does not exist in the merchant's catalog
- `invalid_address` — the fulfillment address cannot be fulfilled
- `payment_failed` — the PSP rejected the payment token
- `session_expired` — the session has passed its expiry time
- `invalid_session` — the session ID does not exist or has already been completed or canceled
3. Rate Limit Handling
Merchants must implement rate limiting on their ACP endpoints and return `429 Too Many Requests` with a `Retry-After` header when limits are exceeded. This signals to the agent how long to wait before retrying. Merchants who do not implement rate limiting risk endpoint overload during high-volume periods, and agents that receive unhandled errors instead of `429` responses may retry immediately, compounding the problem.
4. Webhook Delivery Reliability
Merchants must demonstrate reliable delivery of `order.created` and `order.updated` webhook events to the AI platform's webhook endpoint. Webhooks must be:
- Signed with HMAC using the shared secret provided by the AI platform
- Delivered promptly after order state changes
- Retried by the merchant if delivery fails (the merchant is responsible for reliable delivery, not the platform)
- Carrying the correct order status value at each transition point
---
Implementation Checklist for Certification Readiness
- [ ] `POST /checkout_sessions` returns full session object with all required fields
- [ ] `payment_provider` object present in session creation response with `type` and `public_key`
- [ ] `links` object with `terms_of_service` and `privacy_policy` URLs present in all session responses
- [ ] `POST /checkout_sessions/{id}` recalculates tax on address update and returns updated `cost` object
- [ ] `POST /checkout_sessions/{id}/complete` processes PSP token and returns `order` object
- [ ] `order` object includes `id`, `checkout_session_id`, `status: created`, and `permalink`
- [ ] `POST /checkout_sessions/{id}/cancel` returns session in `canceled` status
- [ ] `GET /checkout_sessions/{id}` returns current session state
- [ ] All error scenarios return ACP-standard error codes (not custom messages)
- [ ] `Authorization` header verified on all requests
- [ ] `Signature` header verified against request body on all requests
- [ ] `Timestamp` validated to reject replay attacks
- [ ] `Idempotency-Key` stored and enforced on `complete` endpoint
- [ ] Rate limiting implemented; `429` with `Retry-After` returned when exceeded
- [ ] `order.created` webhook delivered promptly after order creation
- [ ] `order.updated` webhook delivered on every order status transition
- [ ] Webhooks signed with HMAC using platform-provided shared secret
- [ ] Product feed submitted at stable HTTPS URL and accessible for indexing
- [ ] Trust signal fields present on all products in feed
Sandbox vs. Production
The ACP specification describes testing against a sandbox environment before going live in production. A sandbox environment allows a merchant to:
- Test the full checkout session lifecycle with simulated PSP responses
- Verify that all five endpoints return correct schema without processing real payments
- Simulate error conditions (out of stock, invalid address, payment failure) to confirm error codes are correctly returned
- Test webhook delivery to a sandbox endpoint before the production webhook endpoint is registered
---
Why It Matters for Merchants
Certification readiness is the gate between having an ACP implementation and having a live, revenue-generating ACP channel. A technically sound implementation that has not passed conformance verification cannot appear in a live AI shopping surface. The investment in getting certification right is also an investment in operational quality: merchants who implement signature verification, idempotency, and correct error codes have a more robust checkout system overall — one that handles edge cases gracefully rather than creating silent failures or duplicate orders.
The conformance requirements are also a forcing function for data quality. A merchant cannot pass the schema check if their product feed is missing required fields; they cannot pass the webhook reliability check if their order management system does not emit status updates. Certification preparation therefore drives improvements across the merchant's entire product and order data stack, not just the ACP-specific endpoints.
---
FeedBridge Relevance
FeedBridge's AI Readiness Score includes Protocol Compliance as its highest-weighted dimension (30% of the total score). Protocol Compliance scoring in FeedBridge validates ACP and UCP compliance status at the product and feed level — confirming that the required protocol fields, trust signals, and data formats are present in the product data layer before the merchant enters the API-level certification process.
This makes FeedBridge a pre-certification tool for the data layer. A merchant whose products score well on Protocol Compliance in FeedBridge has significantly reduced the risk of schema failures during ACP certification, because the trust signal fields, variant structure, and product identifiers that the certification process validates against are the same fields that FeedBridge's scoring and enrichment engine generates and measures. Merchants can review their Protocol Compliance score per product in the FeedBridge dashboard, with actionable fix suggestions and one-click navigation to problem fields.
---
Frequently Asked Questions
Q: Is there a formal ACP certification body? A: The ACP specification is open. There is no single independent certification body. To appear in ChatGPT Instant Checkout specifically, merchants must pass OpenAI's conformance checks as part of the approved partner program. Other ACP-compatible AI platforms may run their own conformance processes.
Q: How long does the certification process take? A: The ACP specification does not define a certification timeline. This page does not make claims about approval timelines for any specific platform's partner program. Merchants should contact the relevant AI platform for current program status.
Q: Can I test webhooks without a live order? A: Yes. During sandbox testing, merchants can emit test `order.created` and `order.updated` events to a sandbox webhook endpoint to verify signing, payload format, and delivery reliability before a real order is ever created.
Q: What is the most common cause of certification failure? A: Based on the conformance requirements, the two highest-risk areas are idempotency enforcement on the `complete` endpoint (which requires storing and checking `Idempotency-Key` values to prevent duplicate orders on retry) and signature verification (which requires HMAC verification of every inbound request, not just some). Missing either of these is both a security risk and a certification blocker.
Q: Do I need to re-certify if I change my PSP? A: Changing your PSP changes the `type` and `public_key` values you return in the `payment_provider` object, and changes the token format you process at the `complete` endpoint. This constitutes a material change to your ACP implementation and should be retested against the full conformance checklist before going live with the new PSP.
---
Related Topics
Parent hub: ACP Implementation
Related concepts:
- What Is ACP?
- ACP Merchant Onboarding Requirements
- ACP Product Feed Requirements
- What Merchants Need for Agentic Commerce Readiness
Breadcrumb:
---
Source Documentation
| Claim | Source | Source Class | Reference | |---|---|---|---| | ACP conformance areas: schema correctness, error codes, rate limits, webhook reliability | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | ACP error codes: out_of_stock, item_not_found, invalid_address, payment_failed, session_expired, invalid_session | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | Order status enum values | OpenAI ACP Checkout Spec | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | Building with ACP open to all; ChatGPT Instant Checkout through approved partner program | OpenAI ACP Checkout Spec / agenticcommerce.dev | T1 – Official ACP Docs | https://developers.openai.com/commerce/specs/checkout/ | | FeedBridge Protocol Compliance scoring (30% of AI Readiness Score) | FeedBridge Platform Capabilities April 2026 v2.0 | T1 – FeedBridge Internal | FeedBridge-Platform-Capabilities-April2026.md |