You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
We are experiencing an issue with order total mismatches when processing payments through the Mollie module in PrestaShop. The problem seems to be caused by differences in how VAT is rounded between PrestaShop and Mollie.
Issue Details
This is a B2B webshop that deals with large quantities and calculates prices excluding VAT.
The product price is €3.09 excl. VAT.
VAT rate: 21%.
Order quantity: 1,920 units.
- PrestaShop calculates the total amount as follows:
- Subtotal (excl. VAT): 1,920 × €3.09 = €5,932.80
- VAT (21% over total): €5,932.80 × 0.21 = €1,245.89
- Total incl. VAT: €5,932.80 + €1,245.89 = €7,178.69
Mollie expects a different total: €7,179.70 (from API error response).
However, when we change the rounding method in PrestaShop to "Round per item," the total becomes €7,180.80, and Mollie accepts the payment.
API Error Message
"message": "[2025-02-19T08:53:11+0100] Error executing API call (422: Unprocessable Entity): The amount of the order does not match the total amount from the order lines. Expected order amount to be €7,179.70 but got €7,178.69.
Possible Cause
It seems that Mollie calculates VAT per item and then rounds, while PrestaShop calculates VAT on the total and then rounds. This discrepancy leads to a mismatch in the total amount sent to Mollie. Since this is a B2B webshop that works with large orders and always calculates prices excluding VAT, we do not want VAT to be rounded per item.
Steps to Reproduce
Set product price to €3.09 excl. VAT in PrestaShop.
Configure 21% VAT.
Add 1,920 units to the cart.
Ensure rounding in PrestaShop is set to "Round on total".
Proceed to checkout and attempt payment with Mollie.
Payment fails with a 422 error due to a total mismatch.
Change rounding to "Round per item" in PrestaShop.
Payment is accepted, but the total now differs from PrestaShop's calculation.
Expected Behavior
Mollie should either:
Accept the total as calculated by PrestaShop (without forcing "Round per item").
Provide an option in the Mollie module to calculate VAT and rounding at the order level, rather than per item, to support B2B webshops.
Environment
PrestaShop version: 1.7.8.10
Mollie module version: 6.2.6
PHP version: 8.3
PrestaShop rounding settings: Per ordertotal
Suggested Fix
Allow PrestaShop's total (rounded at the order level) to be accepted by Mollie.
Provide a setting in the Mollie module to match PrestaShop's rounding method and allow order-level VAT calculation for B2B stores.
Add better logging or error messaging to clarify why Mollie expects a different total.
Is anyone else experiencing this issue? Any suggested workarounds other than changing rounding settings?
Thank you for your help!
The text was updated successfully, but these errors were encountered:
Description:
We are experiencing an issue with order total mismatches when processing payments through the Mollie module in PrestaShop. The problem seems to be caused by differences in how VAT is rounded between PrestaShop and Mollie.
Issue Details
- PrestaShop calculates the total amount as follows:
- Subtotal (excl. VAT): 1,920 × €3.09 = €5,932.80
- VAT (21% over total): €5,932.80 × 0.21 = €1,245.89
- Total incl. VAT: €5,932.80 + €1,245.89 = €7,178.69
API Error Message
Possible Cause
It seems that Mollie calculates VAT per item and then rounds, while PrestaShop calculates VAT on the total and then rounds. This discrepancy leads to a mismatch in the total amount sent to Mollie. Since this is a B2B webshop that works with large orders and always calculates prices excluding VAT, we do not want VAT to be rounded per item.
Steps to Reproduce
Expected Behavior
Mollie should either:
Environment
Suggested Fix
Is anyone else experiencing this issue? Any suggested workarounds other than changing rounding settings?
Thank you for your help!
The text was updated successfully, but these errors were encountered: