The assumption that the PaymentInformation pane should automatically include and show the billing address might make sense for a lot of sites but not all of them.
In my case, I need a custom pane where the user can provide the billing and optionally a different shipping address (without any actual shipping interation/logic, I just need an address, so I don't plan on using commerce_shipping) and then the user selects the payment gateway later on the review checkout page, at which point I know that he has a valid billing address and I don't want to show anything related to that anymore.
For me, all I'd need is a setting to show/hide the address form as part of this pane.
We might also want to make commerce_payment_commerce_checkout_pane_info_alter() more flexible and e.g. solve that with checkout-flow specific access checking, based on the setting of our pane?
Happy to work on a patch/PR for this, but want to get some feedback on it first, Probably also makes sense to at least wait on the multiple payment gateways issues to land as that makes pretty bug changes to that pane.
Comments
Comment #2
berdirComment #3
luksakI totally agree. The two panes should be separated in general from a UX point of view. Does it make sense tieing a credit card to billing address? Reusing a credit card ist something different than reusing a billing address in my opinion.
Comment #4
bojanz commented@Lukas von Blarer
The current setup was carefully researched for both UX and DX reasons.
Each card has a billing address associated with it. That's how tokenized payment methods work,
That means that selecting a card must also select its billing address, meaning that the other billing address was provided for no reason and should be ignored. That's the problem with the 1.x approach you're advocating.
If you look at major ecommerce sites, you will find that most ask for your billing address together with your card, they don't separate it into separate panes and steps, like Commerce 1.x (and many other ecommerce systems) do.
Comment #5
bojanz commentedI spoke to berdir and we agreed that there's nothing we can realistically do for now. This use case is better solved with a custom checkout flow.
Comment #6
luksakOk, you are right that the billing address can be associated with a card. But from a UX perspective this doesn't always make sense. How would we approach this if the store doesn't need a billing address at all? Is this configurable?
I kind of liked the ways my commerce 1.x sites worked having basically two steps:
How hard is it to create a custom checkout flow like this?
My opinion is that this is a very common checkout pattern and should be configurable without coding a custom checkout flow.
Comment #7
bojanz commentedThis issue was about collecting a billing address separately from the payment method, not about not collecting a billing address.
For not collecting a billing address we have #2820122: Allow collecting a less detailed billing address, you can continue that discussion there. Commerce itself never supported that use case, for reasons listed in that issue.
Creating a custom checkout flow like the one in #6 is moderately-involved and will become much quicker once #2858599: Move a portion of the PaymentInformation pane logic to a PaymentOptionsBuilder is done.
I should mention that such a flow only makes sense UX-wise if you never offer the option to reuse cards, due to #4.
If the site only has offsite gateways, you could code it in a day.
Don't see any other actionable suggestions in this issue, so restoring status.