Hi everyone, I’m currently working with merchants and cross-border brands that are interested in the ChatGPT commerce ecosystem. We are exploring merchant onboarding readiness, product feed preparation, and possible ACP-based checkout implementation.

I’m not posting this as a support request, but rather to better understand the practical side of preparation and rollout.

A few questions I’d love insight on:

1. For merchants preparing early, what are the most important things to get right in the product feed before formal onboarding?

2. From a practical perspective, what tends to matter most for ACP / checkout readiness?

3. Are there any common mistakes or gaps merchants should avoid when preparing for this kind of integration?

4. For teams working with cross-border brands, are there any best practices for preparing merchants before they enter a more formal review process?

Would really appreciate any technical or operational insight from people thinking about this space. Thanks.

On ACP checkout readiness specifically, since that’s the part I have direct experience with (we just built our own ACP checkout implementation at Facet): the formal OpenAPI schema (the additionalProperties: false and required blocks) is authoritative, and it sometimes disagrees with the spec’s own worked examples on the same field. We hit this on three separate request fields this week: line items can arrive keyed as line_items even though an example elsewhere shows items, the fulfillment address can be nested inside fulfillment_details.address rather than flat, and the payment credential can be nested under instrument.credential or flat, with the spec’s own example contradicting its own schema on that one. If you build against the example JSON alone, you’ll handle example-shaped requests fine and silently mishandle real ones that don’t match.

One common mistake worth flagging: treating a popular third-party reference implementation as authoritative. We ran a differential test against one and it diverges from the real spec on several of these same fields. Any reference implementation, including OpenAI’s own examples, is worth verifying against the formal schema rather than trusting outright.

Practically, on the five-endpoint lifecycle (create, get, update, complete, cancel): give every single one the same signature-verification treatment. It’s easy to be careful on create/complete/cancel since they feel like the money path, and treat get as an afterthought. We found exactly that gap in our own build, a review process (ours or anyone else’s) checks for consistency across all five, not just coverage of the ones that feel important.

I don’t have direct experience on the feed-prep or cross-border-specific questions, so I’ll leave those to others here.