There is a shop, and it is still on the old checkout. The owner has been told more than once that it is time to move to the WooCommerce block-based checkout. They keep not doing it. Not out of stubbornness: the checkout is where the money is, and nobody wants to be the person who broke it on a Tuesday afternoon.
Somewhere in that checkout are two or three fields that matter. A VAT number. A delivery note. A “how did you hear about us” that marketing asked for in 2021 and still reads every month. Nobody remembers who added them, or how. They are not part of WooCommerce; they are just there, and they have worked for years.
The reasonable question is: if I switch, do those survive?
The honest answer is that they often do not, and the reason isn’t something you will find by digging deeper into your settings.
The two checkouts do not share a field system
This is the part that surprises people, so it is worth being blunt about it.
WooCommerce has two checkouts. The older shortcode checkout, and the newer block-based one. They are not two skins over the same form. They collect their fields in completely different ways, and neither knows about the other’s.
A field added to the shortcode (often called classic) checkout is invisible to the block-based checkout. A field registered for the block-based checkout does not appear on the shortcode one. This isn’t a bug, and it isn’t a setting somebody forgot to turn on. There is no toggle for it, and no amount of looking will find one.
So when a shop switches checkouts, and the VAT number field is simply gone, nothing has broken. The new checkout is doing exactly what it was built to do: it doesn’t know about a field that was never registered with it.
Why does the advice you find not work anymore?
Search for how to add a checkout field to WooCommerce, and you will find a great deal of writing, most of it good, almost all of it about the shortcode checkout.
Those articles are not wrong. They are just about the other checkout. And there is nothing on any of them that says so, because most were written before there was another checkout to distinguish them from.
If you or your developer are writing the code yourselves, we already wrote the one for the block-based checkout: How to ship WooCommerce Blocks checkout fields with your plugin or theme. This post is deliberately not that one, and there is no code anywhere below.
The same is true of snippets already living in your site. A snippet in a child theme, a small plugin someone wrote for you, a hook in functions.php that’s been there so long it’s moved house twice. If it was written for the shortcode checkout, switching checkouts turns it off without a word.
This is the practical trap. You do not get an error. You do not get a warning. You get a checkout that looks fine and quietly stops collecting something you needed.
Where the data actually goes
Fields store values per order and per customer, and the two checkouts don’t necessarily store the same field in the same place.
That matters more than it sounds. Old orders keep their values, so nothing is lost behind you. But new orders may write to somewhere nothing reads, which is a much worse failure than an empty field: the data is being collected and is going nowhere anyone will look.
If something downstream depends on those values, an invoicing plugin, an export, a fulfillment script, a spreadsheet somebody maintains by hand, that is the thing to check before the switch, not after.
What to check before you move
Not glamorous, and the part everybody skips:
List every custom field on your current checkout. Actually look at the checkout; do not work from memory. There is usually one more than anyone remembers.
For each one, find out what put it there. A plugin, a theme, a snippet, an agency. If nobody knows, that is your answer for where the risk is.
Then check whether that thing supports the block-based checkout at all. Not “is it updated”. Not “is it compatible with the latest WooCommerce”. Specifically whether it registers its fields with the block-based checkout, which is a different question and often has a different answer.
Anything that fails that third question needs replacing before you switch, not after somebody notices.
Two things that are not your fault
Even when done properly, WooCommerce itself gets in the way in two places. Both are worth knowing about, because both look like somebody’s mistake and neither is.
A value collected on the shortcode checkout is not shown back to you everywhere. It is on the order. It is stored correctly, under the right key. But WooCommerce reads these values back only for orders its own block-based checkout created, so they don’t appear in order emails or in the customer’s order view under My Account. There is no filter, no argument, no setting.
A workaround is floating around: tell WooCommerce the order came from somewhere it didn’t. It works. We will not ship it, and we suggest you don’t either: it lies to every other piece of code that asks how the order was created, and you will not remember doing it when something else starts behaving strangely a year from now. We reported it instead.
The second one is worse, and it is easier to hit. WooCommerce wraps the entire “Additional information” area of the shortcode checkout in the “Enable order notes” setting. Turn order notes off on a completely different settings screen, and every other field in that area disappears with it. Not just the notes box. Every field.
Worse, the fields are still validated. So a required field that is no longer on the page still has to be filled in, and the customer gets told that a field they cannot see is required, with no way past it. The checkout simply cannot be completed.
Nobody would guess that a setting called “Enable order notes” on a screen about products. We reported this one too, then wrote the fix and sent it to WooCommerce, because it affects every plugin that adds a field there, not only ours.
Where doing it by hand stops paying
None of this argues against writing the field yourself. One field, one checkout, a developer who knows the site: that is half an hour, and buying something for it would be silly.
It stops being half an hour somewhere around here. Half a dozen fields. Fields that should only appear sometimes, depending on the country or what is in the cart. Core address fields you also want to rename, remove, or reorder. A client who needs to see and change the setup without reading code. And fifteen sites that all have to stay in step.
At that point you are not writing a field anymore. You are maintaining a small system, on the most sensitive page of the shop, in two different checkouts.
The other way
This is where our own plugin comes in, so take the next few paragraphs accordingly.
Simple Checkout Fields Manager for WooCommerce adds text, select, and checkbox fields to all three sections of the checkout: Contact information, Address, and Additional information, with no code. Those fields work on both checkouts and are stored the same way on both, so an order looks the same no matter which checkout took it. Nothing to redo when you switch, and nothing left behind.
The same is true of WooCommerce’s own address fields. Rename them, reorder them, resize them, remove them, make them required or optional, and it applies on both checkouts and in My Account.
The limits, in the same breath, because you should know them before you buy and not after:
“Additional information” fields on the shortcode checkout need one setting turned on in the plugin, for the WooCommerce reason described further up. The plugin ships the corrected template and tells you on its own settings page when it applies to you. “Select with fee per option” fields work only on the block-based checkout, because the fee is applied from the cart. Conditional rules, which show or require a field depending on the cart or on what has already been filled in, are block-based checkout only for now, because the shortcode checkout has no way to evaluate them as the customer types.
One paragraph for whoever reads these values from somewhere else, because it is worth real money and has no other obvious home: the value lands under the same key whichever checkout took the order. An integration, an export, an invoicing plugin, or a fulfillment script never has to know which checkout the customer used, and nothing has to be rewritten when the shop switches.
Also new in our 9.0 release
Core fields fully supported on the shortcode checkout and in My Account, a different name for a field on the billing and on the shipping address, field width, autofill, your own data- attributes, an orders list column for any field, and wider WPML coverage.
And if you do not need any of this
If you have one checkout field and one shop, register it in PHP and move on. Our guide to doing exactly that will save you the research. You don’t need a plugin, and anyone who tells you otherwise is selling something.
The case for buying is narrower and more specific: you have more than a couple of fields, someone who isn’t a developer has to manage them, or you are moving between checkouts and would rather not find out the hard way which of your fields survives the trip.
