A merchant's notes on rebuilding checkout with the Checkout SDK, handling three buyer flows on one page, and what the rebuild measurably did for our cart abandonment.
Our default Optimized One-Page Checkout was costing us money. Cart abandonment sat at 71%. The B2B segment was worse, at 78%. We knew the checkout was the problem because the drop-off pattern in GA4 was concentrated at the payment step, not at shipping or address entry. The fix turned out to be the BigCommerce Checkout SDK, and the rebuild took us from 71% to 58% sitewide and from 78% to 51% on the B2B segment.
This is the technical writeup of how the Checkout SDK works, what we built, and what the lift actually was. It is detailed enough that another merchant or a developer scoping a project should be able to estimate timelines from it.
The Checkout SDK is a JavaScript library that wraps the Storefront Checkout API. The Storefront Checkout API is the same API that powers the native BigCommerce checkout page. So a custom checkout built on the SDK is not running on a separate codepath. It is calling the same backend that the default checkout calls, just with a UI you control.
This matters because it means new payment gateways and checkout features that BigCommerce ships get added to the SDK automatically. You do not have to rebuild or maintain a separate payment integration layer when, for example, BigCommerce adds support for a new buy-now-pay-later provider. The SDK handles it.
The package is published as @bigcommerce/checkout-sdk on npm. You install it like any other npm package, then create a CheckoutService instance to interact with the checkout state:
import { createCheckoutService } from '@bigcommerce/checkout-sdk';
const service = createCheckoutService();
const state = await service.loadCheckout(checkoutId);From there, every checkout action (load shipping options, apply a coupon, select a payment method, complete the order) is a method call on the service. The SDK manages the underlying API calls, error handling, and state management.
We had three distinct buyer flows trying to share one checkout page.
The default checkout could not handle this with its standard configuration. Trying to bolt the B2B fields onto the default UI with apps and theme overrides created a checkout that looked busy for retail buyers and missed fields for B2B buyers. The right answer was a custom UI that conditionally rendered fields based on the customer group.
The custom checkout is built in React on top of the Checkout SDK. The high-level architecture:
Build time: about three weeks for our in-house developer. The SDK has thorough documentation and the GitHub repository has working examples that cut the learning curve significantly.
The hardest piece was the payment method conditional logic. Net-30 customers should not see credit card fields by default because we do not want them to accidentally double-pay. But they should be able to opt in to credit card if they want to (some prefer to pay by card to earn points).
We solved this by querying the customer's group on checkout load, hiding the credit card option in the default render, then exposing a small "pay by card instead" link that swaps in the credit card form. Implementation was about 80 lines of React. The SDK does the heavy lifting on the actual payment method instantiation.
We do not run a headless storefront, but it is worth knowing the option exists. Embedded Checkout is a version of the Optimized One-Page Checkout that can be iframed into an external site (like a CMS-based content site). Shoppers complete their purchase in-context without being redirected to the BigCommerce domain.
If you are building a content-led storefront on WordPress or a static site generator and want to keep customers on your domain through checkout, Embedded Checkout is the path. Same Checkout SDK underneath, different deployment target.
The conversion impact, measured 90 days after launch versus 90 days before:
The B2B numbers moved most because the default checkout's biggest failure was confusing B2B buyers. They expected fields that were not there (PO number, net-30 option) and were forced to use a payment flow that did not match their workflow. Once the custom checkout matched their expectations, the conversion came back fast.
The Checkout SDK rebuild was one of five customizations we have done over the last 14 months. The full list is in our customization roundup with conversion data. The B2B-specific configuration that pairs with this checkout work lives in our B2B pricing tier setup writeup.
For the full SDK reference and code examples, the official BigCommerce Checkout SDK documentation is the resource we use most. The GitHub repository has working sample implementations in vanilla JavaScript and React that are worth cloning to play with before you commit to a build approach.
Yes. The BigCommerce Checkout SDK lets you replace the default checkout UI with a custom one while keeping the underlying payment infrastructure. You can use React, Vue, or vanilla JavaScript. The SDK calls the Storefront Checkout API, the same API that powers the native checkout page.
No. All new BigCommerce checkout features and payment gateways are added to the SDK, so a custom checkout built on the SDK keeps current with new payment methods as they are added. You do not maintain a separate payment integration layer.
Optimized One-Page Checkout is the native checkout that BigCommerce ships with the storefront. Embedded Checkout is a version of that same checkout that can be iframed into an external site, useful for headless storefronts on a different domain. Both are built on the same Storefront Checkout API.