Abandoning the off-site payment window lets you update the cart without triggering recalculation.

[Kent-N]

Description Abandoning the payment window when using an external gateway, lets the customer return to the site and update the cart without triggering recalculation. The customer can now add items to the cart that won't have VAT added to them and also the shipping won't update either.

What happens is that as you initiate payment through 'commerce/payment/pay', the recalculation mode is set to "none" and the customer is redirected to an off-site payment window. They can now choose to abandon or ignore this window, return to the shop and continue adding items to the cart. All those new items will be missing VAT and they also won't count as additional weight for shipping. This significantly cheaper cart can then be paid for and completed.

To Reproduce

1. Start checkout and select an external/off-site gateway.
2. Close/ignore the payment window.
3. Return to the shop and add more items to the cart.
4. Newly added items don't have VAT added, etc.
5. Initiate checkout again and complete it.

Expected behavior The cart should recalculate when it's updated, even though checkout was initiated previously.

Additional info

• Craft version: Craft Pro 3.6.17
• Commerce version: 3.3.5.1
• PHP version: 7.2.7
• Database driver & version: MySQL 5.5.5
• Other Plugins & versions: QuickPay for Craft Commerce 2.2.15

[pdaleramirez]

@Kent-N What payment gateway are you using for this issue? I tested this on PayPal and Mollie gateway and I couldn't reproduce the issue.

[Kent-N]

@pdaleramirez I am using "QuickPay for Craft Commerce 2.2.15".

[pdaleramirez]

@Kent-N I would suggest to bring the issue to the third party provider. I have tested this on Commerce first party plugin and It is working as expected. Most likely an issue on the quick pay plugin.

[CMeldgaard]

@pdaleramirez, how did you cancel the payment? Its the commerce core setting the recalculation_mode to none. I can see it be handeled in the plugin if the user hits the cancel/return url. But if the just use the browser return button, the issue happens where new products, change of shipping etc doesnt update total for order.

[pdaleramirez]

@CMeldgaard Not sure if the quick pay plugin is causing this. You could also try disabling your custom plugin and modules if you have one. Also test it out on PayPal and see if you still have the same issue.

[CMeldgaard]

@pdaleramirez the issue with the ones you mention is that they aren't offsite. You still stay on the same page, but not all gateways does that. This is the scenario:

1. Customer goes to checkout, pushes on "To payment" - Commerce now sets recalculationMode to none
2. The gateway redirect to a new page on a different domain - so we are now not on the webshop anymore
3. The customer pushes the return button in the browser, which then returns him to the checkoutpage
4. The customer now changes lineitems, shipping etc, but VAT etc. isnt updated because recalculationMode is set to none when you go to payment i Commerce

Same issue arrises if they open the shop in a new window and closes the one with the payment gateway.

When the gateway is onsite, setting recalculationMode to none is not really a problem since you pay imediately. But for offsite gateways it creates issues, such as missing VAT, missing shipping costs etc.

[lukeholder]

@CMeldgaard

Putting the Order into that mode during the payment request should not be saving to the DB in that mode. Referring to this:

https://github.com/craftcms/commerce/blob/develop/src/controllers/PaymentsController.php#L410-L413

Can you confirm that it is persisting it in the database as the recalculation mode of none while you are on the offsite gateway?

[CMeldgaard]

@lukeholder i can confirm that the order is persisted to the database with the recalculation mode of none.

I don't have any idéa as to where it goes wrong. The only time the Order gets saved is when creating the PaymentRequest model, because we need the final order reference before creating the link. But the Order objects here gets instantiated via the authorize function in the gateway using $transaction->getOrder(). So that shouldn't make it persists recalculation mode to the database.

[Kent-N]

@lukeholder I also tested this on my setup and the recalculation mode persists as none in my database, after being redirected to the offsite gateway.

[lukeholder]

@CMeldgaard @Kent-N Hmm, I will need to try and reproduce. Doing so tomorrow morning.

[pdaleramirez]

@CMeldgaard I was able to reproduce this via using the Quick Pay plugin. It happens when you submit a payment using the Quick pay gateway. I think the plugin is setting order recalculation to none during payment submission.

On Commerce first party payment plugin it does not have this issue. I would suggest to submit an issue on Quick pay plugin repo.

[CMeldgaard]

@pdaleramirez @lukeholder

We found the error. QuickPay requires an order number, and the plugin therefor generates the reference for the order, and saves it to it. Managed to track the order model back to where the recalculationMode was set to none, and there by it got saved to the database.

Fixed by temporarily changing it to ALL when saving the reference, and then back to what it was before saving.