search

craftcms / commerce

Fully integrated ecommerce for Craft CMS.
https://craftcms.com/commerce
Other
226 stars 170 forks source link

[5.x]: Order total price is different than the transaction price #3714

Closed MatthiasBrodelet closed 1 week ago

MatthiasBrodelet commented 1 week ago

What happened?

Description

A client placed an order and the amount to pay is slightly different in the transaction than in the order itself. In the screenshot you can see the initial transaction that was reacted with Mollie. The last one (Overschrijving ING) is a manual transaction that matches the order price to work around the issue. You can ignore that transaction.

The transaction price was €4,871.50 while the order price is €4,868.50. Our prices are updated every minute so my guess would be that the transaction was created, the prices were updated, and then the order was created. It would be more logical to first create the order and then the transaction. This way the price can't change in between the 2 actions. If the prices in the cart can be locked as soon as the transaction is created then that would also fix the issue.

Image

Steps to reproduce

  1. Place an order
  2. Update price
  3. Start transaction

You will probably not be able to reproduce this issue since it only will leave a fraction of a second window to change the price. In my case this only happend after 200 orders so the chances are slim. However it still shows that there is something wrong.

Expected behavior

The transaction price should match the order price.

Actual behavior

Transaction price does not match order price.

Craft CMS version

Craft CMS 5.4.6

Craft Commerce version

5.x

PHP version

8.2

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

-

linear[bot] commented 1 week ago

PT-2200 [5.x]: Order total price is different than the transaction price

lukeholder commented 1 week ago

We do our best effort to lock the order from recalculation during the payment process (see the payment controller for the checks we do), but there is no guard guaranteed due to the nature of some gateways needing offsite redirects etc.

The best way to prevent this would be to complete the order manually to lock the order as complete, then make payment on the completed order. Complete the order with the complete cart action and then make payment on the cart with the pay action, making sure to pass the order number param to pay the completed order (and not the current cart).

Hope that helps.