Standalone storefront guide

Purpose

This guide explains how to install the Tern storefront on a standalone shop that does not use headless authentication.

This is the anonymous no-proof storefront path. It is the lower-trust option and should only be used when the recommended authenticated headless flow is not possible.

For new integrations, prefer an authenticated headless guide:

Recommendation First

Use the standalone no-proof flow only as a fallback.

Tern recommends the authenticated headless approach because it provides a stronger trust signal, supports merchant-signed bootstrap, and can attach customer context when needed.

Use the authenticated guide when you need any of the following:

  1. Logged-in customer context.

  2. Server-generated proof of who is bootstrapping the storefront.

  3. Stronger protection against unauthorized or copied integrations.

  4. A path that can safely identify a Shopify customer.

Security Concerns

This standalone flow has important security limitations:

  1. There is no merchant-signed proof on the bootstrap request.

  2. The browser does not prove customer identity.

  3. The storefront session is anonymous only.

  4. Anyone who can serve code from the configured standalone origin can attempt to bootstrap the storefront.

  5. You must not treat the returned storefront token as proof that a customer is logged in.

Because of those limits, this mode is appropriate only for anonymous standalone storefront experiences.

If you need customer-aware behavior or stronger trust guarantees, stop here and use one of the authenticated headless guides instead.

Summary

The simplest standalone implementation has two steps:

  1. Load the storefront runtime.

  2. Add <tern-trade-in> to the page.

Optional config overrides can be added later if you want to force a locale.

Minimal Install

For standalone storefronts, the minimal install does not need window.ternStorefrontConfig.

If the page is served from the exact standalone hostname configured in Tern, the storefront can resolve the shop from the request origin and initialize its session from subsequent storefront API calls.

Minimal head

Minimal body

Why This Works

When no config is provided:

  1. The storefront uses the page origin to identify the standalone shop.

  2. Locale falls back to the document language first, then the browser language.

  3. The first storefront API calls can initialize the standalone session from that origin.

Use the minimal install unless you need a specific locale override.

Optional Config Overrides

If you want to override the locale explicitly, add one extra step to the minimal install:

  1. Define window.ternStorefrontConfig before mounting <tern-trade-in>.

Config Format

Expose window.ternStorefrontConfig only if you need an override such as a forced locale.

For standalone anonymous bootstrap, the optional config should usually include only:

  1. locale

Example:

Rules:

  1. Use locale only when you need to override the default locale.

Session Behavior

In the minimal standalone install, there is no explicit bootstrap request to configure first.

Instead:

  1. The storefront mounts on the page.

  2. Early storefront API requests use the page origin to resolve the standalone shop.

  3. The storefront session token is established and refreshed as those API requests complete.

That token is a Tern storefront session token for anonymous storefront traffic. It is not customer authentication.

If you add window.ternStorefrontConfig for a locale override, the runtime can make the explicit headless bootstrap request before mount. The minimal install does not depend on that call.

Browser Runtime And Mount

The minimal install is the recommended starting point.

If you need an override such as locale, add window.ternStorefrontConfig before the same direct <tern-trade-in> mount:

For shared runtime prerequisites around loading the bundle before mount, see What The JavaScript Example Assumes.

Standalone-specific prerequisite:

  1. The page must be served from the exact standalone hostname configured in Tern.

Operational Notes

Keep these constraints in mind:

  1. This flow is origin-based and anonymous.

  2. Logged-in customer identification is not supported.

  3. If the page origin does not match the configured standalone shop domain, bootstrap can fail or resolve the wrong shop.

If you later need authenticated sessions, do not extend this pattern in the browser. Move to one of the authenticated headless guides instead.

Implementation Checklist

  1. Configure the standalone shop record in Tern.

  2. Confirm the shop uses the exact standalone hostname you will serve from.

  3. Serve your storefront page from that hostname.

  4. Load the storefront browser bundle, for example https://prod.tern.eco/js/storefront/trn-nrc-umd.js.

  5. Add <tern-trade-in> to the page.

  6. Only add window.ternStorefrontConfig if you need an override such as locale.

  7. Let the storefront module initialize the anonymous storefront session.

  8. Treat the storefront session token only as the Tern storefront session token for anonymous storefront APIs.

  9. If stronger security or customer context is needed, switch to Shopify Headless Storefront Integration Guide or Non-Shopify Headless Storefront Integration Guide.

Last updated