Every BigCommerce store runs on the same Optimized One-Page Checkout by default, a single-page flow BigCommerce hosts and maintains itself, customizable through injected scripts and the Checkout.js SDK for branding and minor behavior changes. Capturing a genuinely new field, and getting its value to reach anything beyond the order record, requires building against BigCommerce's Checkout API directly. There's no plugin marketplace shortcut the way there is on a self-hosted platform.
Every store, regardless of plan, runs the same Optimized One-Page Checkout, a single-page flow combining shipping, billing, and payment into one screen rather than BigCommerce's older multi-step layout. BigCommerce hosts and maintains that checkout directly, which means consistent performance and PCI compliance, but also means there's no theme-level checkout template to edit the way there is on the rest of the storefront.
Customization at this layer happens through Checkout.js, BigCommerce's SDK for injecting custom scripts and styling into the hosted checkout page, letting a business adjust branding or light behavior without replacing the checkout entirely. It's meant for cosmetic and minor functional tweaks, not for fundamentally restructuring what the checkout captures.
Capturing something genuinely new, a delivery note, a tax-exemption ID, a custom gift message, and getting it to show up anywhere beyond the order record means building against BigCommerce's Checkout API directly, either customizing the hosted checkout's behavior through the SDK or building a fully custom checkout experience from scratch. WooCommerce's plugin-based field editors don't have an equivalent here, since BigCommerce's hosted checkout isn't designed to be casually extended the way a WordPress plugin extends a self-hosted site.
That's a real, meaningful platform difference worth knowing before choosing between the two for a business with specific checkout requirements: BigCommerce's checkout is more consistent and less fragile by default, but customizing it past branding is a development project, not a plugin install.
A delivery note or gift message captured through the Checkout API lands directly in the system your warehouse or fulfillment team works from, instead of sitting unused in the order record because nothing's built to route it anywhere.
A business tax ID collected at checkout flags the order correctly in your accounting system automatically, so a wholesale or exempt order doesn't need someone manually re-checking it against a list after the fact.
A custom field, a conditional rule, a value that needs to reach another system: tell us what it is, and we'll scope what building it against the Checkout API would take.
There's no plugin market to browse for this the way there is on other platforms. Getting a custom field into BigCommerce's checkout, and getting its value to actually do something once captured, is a direct build against the Checkout API. Checkout is just this page's example; n-frames takes on that kind of platform-specific engineering wherever a business needs something a prebuilt setting or app can't cover.
Let's talk →Within limits. Branding, styling, and minor behavior changes are possible through Checkout.js and the hosted checkout's built-in customization options. A fundamentally different checkout structure, or capturing entirely new data, requires building against the Checkout API directly rather than a settings change.
The default checkout experience on every BigCommerce store: shipping, billing, and payment combined into a single page rather than separate steps, hosted and maintained directly by BigCommerce.
Yes. Adding a genuinely new field and getting its value to reach another system requires building against BigCommerce's Checkout API; there's no settings panel or app install that does this the way field-editor plugins work on other platforms.
Not in the same sense. BigCommerce's hosted checkout isn't built to be extended by installable plugins the way a self-hosted WooCommerce site is; customization past branding goes through direct development against BigCommerce's own Checkout API and SDK instead.