| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007717 | module PayPal Checkout | module PayPal checkout - sub | public | 2024-09-02 15:39 | 2024-09-16 14:04 |
| Reporter | Galanx | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 2.5.0 / 3.5.0 | ||||
| Summary | 0007717: Paypal AMOUNT_MISMATCH | ||||
| Description | During checkout, if the user is in netMode, it happens that the total amount is derived from $brutBasketTotal (since v2.4+). However, there is a mismatch between $itemTotal + $itemTotalAdditionalCosts and $brutBasketTotal. To be exact, the mistmatch is -0.0099999999999998, thus for example if the price shown in the basket is 6.88, the price we get from $itemTotal + $itemTotalAdditionalCosts is 6.87. When the amount is sent to PayPal, it then results in an AMOUNT_MISMATCH error. | ||||
| Steps To Reproduce | User has to be in netMode, so the $amount->value will come from $brutBasketTotal, otherwise it will always come from $itemTotal + $itemTotalAdditionalCosts. So this is only reproducable in netMode. --- Copied from QA comment --- Steps to reproduce: - Set the option Master Settings > Core Settings > Settings > Show net prices in frontend (B2B). - Create a product with price EUR 1.60. - Create a product with price EUR 1.13. - Create Shipping cost of EUR 10.00. - Now put each product one time into the shopping cart. - Log in. - Select payment option PayPal. - Try to finish order by clicking Order now. You get redirect to checkout step 1 and error message "The payment authorization failed. Please verify your input!" is shown. | ||||
| Additional Information | I suspect the function $basket->getPayPalCheckoutItems(); is calculating the tax % wrong, probably a rounding issue somewhere. The attached screenshot is from the OxidSolutionCatalysts\PayPal\Core\PayPalRequestAmountFactory class. | ||||
| Tags | Checkout, PayPal | ||||
|
|
Hi, thanks for your report. I used a product with a price of EUR 6.88 and shipping cost of EUR 4.90. I think that's exactly your scenario. However, I cannot reproduce the issue in upcoming PayPal Checkout release. The price was EUR 11.78 for amount and breakdown variable. So I have two questions: 1. Can you please tell me with what version of the module you are encountering the issue? 2. Do you apply any discount? We had rounding issues with discounts in the past. [sp] |
|
|
Hi, thanks for your reply. I am using Version 2.5.0. This issue didn't happen with 2.3.0. It started after I upgraded, mainly because the if($netMode) condition from line 49 wasn't there and the price was always consistent. |
|
|
Also forgot to mention we are not using any discounts and are currently able to reproduce it with every product in the Shop of our client. There might be something with how taxes are handled. By sending $total->value as the first parameter in line 69, I think the issue would be fixed and the item_total would be consistent with the total value, unless there was a reason why it gets recalculated again. |
|
|
UPDATE: It seems that this is not always reproducable, only if there are more products in the basket that would lead to some kind of rounding error with a VAT of 19%. I added for example a product with the price 1,60 and one with 1,13 and I could reproduce it again. |
|
|
Thanks for the additional Info. We fixed a similar issue in the past but it seems to be still an issue in some cases. Steps to reproduce: - Set the option Master Settings > Core Settings > Settings > Show net prices in frontend (B2B). - Create a product with price EUR 1.60. - Create a product with price EUR 1.13. - Create Shipping cost of EUR 10.00. - Now put each product one time into the shopping cart. - Log in. - Select payment option PayPal. - Try to finish order by clicking Order now. You get redirect to checkout step 1 and error message "The payment authorization failed. Please verify your input!" is shown. If you use different prices, the issue may not occur. It's very likely a rounding error in some soecial price calculations. Tested in 2.5.0 and current 3.3.5-rc.6. [sp] debugggerScrn.png (45,639 bytes) |
|
|
May I ask when a fix is gonna be released? We have a live Client that is facing this issue and are not sure if we should fork and patch it or wait for a fix. |
|
|
Hello @Galanx, the project team is currently in evaluation state. Currently I'm unable to provide any time estimation so if you are able to fix it yourself this might be the fast way for you. With OXID Platform you can also write a module that extends another module. For updateability this may be even better than a fork. [sp] |
|
|
Hi, yes, though the factory class that I want to patch is not easy to extend via Oxid platform as it doesn't inherit from the Oxid chain. |
