Update Checkout Summary after changes to PaymentInformation pane

Tagging for review next week in Prague.

Oh yes please this is so important IMO:
Especially if a user is changing billing country inside the EU, then the VAT can change like Germany 19% to Austria 20%.
We should also keep in mind that same thing is maybe needed if the order is created via order admin form.
Tried it to handle with my order processor, but order refresh leads inside an infinite loop. The order doesn't get refreshed when the payment information/address is updated until the refresh interval is fired again.

By the way: IMO it's more a (major) bug than a feature request. Because it's showing a customer wrong information about the order. And if the order is moving to order status "completed" because user is finishing checkout faster than order request you have wrong billing data. This may cause even legal problems.

Any news about this issue related to DrupalCon Prague? :)

This was tagged for review in Prague, but we had a lot on our plates already and prioritized getting stable releases of our contrib modules out (See https://www.drupal.org/project/issues/search?issue_tags=KickstartPrague2022) to see the work that was accomplished there).

Stumbling about that bug again. It's really bad for UI and UX.

Would even pay 50$ to get this issue here fixed. Perhaps other people would also spend some money so together we can sponsor development?

(DO should support an easy way of crowdfunding, but that's another topic 😅.)

Perhaps it would make also sense, if it's possible to set a parameter in the order processor to force an order refresh once without slipping into an infinite loop, too?

I am interested in this issue too.

Is there a workaround to solve this issue?

Trying to figure out if an ajax callback would be an option too. But no idea where to hook in and alter existing structures. commerce (sub)module has something similar functionality, when applying a coupon, then the order summary gets updated (and the order recalculated). See \Drupal\commerce_promotion\Plugin\views\area\CouponRedemption::ajaxRefreshSummary.

Is there a more generic solution than manipulate the billing information form? For example if you're using different forms depending on payment method (in my case commerce_stripe module). But I'm not sure how commerce_stripe gathers address information 🙈

We have somebody from our team looking into this, the patch will be posted here in the upcoming days.

Here is the patch that should fix this issue. However, it needs to be adequately checked, maybe I've missed some cases. Let us know if you have any issues with this patch.

Thank you so much for the patch 🙏.

I tested it on my site installation. The default billing country is Germany (order summary is shown with VAT 19%).
I provide at my site two payment methods for the customer. Both payment methods are checked to collect billing information.
My payment methods provided:

• stripe (see Module page) for credit card payments
• "Buy on invoice", a manual payment plugin, which does actually nothing, aside collect billing information for generating an invoice later via commerce_invoice module. The user can pay later, sending the money manually via bank transfer.

I have following results after applying the patch:

Let's say the user is from Austria (VAT 20%) instead Germany. The user is a first time customer, no customer profile yet.

Test with Stripe

After filling out billing information and click on "continue to review" the order summary gets refreshed with 20% VAT. Works fine.
From a UX point of view it would IMO be nicer, the summary gets refreshed immediately as soon as the billing country in the address widget is changed. AFAIK the address field does a AJAX update of itself too when country is changed?

Test with "manual" plugin

After filling out billing information and click on "continue to review" the order summary doesn't get refreshed. Here the patch doesn't work. The order gets only refreshed after waiting for refresh interval.

I'm seeing some unexpected behavior in testing this patch myself. For my own testing, I just added a promotion that would appear when the billing country is UK. I could see this get applied once, but changing address selections triggered some sort of Ajax refresh that not only removed the adjustment when I went back to a US address but also overwrote the address associated with my prior payment method ... so a payment method with a UK address was changed to be associated with a US address.

I'm guessing this means we're attempting an update with partial or improper data in the wrong context due to the Ajax behavior. At first glance, I'm not sure where / how that may be, but I'm going to move this to "needs work" rather than "active" to show at least it has a starting patch.

Marking this as a "release blocker" even though this is technically not a blocker, but just for keeping track of issues I have in mind for 3.x.

issue is marked as needs work for 3.0.x-dev , however 3.1 is released, wanted to clarify this issue was not fixed as part of the 3.1 release, and is indeed still an issue. Will this be fixed in 3.1?

Will attempt to re-roll the previous patch/MR for this issue.

@astoker88: We are not actively working on this, afair this wasn't ready at all.
Regarding our semantic versioning approach, I invite you to read Revisiting semantic versioning in Drupal Commerce.

Will this be fixed in 3.1?

3.1 is already released, so the answer to that question is no.

The main active branch that is maintained is 3.x.

Thank you jsacksick
I can't apply patch #15 with dev version.
How can apply the fix and test it?

Can you provide the patch for 3.1 version?

Thank you in advance

Can you provide the patch for 3.1 version?

The patch wasn't functional according to #17, we're currently prioritizing other issues. Feel free to take a stab at it if you can, otherwise I'll check if we can prioritize this feature in one of the upcoming releases.

Committed initial fixes to the draft MR.
I've used similar approach as in the commerce_shipping module for auto recalculation. The javascript is the same. Only changed names of variables and functions in code.
I've added new setting to the Payment information pane - 'Auto update order summary'. If the option is not enabled (it's not by default) then there should be 'Update order summary' button displayed on the pane. Otherwise - it's hidden and javascript triggers it on changing the billing address.
Have just tested only editing address. It works - adds or removes discount from promotion depending on selected address and condition in the promotion (I used billing address country as condition).
I haven't test selecting saved addresses yet.
Also the "My billing information is the same as my shipping information." button doesn't refresh the order summary. So we need the fix for it as well. Those checkbox is added by the commerce_shipping module, so maybe it should be fixed those module.
Didn't test also with multiple different payment methods.
And not sure if it doesn't have any conflicts with the shipping information pane e.g. when triggering element is checked in the code. Will need to review and test.

During debugging failed tests I have found that current fixes in the MR doesn't work when the billing profile inline form is added inside the add payment method form. Trying to find solution so it could work for such case too...

To test the fixes in the MR enable the 'Auto update order summary' in the Billing information pane or the Payment information pane (if commerce_payment is enabled).

Hi, as a quick review, In my case the latest MR does not apply fees when swapping between payment methods. The summary does indeed get refreshed via ajax, but the resulting order does not have its fees applied. I will probably look into it if I get the time, but any insight @khiminrm will be very welcome

Noted, I am not at all changing my billing information, just switching between available payment methods, my Fee applies to the payment gateway and has nothing to do with the billing address.... if this is handled In a different issue, I did not find it (sorry) and I would appreciate if you could point me to it. If we would like to handle this here as well, let me know

Thanks

Adding #3583042: Refresh the payment method add form on address selection as a related issue, even though it is not strictly identical but I believe making it easier to react to an updated address should simplify this issue drastically.