UCP Catalog 2026-08-25 · UCP Checkout 2026-08-25 · UCP & AP2 Mandates
1. Returning an inconsistent catalog
Test search and lookup with representative products, variants and unavailable items. Apply the filters and availability structure defined by the negotiated Catalog capability; do not copy Schema.org stock labels into the UCP payload. The published catalog scope should match what this channel can actually sell.
2. Reusing stale inventory
Catalog data describes current terms for a request; it does not reserve inventory or guarantee a sale. Use the supported lookup capability and revalidate prices and availability during checkout. Set cache and ERP synchronization policies from actual stock volatility, and avoid reusing session-specific responses across buyers.
3. Validating against an invented field list
Validate product and variant objects against the schema for the negotiated version. Catalog prices use an amount in minor currency units plus a currency code. Keep variant IDs consistent with checkout item IDs. Include genuine product identifiers where supported; neither a made-up taxonomy nor a guessed required-field list establishes conformance.
4. Confusing login tokens with payment mandates
Identity authorization and AP2 payment authorization are different contracts. Handle OAuth token expiry through the identity provider flow. With AP2 Mandates, verify signed Checkout and Payment Mandates and their transaction binding. Do not silently refresh an expired purchase authorization as though it were an ordinary login token.
5. Using opaque product names
Keep a stable product identifier, but provide an accurate, descriptive title and useful attributes. A material, size and capacity help distinguish variants. Validate the published fields against Catalog; a custom business field does not become a standard UCP field because it targets an AI agent.
6. Mixing website markup with checkout policies
Schema.org return-policy markup describes a public web page. UCP checkout has its own links and policy contract. Expose the real merchant terms through the fields supported by the negotiated specification and keep them consistent with the website. Do not invent a return-policy object and present it as normative.
7. Choosing untested rate limits
Set limits per operation and authenticated client using load tests and operational risk. Document retry behavior and test throttling without weakening authorization. Neither a universal requests-per-minute allowance nor inventory reservation at every checkout request follows from UCP.
8. Breaking HTTPS trust
Verify the certificate hostname, expiry and full certificate chain on the actual API host. Automate renewal and alert before expiry. Include an HTTPS check in release validation; never disable certificate verification to make a failed integration appear healthy.
9. Treating asynchronous completion as failure
Creating a checkout is distinct from completing it. The versioned Checkout specification supports complete_in_progress for accepted completion that is still running. Retrieve the existing checkout with Get until a documented outcome is available. Do not invent an optimistic order ID or replay Complete with a new idempotency key while the result is unknown.
10. Testing only the successful path
Validate versioned schemas and maintain contract tests for invalid requests, insufficient authorization, price changes, escalation, timeouts and duplicate completion attempts. Manual examples are useful but insufficient. State which version and transport passed, and keep the evidence; these checks do not confer an official certification.