Platform guides

The tag is the same everywhere. Three things differ by platform, and only three: where the script goes, how the cart total is read, and where the claim happens. Each guide below answers those three. But they are not equivalent guides, because we have not done equivalent work. Start with the table.

If you have not read How the integration works, read it first: the mechanics behind every page here (page detection, adapters, the click id, the gwp:selection hook) are explained there once and not repeated. The generic, platform-agnostic install steps live in Install the tag.

Where we stand

We would rather tell you this up front than have you discover it mid-sprint.

Platform	Status	Cart read	Claim moment
Shopify — cart page and cart drawer	Running in production. Both surfaces, the cart-attribute → order-email claim path, and the Liquid snippet on that page are all live code, exercised end to end on a real order	dom	Your own order-confirmation email. Shopify's thank-you page is part of checkout and never loads your theme
Custom / headless / in-house	Running in production, including a storefront whose checkout lives on a sibling subdomain	datalayer most often; window or dom also fine	Your confirmation page (on-page redemption card), your own email via the gwp:selection hook, or both
BigCommerce	Not done. No completed install	Expected dom, or datalayer if you run GTM	To confirm. See that page
Magento / Adobe Commerce	Not done	Expected datalayer or dom	Your checkout/onepage/success page is yours, so the on-page card should work (to confirm)
WooCommerce	Not done	Expected dom, or datalayer if you run a GA4 plugin	Your order-received page is yours (to confirm)
Salesforce Commerce Cloud	Not done	Expected datalayer (Tealium/GTM) or dom	Your Order-Confirm page is yours (to confirm)

"Not done" means exactly that: nothing in the last four rows has been through a real install. Nothing about them looks hard. The tag makes no platform-specific assumption about how you build, and the same three adapters are all that exist. But we are not going to describe an untested path as if we had walked it. Talk to us (email support@gwpingenuity.com with [INTEGRATION] in the subject) and we will scope it with you in one call.

A page per platform is not a claim of parity. Four of the six pages below exist to tell you what we would need to find out, not what we have done. The two proven ones are much longer for exactly that reason: they describe work that happened.

The platforms we have shipped

• Shopify, the proven path in eight steps: the tag in theme.liquid, placement on the cart page, the cart drawer's two selectors, the dom cart read, the order-confirmation email claim path with the Liquid snippet in full, consent, CSP and a checklist.
• Custom, headless and in-house covers where the tag goes in a bespoke stack, all three cart adapters, a checkout on a sibling subdomain, and the two claim moments: the on-page redemption card and your own email via the gwp:selection hook.

The platforms we have not shipped

We have not done an install on any of these four. Each page sets out the shape we would expect and the specific things we would confirm with you. Treat every "likely" on them as a question, not a promise: we can tell you exactly how the tag behaves, but we cannot tell you how your platform behaves until we have looked at it together.

Two things are true regardless of platform:

• Only one Shopify-specific path changes what you have to build: the cart-attribute writer (/cart/update.js), and it is off unless the order-email channel is enabled for your account. The tag also ships Shopify-specific detectors: a Shopify Customer Privacy consent adapter, and Shopify/Dawn/Horizon cart events used to notice a drawer opening. Those are additive and simply inert on other platforms. Everything else (page detection, the three adapters, the click id, the claim URL, the gwp:selection hook) is platform-neutral.
• The generic hook is your email path on any platform. If your platform can put a value on the order and render it in a transactional email, you have a claim channel, whatever it is.

The four pages, and the first thing each one would hinge on:

• BigCommerce: Script Manager or the Stencil base layout; */cart.php already matches our default basket patterns. First thing we would test together: whether a Script Manager script can carry the redemption card on the order-confirmation page.
• Magento / Adobe Commerce takes layout XML or a GTM container; checkout/onepage/success is your own page, so the on-page card is the path we would aim for. The open question is the Knockout-rendered cart summary.
• WooCommerce: wp_enqueue_script or a tag-manager plugin; the order-received page is yours. The open question is the cart-total selector, because themes vary enormously.
• Salesforce Commerce Cloud, via an ISML include or your existing Tealium/GTM container; Order-Confirm is your page. The open questions are your URL shapes (SFRA vs SiteGenesis) and a CSP that is often strict.

What to bring to that conversation

Three answers get an unproven platform scoped in a single call:

1. The URL patterns of your basket page and your confirmation page, as they really appear in a browser, including locale prefixes and any subdomain hop.
2. How a script on the page can read the current cart total: a data layer, a global we can read, or a selector that is stable in your theme.
3. Where you want the claim to happen (your confirmation page, your own transactional email, or both) and, if it is the email, what your email platform can read off an order.

Bring a staging URL if you have one; the tag runs there as soon as the hostname is registered. The same is true of a hostname on your own laptop (local development).

Where next

• Install the tag: snippet, page registration, adapters, verification steps, troubleshooting and CSP in full.
• How the integration works: the mechanics, once.
• Conversion API, for the advertiser side.
• Ask us something. Email support@gwpingenuity.com with [INTEGRATION] in the subject, including "we are on a platform you have not done". We would rather scope it than have you find the gaps. (/support is the shopper help page, not developer support.)