The Baymard Institute's multi-decade research puts average checkout abandonment at roughly 70 percent across ecommerce, with an estimated $260 billion in annual recovery opportunity across the US and EU. BigCommerce's own checkout article flags that the average checkout requires 5.1 steps and 11.3 form fields according to aggregated Baymard data, and that 63 percent of shoppers abandon if no guest checkout option is offered. Those numbers frame the optimization problem but they do not settle it. What actually moves conversion on a BigCommerce store is platform-specific: the behavior of the Optimized One-Page Checkout, the CORS boundary of the Checkout SDK, the payment method mix, and the theme-level constraints that determine how much of the flow can be customized at all.
This guide starts from the platform reality and works outward. The Stencil and Catalyst article covers the architecture context, and the main guide connects checkout to broader BigCommerce development decisions. Baymard's public research is available at baymard.com.
Where abandonment actually comes from
Four categories cover roughly 80 percent of abandonment on a BigCommerce store. Unexpected cost (shipping, taxes, fees) at checkout is the largest single category. Required account creation is the second. A complex or slow checkout flow is the third. Payment method friction (preferred method not available, card declined without clear messaging) is the fourth. Baymard research also flags that 25 percent of shoppers abandoned checkout in the past three months for trust-related reasons, and 22 percent abandoned for a checkout they considered too complex.
The platform-specific angle is that BigCommerce's Optimized One-Page Checkout addresses three of those four categories out of the box: shipping is calculated early, guest checkout is available, and the flow is compressed onto a single page rather than a multi-step wizard. The fourth category, payment method friction, is a configuration decision the merchant controls. A store that offers only a credit card field in 2026 leaves conversion on the table. Digital wallets (Apple Pay, Google Pay, Shop Pay if available), Buy Now Pay Later options (Affirm, Afterpay, Klarna), and PayPal One Touch have all shown measurable conversion lift in industry data.
Optimized One-Page Checkout in detail
Optimized One-Page Checkout is BigCommerce's hosted reference checkout experience. It ships on every new store and is the default on Stencil themes. A 2026 platform update reduced the cart-to-checkout transition, delivering first interactivity roughly one second faster than the prior behavior, with no merchant configuration required. That one second matters because the seconds immediately after cart-to-checkout are where a meaningful share of rage-abandonment happens.
The checkout supports guest and account flows, auto-applied customer-group pricing, tax calculation, multiple shipping methods, and the full payment method set configured in the store. Customization at the theme level is limited to cosmetic changes: brand colors, fonts, logo placement, and text on buttons. Layout and flow changes go through the Checkout SDK rather than through theme templates.
Performance of OOPC on typical Stencil deployments sits in the 75 to 90 Lighthouse mobile range out of the box. Most of the performance surface has already been optimized by the platform team. Merchants who see lower numbers typically have third-party scripts loading during checkout (analytics, chat, reviews) that they can deprecate without losing business value. A 10-point Lighthouse improvement is often a matter of removing one chatty third-party script.
The Checkout SDK and its CORS boundary
The @bigcommerce/checkout-sdk npm package (version 1.904.2 at the time of writing) is the JavaScript library that drives checkout customization. It exposes modules for checkout, checkout-button, and embedded-checkout, and supports payment methods including PayPal, Braintree, Square, Amazon Pay, Klarna, and Afterpay. The SDK is framework-agnostic and can be used with any JavaScript stack. It is also available through a CDN loader at checkout-sdk.bigcommerce.com/v1/loader.js for direct browser use without a build step.
The constraint that shapes every customization project is CORS. The BigCommerce storefront web APIs do not currently support cross-origin requests, which means the SDK has to run on the same origin as the storefront. For a Stencil store, that is straightforward. For a headless Catalyst storefront, the common pattern is to keep the native OOPC and embed it into the Catalyst frontend using the embedded-checkout submodule rather than rebuilding the flow. For a fully custom checkout on a separate origin, the path is to proxy the Storefront Checkout API through a server that runs in the same domain context as the storefront, which is non-trivial ongoing work.
On Stencil themes, the SDK readme notes that Optimized One-Page Checkout must be enabled in the store for local preview of SDK customizations to work correctly. Teams that try to develop against the legacy multi-step checkout first and migrate later lose time twice. Enable OOPC at the start of the project.
Payment gateway impact on conversion
Payment method choice is the single most underrated conversion lever on BigCommerce stores. The store behind the gateway does not matter as much as whether the shopper's preferred method is available at the moment of purchase. Five methods cover over 90 percent of US and EU checkout preference: credit card, PayPal, Apple Pay, Google Pay, and Buy Now Pay Later. A checkout that offers all five typically sees a 3 to 7 percent conversion lift against a credit-card-only checkout.
The trade on payment methods is processing fees. Standard US credit card processing runs 2.6 to 2.9 percent plus a fixed fee per transaction. PayPal runs 3.49 percent plus fixed for the standard processing tier. Apple Pay and Google Pay add no fee beyond the underlying card processor. Buy Now Pay Later providers typically charge 4 to 6 percent to the merchant but take the credit risk off the store. The conversion lift usually justifies the fee spread on stores with average order value above $75, where abandoned carts cost meaningful revenue per unit.
A meaningful second-order effect is that digital wallets compress checkout to an authenticated touch on mobile. Apple Pay and Google Pay skip the address entry, card entry, and billing entry fields entirely. On mobile, where checkouts abandon most, that compression is worth real conversion points.
Shipping calculator placement
Two shipping calculator patterns show up across BigCommerce stores. The first puts the calculator on the cart page, letting shoppers see estimated shipping before they enter checkout. The second surfaces shipping only at checkout, after the shipping address is entered. The first pattern reduces abandonment caused by unexpected shipping cost. The second pattern reduces friction on the cart page but raises abandonment at checkout.
The tradeoff depends on shipping cost variability. A store with flat-rate shipping (or free shipping over a threshold) benefits from on-cart display because the message is reassuring. A store with real-time carrier rates that vary by weight, destination, and service level benefits less, because a pre-checkout rate is either an approximation (which irritates shoppers whose real rate differs) or a delay (which cancels out the benefit). The honest pattern for stores with carrier-rate complexity is a simple threshold statement on cart ("Free shipping on orders over $75") rather than a live calculator.
Stencil theme checkout constraints
Stencil themes cannot rewrite the checkout layout at the template level. The OOPC is served from the platform and customization flows through the Checkout SDK or through the limited theme-level cosmetic settings. Teams used to working on Shopify Plus, where checkout.liquid gave extensive template-level customization until Shopify deprecated it in favor of Checkout Extensibility, sometimes discover this constraint late in a BigCommerce project and lose a sprint to rescoping.
What a Stencil theme can do inside the checkout is limited to button text changes, trust messaging adjustments, and the cosmetic brand layer. Bigger changes require the SDK. Form field additions (a PO number field for B2B, a loyalty ID entry, a gift message field) go through the SDK's custom field extension pattern rather than through template changes. The practical effect is that a "simple" B2B checkout customization is a 40 to 80 hour engineering engagement rather than a theme tweak.
A/B testing the BigCommerce checkout
A/B testing checkout on BigCommerce requires traffic split at the checkout entry point rather than at the cart or product page. The right tools are Google Optimize (deprecated in 2023) successors like VWO, Optimizely, or a simple custom split via a Cloudflare Worker. The test harness has to preserve the cart state across the split, which means cookie-based session affinity to keep the shopper on the assigned variant through checkout completion.
Meaningful tests usually target one of four variables: the headline messaging on the checkout, the payment method ordering and visibility, the presence or absence of upsell modules, and the copy on the primary CTA button. Small tests in each category routinely show 1 to 3 percent conversion deltas, which compound meaningfully on a store doing over $5 million in annual revenue. Larger tests that restructure the flow (for example, collapsing optional fields or reordering shipping and payment steps) are harder to run because the OOPC template shape is constrained by the platform.