StoreBuilt reviewed Shopify’s checkout form documentation for this guide. The key distinction is between the customer’s contact method and a phone number attached to a shipping address. They may look like the same business requirement, but they are separate parts of checkout and should be tested separately.
Making a Shopify checkout phone number required can help a UK merchant meet a genuine delivery requirement. It can also add unnecessary friction when nobody uses the number. Before changing the setting, identify who needs the data, for which orders, and where it must arrive after checkout.
Contact StoreBuilt to review the checkout and fulfilment path behind your phone-number requirement.
Table of contents
- Start with the operational reason
- Separate contact method from shipping information
- Understand the shipping-step boundary
- Check product configuration when shipping disappears
- Test the customer paths the store actually offers
- Follow the number into fulfilment
- Keep delivery contact and marketing separate
- An illustrative mixed-catalogue problem
- Measure the result after a controlled release
- StoreBuilt point of view
Start with the operational reason
Ask the fulfilment team what happens when an order has no phone number. Does the carrier reject the booking, does a delivery service need to arrange access, or does support simply prefer another contact option? Those are different levels of need and should not be collapsed into a blanket requirement.
Request evidence from the actual carrier or payment-provider workflow. A historical checklist may reflect a service the business no longer uses. Confirm the current requirement with its owner before making every customer complete another field.
For bulky furniture or appointment-based delivery, contact may be part of the service promise. For an ordinary parcel or digital download, the process may be different. This guide does not set a universal UK policy; it helps the merchant connect a specific operational requirement to the correct checkout behaviour.
Separate contact method from shipping information
Shopify’s checkout form documentation distinguishes the customer contact method from the shipping-address phone field. The contact setting supports email or a choice of phone number and email; it does not provide a single switch requiring both as the contact method.
The shipping phone field is configured separately. If the business needs an email contact and a phone for physical delivery, review both settings and test the resulting journey. Do not assume that selecting one makes the other mandatory in every kind of order.
Keep the brief precise: “Collect an email for the order and a usable phone number for shipments handled by our nominated service.” That is easier to implement and verify than “make phone mandatory everywhere”, especially in a store that also sells non-shippable products.
| Business need | Setting or process to review | Acceptance question |
|---|---|---|
| Email order communication | customer contact method | does the intended email reach the order? |
| Carrier needs delivery phone | shipping phone field | does the shipping address contain it? |
| Digital service needs a callback | separate supported service process | where is the requirement enforced? |
| Marketing messages by SMS | marketing subscription process | is permission recorded independently? |
| Warehouse cannot see the number | integration mapping | which order field is being exported? |
Understand the shipping-step boundary
The current Shopify documentation states that the required shipping phone field is enforced only when the checkout includes a shipping-address step. If the basket contains no items requiring shipping, that step can be skipped. Requiring a shipping phone number does not create a shipping step for a digital-only purchase.
This explains why a configuration can appear to work for a physical item and fail for a gift card or download. The two tests are not equivalent. Before escalating a missing number as a platform defect, record the products in the basket and whether shipping information was requested.
Do not mark a digital product as physical merely to force another field. That can introduce an inappropriate delivery journey and confuse shipping calculations or customer expectations. Define the real service requirement and use a supported collection approach that fits it.
Check product configuration when shipping disappears
When a physical item unexpectedly skips shipping, inspect its shipping configuration and relevant variants. Product imports or bulk changes deserve attention if the problem began after a catalogue update. Use a known-good physical product as a control so the investigation can separate product data from checkout settings.
Record the exact variant used in the test. A merchant may inspect the parent product while the customer purchased a variant with different data. The evidence should connect the basket item to its configured shipping behaviour, rather than relying on the product title alone.
The product CSV update guide is useful when imports are involved. Keep the correction narrow and verify the affected items after saving. A broad catalogue update to fix one variant creates unnecessary opportunities for unrelated mistakes.
Test the customer paths the store actually offers
Build a small matrix covering the store’s real purchase types: physical only, digital only and a mixed basket if all are supported. Add the relevant customer state and payment entry points. The goal is to observe the flow, not to assume every route presents the same screens in the same order.
Test on mobile as well as desktop. Look at the input label, error message and keyboard behaviour. A technically required field can still be confusing if the customer cannot tell why it is needed or whether a recipient’s number is more appropriate than their own.
Use controlled details owned by the business. Do not create orders against real customers merely to inspect data. When a completed test order is necessary to verify fulfilment mapping, use the merchant’s approved test process and keep its operational effects clearly identified.
Follow the number into fulfilment
A value appearing during checkout does not prove that the carrier receives it. Inspect the resulting order and the address field the integration reads. Customer-profile phone, order contact phone and shipping-address phone should not be treated as interchangeable without checking the actual implementation.
Ask the integration owner to document the source field and any transformation. If the warehouse export reads the wrong field, requiring more checkout data may not solve the problem. The fix may belong in the mapping between systems rather than in the customer form.
Check how the receiving system handles international formats, spaces and country codes using the formats your business supports. Do not promise that a number is reachable merely because it passes a form’s validation. Syntactic acceptance and successful customer contact are different outcomes.
Keep delivery contact and marketing separate
An operational number collected for a shipment should not automatically become an SMS marketing subscription. Shopify’s customer contact guidance describes separate subscription controls. Preserve that distinction when moving data into a messaging platform.
This article covers implementation rather than legal advice. Have the person responsible for privacy and marketing approve the actual wording and use of the field. The technical acceptance test should confirm that the chosen subscription state is preserved, not merely that a phone value exists.
Review support scripts too. Staff should understand why the business requests the number and what it will be used for. A consistent explanation reduces confusion and prevents agents from giving promises that the checkout copy or downstream process does not support.
An illustrative mixed-catalogue problem
Imagine a UK home-interiors retailer selling furniture alongside digital gift cards. The team makes the shipping phone field required because furniture deliveries need coordination. A gift-card order still arrives without a shipping phone, and the warehouse team reports that the setting is broken.
The investigation separates the order types. The gift card does not use the same shipping-address journey as the furniture order. The team keeps the furniture acceptance test and defines any separate gift-card contact requirement according to the actual service, instead of forcing a false physical-product setting.
This is an illustrative scenario, not a claimed StoreBuilt client result. Its value is the boundary: checkout requirements should follow the transaction being performed. A single missing field is not enough evidence to conclude that all customers can bypass the same rule.
Measure the result after a controlled release
Track both operational success and customer friction. Useful measures include carrier-booking failures caused by missing data, support requests for contact details and checkout completion for the affected order types. Avoid interpreting a small short-term movement as proof of causation without considering traffic and campaign changes.
| Release check | Evidence | Follow-up if it fails |
|---|---|---|
| Physical order | required field behaves as intended | review settings and product data |
| Digital order | appropriate non-shipping journey | review separate service requirement |
| Mixed basket | expected address collection | inspect each product and route |
| Fulfilment export | number reaches correct destination | inspect integration mapping |
| Marketing state | consent handled independently | correct subscription logic |
| Mobile usability | clear label and recoverable error | revise copy or supported configuration |
Keep the previous configuration in the release note and name the owner of the change. If the operational benefit does not appear, investigate the downstream process before adding further customer requirements. More mandatory fields are not a substitute for correct data handling.
StoreBuilt point of view
A required phone field earns its place when it supports a defined customer service and reaches the team that needs it. StoreBuilt would make the collection scope explicit, test the shipping-step boundary and verify the downstream mapping. The objective is a reliable delivery process with a proportionate checkout experience.
Explore Shopify design and development or Contact StoreBuilt for a checkout and fulfilment integration review.