Move checkout customizations to supported APIs.

Inventory the behavior first

Record what each customization does, where customers encounter it, and which data it requires. Include the behavior when a request fails or a customer uses an accelerated checkout.

Move UI to a supported checkout extension target, business rules to the appropriate Function API, and event collection to a supported pixel integration. Consent is a separate responsibility; the Customer Privacy API is not a substitute for an analytics pixel.

Choose the supported surface

The reviewed 2026-07 checkout documentation uses Polaris web components with Preact examples. Existing React-hook integrations must be checked against their pinned API version rather than mechanically relabeled as current.

Information, shipping, and payment-step UI extensions require Shopify Plus. Confirm each target and capability in the versioned reference. Do not design around arbitrary checkout DOM access. The small manifest below is an inventory format for a project, not a Shopify deployment configuration.

{
  "customizations": [
    {"purpose": "Delivery message", "surface": "Checkout UI extension"},
    {"purpose": "Discount eligibility", "surface": "Shopify Function"},
    {"purpose": "Order analytics", "surface": "Pixel integration"}
  ],
  "checks": ["plan eligibility", "consent", "failure recovery"]
}

Test before the cutover

1. Record the current configuration and define recovery options supported by the platform.
2. Test UI, rules, and tracking independently in a development environment.
3. Exercise mobile layouts, accelerated checkouts, currency changes, and unavailable data.
4. Compare the intended business behavior with the result, including duplicate or missing events.
5. Release an agreed scope and monitor errors. Do not promise universal immediate rollback or zero conversion impact.