Theme inspector: what Shopify (and competitors) actually see.

A Shopify store leaks more provider identity through theme.liquid and its shipped JavaScript than most operators realize. Anyone with the storefront URL can view the source, download every referenced JS bundle, and grep for provider brand strings, endpoint paths and gateway names. Competitors doing store teardowns use exactly this workflow. Category scanners like Ecomhunt-style tools index it at scale. And the friendly-looking developer inspecting your theme code from a support ticket can see the same. This post is what a determined inspector actually finds — and what a brand-cloak obfuscation layer removes from that finding.

Step 1: read theme.liquid

An inspector who can open the theme code editor (via Shopify's own theme editor, or via a Shopify collaborator invite, or via a purchased theme audit) reads theme.liquid directly. Third-party checkout providers historically require a two-line paste into theme.liquid: an inline stylesheet that hides express-wallet buttons, plus a <script src> tag pointing to the provider's hosted JS bundle. Both lines are readable text. The stylesheet contains identifiers like shopify-payment-button, shop-pay-button, apple-pay-button. The script tag contains the provider's domain in the src attribute.

From this alone, an inspector who does not even leave the theme editor knows: this store is using a third-party checkout, the provider's domain is X, and native express-wallet buttons are being suppressed.

Step 2: download the shipped JavaScript

Copy the URL from the <script src>. Fetch it with curl. Open in an editor. Search for brand strings.

An unminified or lightly-minified checkout bundle typically contains dozens of readable identifiers — the provider's brand name in class names and log strings, gateway names in adapter class definitions, endpoint paths in fetch calls, store-config keys in JSON serialization, function names that describe what the code does (fireAddToCart, reconstructFbcCookie, dustoHideExpressCheckout). Each of those is a fingerprint.

An inspector doing a serious teardown grabs the bundle, indexes it against known provider fingerprints, and identifies the checkout stack in minutes. That intelligence can end up in a competitor's playbook, in a "these 12 high-risk stores are using X" list, or in a category scanner that automates the identification.

Step 3: watch the network tab

Open browser devtools, hit the checkout, watch the Network panel. Third-party endpoint URLs appear in the request list. Response headers appear in the request detail. X-Powered-By: Next.js, Server: Vercel, custom X-Provider-Version headers — any of these identify the stack behind the checkout page. Cookies set on the checkout domain reveal SDK usage and session identity patterns.

What brand-cloak obfuscation removes

Each of the three inspection surfaces above has a specific cloak response:

• theme.liquid — reduce the paste to a single <script src> line. Move the inline stylesheet into the loader body. The theme code no longer describes the checkout behavior; it just loads the checkout.
• shipped JS — Terser plus javascript-obfuscator on the moderate config. String literals split-encoded-reassembled. Function names mangled. Control flow flattened. Brand fingerprints eliminated. A leak audit runs on every deploy against a 22-marker fingerprint list — bundle does not activate to production if any marker is present.
• response headers — X-Powered-By stripped. Server normalized. Custom identifying headers removed. What Vercel re-injects at the edge can be stripped by an optional Cloudflare Worker proxy for merchants who need zero-header-leak.

Why competitor visibility matters for high-risk stores

On mainstream DTC, provider-stack visibility is a minor concern — knowing that store X uses checkout provider Y does not really change anything for a competitor. On high-risk verticals, it does. Stack visibility helps competitors identify which specific MIDs are underwriting your category, which acquirers still approve your MCC, which provider you use to route around Shopify Payments. Once that intelligence is in a competitor's playbook, they onboard the same provider, and any acquirer-side risk shocks (throttling, tightening) hit both of you at the same time.

Brand cloak does not solve competitor intelligence entirely. It raises the bar. A determined inspector with reverse-engineering skills can eventually identify most obfuscated bundles. The point of the cloak is to make casual identification impossible and serious identification expensive.

What to check on your own store right now

1. Open your storefront URL in a browser.
2. View source. Search for your checkout provider's brand.
3. Copy any third-party <script src> URLs. Fetch them with curl.
4. Grep the fetched JS for your checkout provider's brand name, for any gateway names, for endpoint paths.
5. Open devtools Network panel. Do a test checkout. Read response headers on the checkout page.

Whatever comes up in that scan is what a competitor inspecting your store sees. If any of it should not be public, the cloak layer is the reason to consider.

Related reading: Brand cloak checkout (product page) · Full cloak stack · Cloak your checkout off SP radar