While your own front-end web application provides the user experience for the majority of your storefront, the Redirected Checkout scenario that we’ll discuss more extensively later is one that involves serving certain pages from a Stencil-based BigCommerce storefront.
Mixing the BigCommerce storefront into your strategy brings up considerations about both domains and channels.
A cross-channel strategy involves using one channel for the headless storefront while using the default channel for serving the Stencil-based checkout. Since any cart can be loaded via checkout redirect URLs and any customer logged in via the Customer Login API, this is a viable setup.
This is not usually the recommended setup in production, as it’s possible to serve Stencil content without needing two separate storefronts by using the single-channel strategy we will discuss next. However, certain scenarios might make it the best choice. If your store contains multiple headless storefronts, but you want each of them to resolve to the same central domain for checkout, this strategy makes sense.
This is also simply the most straightforward strategy requiring the least up-front configuration. In your sandbox store or during pre-launch development when you don’t have the right DNS tools available to make a single-channel workflow function, using your default channel for checkout is your most likely option.
You may note upon first creating a Channel Site for a headless channel that the checkout URL is automatically set to the URL of your default channel.
Any channel, even one not designated as a BigCommerce storefront, can serve a Stencil-based checkout, so long as a domain exists that resolves to the BigCommerce web servers to allow for it.
You can see this in action with a canonical URL, which will actually serve a Stencil storefront for any path, not just checkout. If you have a headless storefront channel, try browsing directly to the canonical URL (https://store-{store-hash}-{channel-ID}.mybigcommerce.com) to observe a typical Stencil storefront.
While there are some DNS hurdles to overcome in order to serve BC checkout directly on a channel where the primary domain is for the headless front-end, this strategy avoids an unnecessary extra active storefront.
For a single-channel strategy, your Channel Site will be configured as follows:
Mixing in BigCommerce storefront pages presents an inherent challenge: Your store domain - mystore.com - resolves to your own custom front-end, but you need some requests to resolve to BigCommerce.
While we’re not going to go in-depth into the domain configuration required, there are two main strategies to consider:
checkout_URL must be a sub-domain of the primary URL.CAUTION!
Note that using a reverse proxy means that a request is transmitted through your own web server before it is forwarded to the BigCommerce storefront. If payment details are transmitted through a URL path proxied in such a way, this will have PCI compliance implications despite the fact that the end destination is a BigCommerce server. Consult your PCI expert if considering this strategy.
Also note that it’s important to ensure user IP addresses are propagated through the reverse proxy. If all traffic on proxied paths appears to come from a handful of unrecognized IP addresses, BigCommerce’s DDoS protection measures may flag this as malicious.
For a single-channel strategy, which technique you choose will determine whether you set a sub-domain or your main domain as the checkout URL on your Channel Site.