Optional checkout answers vanished on express orders

First distinguish an absent opportunity from a lost value

Compare existing ordinary and express orders for the same field identifier. Record whether the express entry point is known from legitimate store records or the buyer's report. If it is unknown, leave it unknown; an express payment method alone does not prove the buyer started on the product page rather than the checkout page.

Trace three separate facts: whether the field was displayed, whether a value was entered and whether that value was saved to the order. A blank order field cannot answer all three. On a path that never displayed the field, the buyer had no opportunity to supply the answer. On a path that did display it, a blank can be a deliberate omission, an unconfirmed submission or a persistence problem. Keep those explanations separate until the evidence distinguishes them.

The registration method defines the supported path

For fields registered with woocommerce_register_additional_checkout_field, the extension documents display on the blocks checkout page. Express checkout from that page collects entered values and saves them to the order. From product or cart pages, those fields are not displayed and are sent empty. If they are required, WooCommerce refuses the payment; an optional field lacks that required-value check.

For fields added through the woocommerce_checkout_fields filter, the documented form is the shortcode checkout page. Entered values are saved to the order as custom fields keyed by the field ID. The fields are not shown on product or cart pages, and required ones block those express paths. This distinction matters when the visible label exists in several forms or an extension has changed the field identifier.

Identify the extension or customization that registers your field, the checkout type and the installed versions. The documentation does not establish that every custom field from every plugin follows these paths. A value visibly entered on the supported checkout page but absent from the saved order calls for investigation of that exact field and its handling; product-page omission does not explain it. Existing customizations can also matter: disabling the documented classic-field handling prevents those values from being saved to express orders.

Make the information requirement explicit

Ask the person who uses the answer what happens when it is absent. If the store can process an order without it and its customer-facing wording leaves it optional, the merchant may accept that product/cart express orders have no answer. Record that coverage limit in the internal process so a blank is not later interpreted as the buyer declining a choice or making an acknowledgment.

If the information is actually necessary before the order can proceed, that is a requirements decision, not merely a missing-data repair. Agree who owns that decision and how a supported checkout path will present, validate and save the field. The extension allows button locations to be configured, so evaluating a checkout-page collection path can be more relevant than changing an optional flag while leaving the field absent on product and cart pages.

Do not enable required status as a silent fix. Required additional fields on those earlier express paths can cause rejection after the shopper approves the wallet sheet. Nor should the team insert a default answer or copy an old order's answer into the new one. Such a value would not establish what this buyer supplied for this order.

Agree on observable coverage before implementation

Write the accepted behavior for each enabled entry point: the field is presented and entered values are saved, or omission is intentionally allowed. If a necessary field cannot be collected on a proposed path, that path has an unresolved requirement. A successful payment alone cannot close it. For older orders with a blank field, retain that gap; any later authorized collection should remain identifiable as later information rather than an answer supposedly given at checkout.

Use the coverage sheet to scope a Prism checkout consultation with the field identifier, its optional or required setting, checkout type and affected locations. Keep actual customer answers in the store's authorized records. Agree which maintainer will make any change and what rendered behavior and saved-order evidence will establish completion. Scope, responsibilities, fees and terms are confirmed before work begins.

Entry-point data coverage

Complete for one real field across each enabled express entry point. Repeat the comparison in your internal records for other fields. Record shown/not shown, collected/not established and saved/not saved rather than customer answers. Unknown entry points remain unknown.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.