Redirected Checkout refers to a strategy in which the headless storefront redirects the user to a BigCommerce storefront for completion of their order. The key checkout interactions - collecting billing and shipping information and processing payment - occur on a front-end served directly by BigCommerce rather than on your custom storefront.
Provided that you’re using a payment processor supported by BigCommerce and that your general checkout data flow matches up well with the BigCommerce model, Redirected Checkout is often a good choice for a few reasons:
As always where PCI compliance is concerned, you should consult with your own PCI expert on the details of your implementation!
As Redirected Checkout is the most straightforward option for checkout on a composable storefront, it’s the strategy our in-depth exploration will focus on in this intermediate course.
When redirecting to a BigCommerce storefront, the checkout is served using the Stencil theme applied to that storefront, just like any other page would be.
If you’re not familiar with Stencil themes, note that typically the checkout UI involves two major components:
The general look and feel of your checkout, therefore, is determined by the Stencil theme applied to the channel where checkout occurs.
If you have created a custom Stencil theme to update the styles and formatting of checkout, you must set this theme on the appropriate channel, which can typically be done in the Storefront or Channel Manager section of your store control panel. If you’re using a single-channel strategy with redirected checkout, however, you will find that you not able to set a different theme on a channel with the “headless” type from within the control panel. But a theme can still be set using the BigCommerce API.
See the API reference for the Activate a Theme endpoint. Note that the supported request parameters for this endpoint actually do include channel id_to activate a theme on a specific channel.
If you’re using a multi-channel strategy- redirecting to a different channel for checkout than the one associated with your headless storefront - there are some additional challenges to consider about the relationship between the two storefronts:
Redirecting a user to a particular URL for checkout is, of course, fairly trivial. The key added requirement we have in our scenario, however, is to load the cart that was created in a headless storefront into the BigCommerce storefront’s own session.
The cart.createCartRedirectUrls GraphQL mutation will enable you to do exactly that. This mutation expects the ID of an existing cart and returns single-use URLs that will load the matching cart data into a user’s session before redirecting them again.