A meaningful share of shoppers in Bangladesh have no email address they actually read. Asking for one at checkout costs orders outright, and the orders that survive often arrive with an address invented on the spot to get past the field.
Why you cannot simply delete the field
Billing email is load-bearing. Order confirmations, guest order lookup, receipts and a long tail of plugins all assume it exists and is unique. Remove it from the form and orders start failing in places unrelated to checkout, usually days later and usually in a report someone else runs.
Derive it instead of demanding it
The field comes off the form entirely. Then, at the moment WooCommerce builds the order object — after its own validation has finished, before the order is saved — an empty billing email is filled in from the digits of the customer’s phone number at the store’s own domain. If even the phone is missing, the order ID provides the uniqueness instead.
Every order ends up with a syntactically valid, unique address. Nothing downstream breaks. And because the domain is the store’s own, no message is ever delivered to a stranger who happens to own that mailbox elsewhere.
The phone number becomes the identity
Once email is derived rather than entered, the phone number is the field that identifies a customer — which makes its formatting suddenly important. The same person typing an international prefix on one order and a local zero on the next would otherwise become two customers. Normalising to a single local form at the point the order is created keeps one customer as one customer.
Two things worth being careful about
Derived addresses must never enter a marketing list; they are placeholders, not contacts. And the domain used must be one the store controls, so that mail sent to these addresses stays inside the store’s own infrastructure rather than bouncing off somebody else’s server.
Key takeaways
- Required fields that do not match how customers actually live produce fake data, not better data.
- Do not delete a load-bearing field — satisfy it another way.
- Fill derived values when the order object is built, after validation and before saving.
- If email stops being the identifier, whatever replaces it needs consistent formatting.
Related reading: validating mobile numbers at checkout, manual mobile-money payments.
Running into a similar limitation in your own WooCommerce or WordPress store? Let’s Talk — ArtinTech Solution builds exactly this kind of custom store tooling.