WooCommerce's checkout fields can be hidden, reordered, marked required, or added to entirely through built-in settings and a wide field-editor plugin market, with the block-based checkout introduced in recent WooCommerce versions making most of that configurable without touching code. What those tools don't do is get a custom field's data anywhere beyond the order record it's attached to. That part is what we build.
Standard fields, name, address, phone, company, can be shown, hidden, reordered, or made optional through WooCommerce's own checkout settings, no plugin required for that layer. Since WooCommerce 8.3, the default checkout runs on a block-based editor built with the same tools as the rest of a WordPress page, which makes rearranging and restyling the layout itself a drag-and-drop job rather than a code edit.
Adding a genuinely new field, a delivery note, a VAT number, a gift message, is where a field-editor plugin usually comes in, letting you define the field, its type, and whether it's required, without writing a `woocommerce_checkout_fields` filter by hand. One-page checkout plugins go further, collapsing the whole multi-step flow into a single page for stores that want fewer clicks between cart and payment.
A field-editor plugin saves whatever you type into a custom field as order meta, visible on the order detail screen in the admin. It doesn't know that a delivery instruction needs to reach a fulfillment system, or that a VAT number on a B2B order needs to change how that order's taxed in your accounting software. The field exists; getting its value to do something useful outside WooCommerce is a separate piece of work entirely.
The same gap shows up with conditional logic that goes past what a field editor's UI supports: showing a business-license field only for wholesale accounts, or routing an order to a different fulfillment process based on an answer at checkout. Most checkout plugins can show or hide a field based on a simple condition, but deciding what happens next, in a different system, based on that answer, is custom integration work.
A delivery instruction or gift message typed at checkout lands directly on the packing slip or fulfillment system your warehouse already uses, instead of staying buried in the order's custom-fields tab where only someone who thinks to look will ever see it.
A tax-exemption or VAT number entered at checkout flags the order correctly in your accounting system automatically, so finance isn't manually re-checking every wholesale order against a spreadsheet of exempt accounts.
If it's sitting in order meta and nobody's acting on it consistently, tell us what it's supposed to trigger, and we'll scope what connecting it for real would take.
A field editor plugin can capture almost anything you want at checkout. Getting that answer to actually change what happens next, in fulfillment, in accounting, wherever it needs to land, is a different job, and it's the one that usually doesn't get built. Checkout fields are just this page's example; n-frames connects whatever data point in your business is currently captured but not acted on.
Let's talk →Yes, through WooCommerce's own checkout settings you can hide, reorder, or make optional most of the default fields, like company name or a second address line, without a plugin. Removing a field entirely from the data WooCommerce stores on the order usually does need a small code change or a field-editor plugin.
A checkout layout that collapses the usual multi-step flow, cart review, shipping, payment, into a single page, usually added through a dedicated plugin rather than a native setting. It tends to reduce clicks between adding to cart and completing an order, which some stores see as worth the layout change.
Not strictly. WooCommerce supports adding fields through a code filter if you're comfortable writing it. For most stores, a field-editor plugin is faster and doesn't require touching the theme's code directly, which matters if whoever set up the site originally isn't available to maintain custom code.
Mostly, yes, since the block-based checkout and most field-editor plugins are built to coexist with popular page builders. Where it gets fragile is when a page builder's own checkout template conflicts with a field-editor plugin's assumptions about where fields render, which is worth testing on a staging copy before changing anything on a live store.