Allow a store to always collect a billing address before payment method selection

I think adding a setting to the payment information pane is the right approach. An alternative approach would have been to allow collecting the billing information via the billing information pane which is unset by the payment module... But this change is probably invasive and confusing.

Regarding

We need to ensure the form accommodates the three types of address entry: new address entry, reuse of a shipping address, and selection of an address from the addressbook. It isn’t clear to me at what point we’ll need to actually write information to the database based on those two alternate address sources, but at this point … presumably the shipping address would have been saved, if applicable, due to the “Recalculate shipping” button … but it also appears that the addressbook widget uses its own logic to determine a default address vs. writing a default address reference to the database for the order.

I'm wondering if we could avoid saving the profile (We could try making this work by creating a temporary billing profile that we could set on the order so that the OrderBillingAddress condition can be properly evaluated.

I don't really like the fact that we're duplicating the logic that currently lives in ProfileFieldCopy (in PaymentInformation), is that necessary? Can't we avoid that?

Rerolled version for Commerce Core 2.25

tried this patch for commerce 2.28

Rerolled to last 2.x-dev

Updated last patch. Improved code. Fixed auto recalculate.

Fixed case when we select not default value from existing payment methods and then reload the checkout step with payment information pane. The address should be updated to default payment method profile's address in that case.

Fixed billing profile when we select Add payment method.

Fixed refresh total when adding new first method with new billing address. But comparing created profiles with the patch and Commerce 2.x without the patch, there is difference - when using clean Commerce without the patch it will create 3 profile entities - 1st for payment method's billing profile, 2nd for address book, 3rd - for order billing profile. In case with patch there are only two created - order and payment method reference to the same billing profile.

Fixed profiles when we create new payment method with new billing profile.

Refactored code to fix error in console when we tried to use existing payment method and submit the checkout form.

+++ b/modules/payment/commerce_payment.libraries.yml
@@ -24,3 +24,13 @@ offsite_redirect:
+    - core/jquery.core

This library doesn't exist. Is it supposed to be once? Also make sure it's not using the deprecated jQuery once over the new @once library.

1. +++ b/modules/payment/js/payment-checkout.js
   @@ -0,0 +1,71 @@
   +      const waitForAjaxComplete = (element) => {
   +        setTimeout(() => {
   ...
   +      let canRecalculate = true;
   

   You're using ES5 syntax, this will break browsers still supported by Drupal core. Drupal Commerce doesn't have the es5 transpile setup from Drupal core like Cart Flyout does.

2. +++ b/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php
   @@ -151,8 +221,94 @@ class PaymentInformation extends CheckoutPaneBase {
   +        if (isset($user_input['copy_fields'])) {
   +          $enabled = (bool) $user_input['copy_fields']['enable'];
   +        }
   

   $user_input['copy_fields']['enable'] ?? false

   Removes if and defaults to false.

3. +++ b/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php
   @@ -151,8 +221,94 @@ class PaymentInformation extends CheckoutPaneBase {
   +      // @todo If the customer has not entered an address, base the selection on the store.
   

   TODO

4. +++ b/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php
   @@ -216,17 +372,27 @@ class PaymentInformation extends CheckoutPaneBase {
   -          'callback' => [static::class, 'ajaxRefresh'],
   +          'callback' => [get_class($this), 'ajaxRefreshForm'],
   

   static::class is the same as get_class.

This patch is way too big as is... I believe the JS was initially copied from commerce_shipping which has been rewritten since to not rely on JQuery since core itself is moving away from JQuery.

I noticed several coding standard issues, and I really don't like the fact that core now has an implicit dependency on commerce_shipping...

We're using a form display that's added by commerce_shipping, and we're getting the shipping profile from the form state. We need to figure out a better way as I wouldn't feel comfortable committing anything close to this approach.

This patch brings me always big pain when I need to update drupal commerce.

I tested the new patch with the reworked javascript from #33 and I think it completely bricks the checkout because the 'wrapper' is wrong.

Wrong:

      $element['#attached']['drupalSettings']['commercePayment'] = [
        'wrapper' => '#' . $element['billing_information']['#attributes']['data-drupal-selector'],
        'paneWrapper' => '#' . $element['#attributes']['data-drupal-selector'],
        'recalculateButtonSelector' => '[data-drupal-selector="' . $recalculate_button_selector . '"]',
      ];

Correct:

      $element['#attached']['drupalSettings']['commercePayment'] = [
        'wrapper' => '#' . $element['#attributes']['data-drupal-selector'],
        'paneWrapper' => '#' . $element['#attributes']['data-drupal-selector'],
        'recalculateButtonSelector' => '[data-drupal-selector="' . $recalculate_button_selector . '"]',
      ];

In the js file, the recalculateButtonSelector is outside if the billing_information. On change, the next button is disabled and never released because the recalculateButtonSelector is not found / triggered.

Attached you can find an updated patch.

This patch only can be applied if with patch 12 from #3184254-12: Separate stored payment methods from new in the Payment Checkout Pane was applied before.

https://www.drupal.org/files/issues/2022-01-06/3184254-separate-stored-payment-methods-from-new-12.diff

I tried to make it compatible with the latest patch that got commited to Commece 3.0.x but I failed.

Maybe @dwkitchen can jump in and help to make this patch compatible with the one, that got finally commited here:
https://www.drupal.org/files/issues/2022-01-31/3184254-15.patch

It turned out, that the patch is not working with free orders.

Attached a fixed version supporting free (0 Value) orders.

We're not going to move forward with this patch as is...

We need to break this issue into multiple. The JS / auto rebuild should be handled separately and this patch should be just about the changes to the Payment information pane itself.

@jsacksick

Unfortunatly we are stuck with this patch. Centarro developed the Byjuno Payment integration (namely dwkitchen). This patch is needed to make the module work at all.

I rerolled the patch again for Commerce 2.31. I don't think that we can split the JS functionality away, because it's an essential part of the idea of the patch. Attached you can find a rerolled patch.

Usecase:

1. If you have a checkout without shipment, you need to enter your payment address details.
2. Based on the country you select, the list of the available payment method is automatically refreshed / updated.
3. If we remove the JS part, the patch will no longer work, because it solved the auto-refresh.

I don't know how to proceed with this patch. It was based on Centarros work, and we should be able to somehow bring this functionality into commerce. Maybe you can make a proposal, how we should proceed with this?

As discussed with @jsacksick we will move the custom code to a custom PaymentInformation checkout pane and no longer rely on this patch.

Cross-posting from #3110842: The billing address condition should not be shown for payment gateways.

There are tangible business reasons why this is necessary.

In Commerce 1 on Drupal 7 it is possible to limit one payment method so it can only be used in one country, and other payment methods so they can be used in all countries except for that one. We've done that for years on a non-profit org's site and it works reliably.

Per #42 it sounds like the work needs to be split into several pieces. Were the necessary issues created? I don't see any open issues regarding this use case besides #2950877, which hasn't been touched in almost three years. What are the next steps here?

In most of our e-commerce projects, we are providing a custom billing information pane and putting the payment method selection in a dedicated payment step. This way it is easy to restrict a payment gateway to a single country, for example

If this is ever implemented, this should go into 3.x.