Redirected Checkout

Plan: Composable Developer

Lesson 19 of 27 · 30 min

The Benefits of Redirected Checkout

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:

  • Checkout interactions are often among the most complex a storefront must deal with, and a ready-made checkout UI alleviates the development cost of building one from scratch. If the BigCommerce checkout meets most of your needs, this is often the quickest route to launching a fully functioning store.
  • If you redirect to BigCommerce’s default Optimized One-Page Checkout, payment details are never handled or transmitted by your own app. Instead they are being handled solely by BigCommerce, meaning that there are fewer PCI DSS compliance implications for you.
  • You can use Redirected Checkout without giving up the flexibility of customizing the checkout UI. Customized checkout can be accomplished using the same tools and techniques that work on a BigCommerce storefront.

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.

Redirected Checkout and Stencil

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 main “frame” of the page, including the header and store logo, is served like any other storefront page using Stencil templates.
  • The main interface is a React-based UI loaded from a separate source - either the default BigCommerce checkout or from an alternate JS loader configured in your store.

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:

  • Store links in the checkout, such as the home link in the store main logo, will be generated using the base URL of the checkout channel. You may wish to remove any such links or update their targets, which you can do by customizing the appropriate template in Stencil.
  • The order confirmation page users are redirected to after completing checkout will likewise use the checkout channel’s base URL. To redirect back to the proper storefront, you will need to customize the logic in the checkout JS.

The Redirect Process

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.

mutation CartRedirectMutation($cartId: String!) {
cart {
createCartRedirectUrls(input: {cartEntityId: $cartId}) {
redirectUrls {
redirectedCheckoutUrl
}
}
}
}

Resources