Allow collecting a less detailed billing address

In our case we cannot use the address field and are replacing it with separate fields for street, number, etc.

So you won't be using payments at all?

The field is locked because every payment gateway depends on it, I'm afraid that unlocking it will allow people to accidentally damage their site.

Most gateways ask for a billing address. That comes from the address field.

So what you're trying to do isn't actually possible. A custom widget for the address field would make more sense.
Otherwise you'll need to write custom code that syncs the address field with your custom fields, which is tedious.

A costum widget on the address field would be nice to have when we when we sell automatic digital goods within the EU, we have to prove, at least two pieces of evidence, for the country in which the customer is staying in, for recovery of the correct tax rate. A common proof is that the customer self-declares a residence on the sworn statement. Here we need country and postal code to determine seating location, street name and city names in this context is less important.

However, if the payment gateway requires all address information, it obviously makes no sense to sort out some of this information.

A digital customer would probably be able to understand the need to give information which can calculate the correct tax, but some might be annoyed to deliver an expanded address information as of the acquisition are not included shipping (unless that country's invoice rules require all information about address).

If I understand correctly, if the payment gateway doesn't need the address everything should work just fine.

Which is impossible. There is no way to design that, gateways simply want this information and we can't abstract it out.

The address field schema has two address lines, why not use one for the street and another for the number?

As I said. In D7 commerce worked fine without billing profile and without address field, e.g. for Ogone/Ingenico.

Only by accident, if the Ogone module never accessed that field.
In D8 we've simply strengthened the assumption that Commerce always had.

Anyway, this is a feature request that I'm happy to consider, it is however more complex than just unlocking the field.
We need to redefine what the minimal guarantees are around billing information.
The only field I'm certain is safe to disable is the "Organization" one. Your proposal is to allow not collecting the first and second address lines. This means checking which payment APIs require these fields (VS just recommending them), and if it's not universally optional, having a mechanism to prevent reducing Address fields when those gateways are used.
Such profiles would also not be reusable as shipping addresses (which makes sense in a digital scenario, but we need to ensure people don't accidentally do it).

EDIT: It was pointed out to me that you are actually collecting street addresses, your problem is that the address field does not give you a separate field for the house number. I offered a solution for that (using the second address line), and would be happy to continue that investigation in the Address issue queue. Focusing here on the digital use case of collecting less detailed addresses.

Hi Stizzi,

A digital customer would probably be able to understand the need to give information which can calculate the correct tax, but some might be annoyed to deliver an expanded address information as of the acquisition are not included shipping (unless that country's invoice rules require all information about address).

Can you give an example of a country that does not require an address for a customer-not-present transaction?

@dwkitchen I'm sorry to have contributed to confusion about this topic that I have very little knowledge about. No, I can not give some examples of some countries which do not require a non-present customer's full address information. Regarding invoice rules, many countries have the opportunity fairy simplified invoice for goods under a certain amount, the customer's address is not required. (UK rules https://www.gov.uk/vat-record-keeping/vat-invoices). My opinion was hypothetical and not based on concrete knowledge.
My thinking about a custom address field stopped, with Bojans statements that payment gateway can not allow the customer not disclose address, Bojan if anyone should know. (Although there may exist undesirable scenarios that I as a novice can not figure out. From Braintree doc
:street_address
String
The credit card billing street address. 255 character maximum. Only required if using card verification when AVS rules are configured to require street address. )

@bojanz
In most e-commerce systems the Name, Surname and Business Name are part of Account settings, while billing contains only the address.
Why not consider such structure for Drupal 8 as well and to unlock the Name/Surname fields?

I subscribe this. We are setting-up an e-Commerce with Commerce 2.0 and we are now in the phase of defining the customers info, and thus assessing the out-of-the-box Commerce set up. It sounds "strange" that we here have an hard-coded "customer" profile, that is then named "address book" in the account local tasks, and that holds just a "locked" Address field, that cannot be personalized: for instance I cannot easily hide/remove the name, surname & company fields bundled in the Address (locked) field and reattach them as separate fields in the same "customer" profile. I might mind would better manage them in a more personalized way.
I also noticed that if I add a new custom field in the bundled "customer" profile (let's say a phone field), besides the address one, it will show up as editable field in the Order edit page. Weird ... and not that easy to fix (so far) for us.
This Commerce customer/address_book section still seems to be a work-in-progress area, needing some possible adjustments. Isn't it?

 It sounds "strange" that we here have an hard-coded "customer" profile, that is then named "address book" in the account local tasks, and that holds just a "locked" Address field

It's hardcoded & locked because code (payment gateways, shipping methods) relies on that information in that shape. It's not easy to allow it to be personalized while ensuring that doesn't break all modules. In fact, in Commerce 1.x people used to accidentally delete their address fields, causing complete data loss across the site.

I also noticed that if I add a new custom field in the bundled "customer" profile (let's say a phone field), besides the address one, it will show up as editable field in the Order edit page. Weird ... and not that easy to fix (so far) for us.

All customer information needs to be provided at checkout / order edit.
It has always been this way, and is the whole reason behind having customer profiles.
If you don't want that behavior, attach your field to a different profile type, not the one used by Commerce.

This Commerce customer/address_book section still seems to be a work-in-progress area, needing some possible adjustments. Isn't it?

Correct, still a work in progress.

tnx @bojanz for the quick answer ...
So this means that the default Commerce "customer" (billing) profile should be un-touchable / un-extendable, and able to collect just "addresses"?
Should I avoid to add custom/additional fields besides the locked "address" one?
Where to put additional info from the customer then?
Should it be better called some other way then/instead, lets' say "customer_address" as bundled profile? As it is quite/very probable that I (we) would/might need a new custom "customer "profile" to store additional customer info (if I cannot use the "customer" commerce default/protected one).

@itamair
A phone field makes perfect sense on the customer profile, since that's a field you'd want to collect at checkout / order edit.
I suggest editing your post to remove the bug report, and moving it to a separate issue, cause it's unrelated to the previously discussed conceptual problem.

you are perfectly right, @bojanz

I wish to weigh in here and add that if I'm creating a local e-commerce site in Europe, that just sells in one country (or in the US if you for some reason sell in just one state) Then I already know all the necessary tax information that is going to apply to all orders. And in EU there are many many payment methods that do not require a billing address input. (Also a lot of credit card processors don't bother with the addresses anymore.)

Having the billing profile fields locked in the checkout could put commerce users in a disadvantage compared to their competitors who can provide a cleaner less hassle checkout process UX wise..

For my current project I'm starting in one EU country where this exactly applies, but when expanding in the future my product's have options and those options already determine the persons taxing location, so in any way it's a redundant field for me in checkout.

Cheers!

Actually is not that difficult to unlock the address field in the customer bundled profile ... and disable the unwanted fields from it.
The Name and Surname (and Company) fields might then be re-implemented as new independent fields in the same customer profile.
Why might this break the payment gateways?

Anyway, I guess/propose/ask the commerce "customer" profile should be renamed into something that better represent its commerce use, such as "customer_billing" or something similar (https://www.drupal.org/node/2867648)

For Russia, Belarus, Ukraine and other CIS countries, this payment form is not suitable! It certainly needs to be corrected! Definitely need to give a chance at all without her, we have many examples when there is no need to enter data, when you select a payment method!

Besides, for our countries, these data are not for full payment!

In commerce1 90% of cases we refused the "address" field at all and used my own field!

I'm curious why the customer profile address field has the "middle name" field unavailable. We'd quite like to collect that data separately, and presumably payment gateways won't care if there is an extra field that they don't require?

If you don't need the address at all, see solution: #2905028: Add a per-gateway setting to skip collecting billing information

I'm having also a lot of issues here, and though I can understand the efforts made by the Commerce developers to avoid people from accidentally breaking their sites, I think some degree of configuration should be available here.

I can think at least of this use cases I've stumbled upon on a recent project.

- Purchases that may not need physical addresses (either legally and for the payment gateway). In my case, i'm using Commerce License for selling roles on Spain and thus asking for directions and zipcodes is useless and will better be avoided.
- Selling mainly (or only) to individuals. "Company" field is clearly the weakest link here.

I hope some compromise can be found here to address both concerns. We don't want breaking sites, but we might also be aware that many developers resort to Drupal + Commerce precisely to avoid locked functionality (instead of using gated systems like Shopify).

- Purchases that may not need physical addresses (either legally and for the payment gateway). In my case, i'm using Commerce License for selling roles on Spain and thus asking for directions and zipcodes is useless and will better be avoided.

It's not useless considering some digital codes must be taxed. And digital transactions have a high fraud count and many merchants use AVS verification.

- Selling mainly (or only) to individuals. "Company" field is clearly the weakest link here.

Agreed.

Another strong case for making the billing address optional is for payment gateways using crypto-currenies.

I'm trying to build such a gateway now and the billing address is absolutely not required.

When you use language like 'most providers' and not 'all providers' this is therefore inherently problematic as 'some other providers' do not actually require it.

Thank you everyone for your feedback.

Thanks to Address 8.x-1.4 and its new field override UI, I was able to move this issue forward.

The commit above has unlocked the address field (which allows it to be edited), and added code that prevents it from being deleted.
It will be a part of today's Commerce 2.7 release.

You can now go to admin/config/people/profiles/manage/customer/fields and edit your Address field, hiding any field except the country dropdown. You can also go to your store edit form, and select a single item in "Available countries", which will also hide the country dropdown.

This makes both sides happy, you can skip asking for billing info, while the system can still rely on having an address object with a country code.

Disclaimer:
- There is no guarantee that your payment gateway / shipping API won't crash without certain fields (such as the postal code or the state in the US). It's up to you, the site builder, to ensure that things still work.
- There is no guarantee your EU accountant will be happy without a complete address. If you're hiding more than the Company/Address line 2 fields, consult the accountant first.

@bojanz this greate news! Thanks

@bojanz, sorry to bother you, I've gone to admin/config/people/profiles/manage/customer/fields and clicked to edit the address field. The options you mention don't appear for me.

I have this installed:

Drupal Commerce 8.x-2.7
Address 8.x-1.4