RFC: Editing/Removing Checkout core fields

[senadir]

As we're gearing up our effort to add the ability to introduce additional fields in Checkout [discussion, tracker issue], we also want to understand your needs for removing or editing fields in Checkout.

In this case, we're looking for feedback from 3 groups of people:

• Payment and Shipping methods developers.
• Extension developers.
• Store owners/customization developers.

When we say core fields, we mean the following set of fields:

• First name.
• Last name.
• Address.
• Address 2.
• Company.
• Country.
• State.
• City.
• Zip code.
• Phone.
• Email.

Fields labels, position, requirement, and visibility is controlled on a default set, and overridden on a country by country basis. For example, this is the menu for US vs Japan vs United Kingdom:

When we say edit, it means either changing label, position or requirement. When we say remove, it means taking this field out of the flow completely, it will not be shown to the shopper.

Questions

We would like to understand the following:

• Are you trying to remove/edit core fields globally, or on a country per country basis.
  • If so, please tell us which field?, and why you need to delete/modify the field?
• As a payment/shipping method, do you require certain fields to function? if so, please tell us which fields?
• Do you need to remove a shipping field, a billing field, or both?

[NTShop]

I've seen some sites that remove the email field because they don't need it, and in some of those cases their customers don't have email addresses. This can be because of the older age of the customers, or their medical condition, or nature of the site itself, etc. In other cases WC is used internal to the company (non-public site) for various purposes (ordering things for various departments or locations, etc) so they might remove various fields, add new fields, and so on.

I think the flexibility should be as it is now with the shortcode, where you can add or remove or rearrange any fields that the site operators want to using custom code or a plugin built for that purpose.

Regarding shipping methods I use, all of them require a country, state/province (if available), and post code to get rates from a shipper's API.

Regarding payment, a complete billing address is most often required for most card processing due to "address validation" (AVS) performed by various card issuers.

[pmcpinto]

Thanks for the feedback.

I've seen some sites that remove the email field because they don't need it, and in some of those cases their customers don't have email addresses. This can be because of the older age of the customers, or their medical condition, or nature of the site itself, etc.

How do merchants get in touch with customers in this situation? Do they have the phone as a required field?

[NTShop]

The customers are known to the shop owner and on an internal list at the company already. In one example it be could via an arrangement with another business, such as various senior living centers and the business running the store has a contract with those centers to provide various items ordered on the site. In another situation it might be a manufacturer who calls the custom when the parts that have been ordered are ready for pickup. So yes, sometimes there is no email and no phone required, other times only phone is required.

[pinalj]

I'm an extension developer and I need to remove address fields from the billing/shipping blocks. This plugin allows WC store owners to convert their stores into a quote only store. It modifies the Place Order button at Checkout to 'Request Quote' button & does not take any payment at Checkout.

Later on, the store owner can send a quote email to the customer with a payment link thereby making the order a part of the normal WC Order cycle. Some store owners prefer to allow the users to place a quote request with only basic information such as first name, last name, email address and phone number.

For this use case, I need to hide the address fields, state/province, country etc. I can do this easily using hooks in the Checkout page created using shortcodes. I'd like to achieve the same with blocks as well.

[MichaelBengtsson]

This sounds really good! As a payment and shipping method plugin developer mainly in the Nordics, a lot of our integrations are iframes and web components that want to replace parts of (or the entire) checkout. For example, Klarna Checkout, Payson Checkout and Nets Easy. The main struggle we have had with making support for the Checkout blocks is that there is no good way for us to use the existing blocks and replace the existing fields with the iframe or web component from the payment provider. And the best solution we have come up with so far is that we have to hide or remove the input fields in the frontend with JavaScript/CSS. The proposal here would make that much more stable, and consistent, and would not require us to take what themes or other plugins might do as well with the same elements.

For our use cases with payment plugins, we would need to be able to remove both shipping and billing fields, potentially all of them. Ideally, we would want to keep any custom fields that are added using other plugins, since they might not be supported by the payment provider themselves.
It would also be good if the Shipping and Billing address sections themselves did not render at all if no fields are inside them.

For the shipping plugins, almost all of them require an input of country and postcode at a minimum. But some might also need extra address data such as city and address lines for things like home delivery, or to be able to locate a pickup point agent. However, some of our shipping plugins also have a widget that would have their own input fields that could replace the existing fields in the WooCommerce block.

One question though, if these fields are removed by us, but we still want to maintain good support with other 3rd party plugins, would the payment method/shipping method plugin be able to integrate well directly in the frontend? Or would we need to make updates to the cart using the store API directly?
I'm wondering this since, at the moment, I believe a payment method cannot, with the provided properties from WooCommerce, update the shipping address data directly.

[helgatheviking]

I have a small plugin that eliminates the address fields if the cart total is $0.

[senadir]

Nice! So you would only collect email and first/last name?

[helgatheviking]

@senadir Yes... For free stuff that's not shipped you don't need any more than that.

[zarankumar]

One of our plugins, available at this link, assists customers in retrieving their current address from the map and automatically populating the address field. Essentially, it functions as a reverse geocoding plugin.

We categorize the following fields as more pertinent to contact details rather than the address:

1. First name
2. Last name
3. Phone
4. Email

On the checkout page, we conceal the following fields and fetch the data from the Google API, mapping it to the corresponding fields:

1. Address
2. Address 2
3. Company
4. Country
5. State
6. City
7. Zip code

This process applies to both billing and shipping addresses.

For a quick demonstration, you can check out our premium demo here.

[senadir]

Thanks! Can you understand why you need to hide it? Wouldn't it make sense to prefill it and let customers edit a value if needed? This is the route we will take with Google address autocomplete.

[daotw]

It doesn't hurt to see what big brands do. For example, this is from Nike.com USA:

Notice Nike USA doesn't show billing address (maybe on the final step it does).

I build website for Taiwan sellers (sell to Taiwan buyers). Billing address is a foreign concept here, I wish to have an option to remove all components associated with billing address, which I can't at this time.

Also, I wish to remove State/County field because it's not applicable to Taiwan.

Typo in doc

Payment Method Integration for the Checkout Block:

It's been a while but nobody corrected this typo.

The biggest Taiwan payment processor (ecpay.com.tw) told me they can't integrate checkout block at this time. I wonder if "not able to integrate" is a global issue or an edge case of mine? Thanks.

[senadir]

I build website for Taiwan sellers (sell to Taiwan buyers). Billing address is a foreign concept here, I wish to have an option to remove all components associated with billing address, which I can't at this time.

We're looking to de-emphasize billing more, but for you, you can force billing to shipping using this option Shipping Options

It should show Checkout like this

And then you can just rename the step title to whatever you want.

Also, I wish to remove State/County field because it's not applicable to Taiwan.

You can remove that using locale data.

add_filter('woocommerce_get_country_locale', function( $locale ) {
		$locale['TW']['state']['required'] = false;
		$locale['TW']['state']['hidden'] = true;
		return $locale;
});

It's been a while but nobody corrected this typo.

Thanks for reporting, feel free to fix it directly next time, for now I will fix it :D

The biggest Taiwan payment processor (ecpay.com.tw) told me they can't integrate checkout block at this time. I wonder if "not able to integrate" is a global issue or an edge case of mine? Thanks.

It would be nice to understand their limitations, they can you refer them to create an issue?

[gggeek]

Quite a specialized corner case, but here you go:

• the good sold is a service, delivered (as either subscription or one-shot) to canal boats
• the core address fields for billing are ok - they are used for billing
• shipping is completely disabled (hidden everywhere)
• custom fields are in use to allow customers to input their boat's location via what3words addresses, as well as other boat details (name, number, description)

Atm the system more or less works, but there is a bit of mismatch - in the end it would probably be better if we could drop all existing "shipping address" fields and replace them with the custom fields.

We still would have a problem for users trying to place an order with multiple subs for multiple boats though, as shipping/custom fields are all per-order, whereas in theory we'd need them to be per-product-sold

[senadir]

Are you charging for shipping? I think your use case can also be served by Local Pickup and by having a custom block that allows people to pick from a map or an external service. @passatgt built a block like that for his pickup method.

[EdithAllison]

I'm a developer and this is a real life scenario from a client site:

Modification: All billing core fields except name & email are removed. No shipping address required.
Reason: the shop delivers goods to holiday caravan sites. Customers can select the address of their caravan from a dropdown.
The modification is currently done with the plugin Checkout Manager (Pro), which allows the disabling of core fields and the addition of new fields.

[senadir]

Sounds more like you're doing Local Pickup, which would make sense in your use case here, it doesn't collect a shipping address.

For the billing address, it's sometimes requested by payment methods, if your payment method doesn't request it, you can remove it country by country on the woocommerce_get_country_locale filter.

[EdithAllison]

Not local pickup, it's holiday chalets so the address is a pre-filled dropdown, the customer can select in which chalet they are staying but nothing else.

[senadir]

Thanks! We will look into that.

In the main time, you can probably:

• Have your prefilled locations as "Rates" so people can select from them.
• Force shipping to billing so that you have a single form.
• Rename everything in the editor so it reflects your usecases.

[passatgt]

Even though its not local pickup, the behaviour is the same and you can just simply rename the local pickup option to "delivery to your caravan" and display the available addresses as options for local pickup(either as separate "pickup" points, or with a custom block that renders a list to choose from). Or at least i would do it this way.

[DavidAnderson684]

I routinely remove the telephone field from all sites that sell only digital goods. I have never needed to contact customers by telephone (rather than email), and when I used to collect it privacy-conscious customers asked why I needed it. And under European data protection legislation, it's now illegal to process or store personal data without a legitimate reason anyway - arguably stores that never honestly intend to telephone their customers thus cannot legally gather this field.

[PlatonB]

@senadir Why would we need to ask for fields other than e-mail to sell digital goods?

[PlatonB]

@senadir It seems obvious to me that 1. e-mail is vital for sending a download link for a digital item; 2. the other fields will only waste the customer's time and raise suspicion of unfair personal data collection; 3. the default behavior for Woo should be to only ask for e-mail for digital products, while the merchant should be able to add additional fields if desired.

[passatgt]

You don't need to send an invoice to the customer? If you do(required in many countries, especially in the EU), you need to collect billing details.

[PlatonB]

@passatgt Mandatory multiple fields made only for the EU doesn't seem like a equitable/neutral solution. I think fields required by the laws of not all countries should be at least removable.

[PlatonB]

@passatgt In the non-EU country where I live, it is enough to send to the customer the URL of digital receipt via email and/or SMS. Generation of this receipt and interaction with the tax office can be undertaken by a payment system (an example of plugin of a suitable payment system).

[passatgt]

A: I have a plugin that can generate receipts instead of invoices after a sale. This way i only need to collect the e-mail address and name from the customer.
B: In contact information i ask for a VAT ID, and when i validate that, i get in return all of the valid billing details, so i don't need to show the fields anymore, i can hide the billing address section completely(but still save the data on checkout)
C: If i sell only in a single country, i don't need the country dropbown(can be hidden now with css though)
D: In Hungary, most of the time we don't use the state field, only in special cases, so i usually hide that(i can still do this with filtering woocommerce_get_country_locale)

[vmlopez]

I think it is necessary to be able to include fields or let other plugins do it as it was done before.
Right now it is impossible to add an extra field to request the NIF/CIF for billing purposes.

[passatgt]

https://developer.woo.com/2024/01/26/woocommerce-blocks-extensibility-snaps-additional-checkout-fields-progress/

[TechnicallyWeb3]

I have tried removing billing fields but found I couldn't do so unless I switched to legacy checkout page. I accept only crypto in my store as we are a Web3 education platform. This means I don't need billing data at all except email. Could we include the ability to remove billing details when certain payment gateways are selected? I am using Coinbase Commerce to accept payments and want to make my checkout flow as frictionless as possible. We only sell digital products for now which get sent to the user's wallet.

[helgatheviking]

@senadir wrote a suggestion for how this might be doable now for me... and I can't find it anywhere. Senadir, do you have the link?