WPIntell

Source evidence

Decimal Quantity not working

Mollie Payments for WooCommerce · support · 2026-05-22T09:55:00+00:00

complaintsentiment
highseverity
0.9relevance
5replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

9 / 39 rows with source links

23.1% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

30 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
vanmeij unresolved
Still the same error; after more than a year. Still no solution. Tried both API’s, tried new keys everything, seems like I’m stuck to version 7.10 Mollie with WooCommerce. Orders without decimal quantity working very well. Failed to create Mollie payment object for order ### Error executing API call (422: Unprocessable Entity): Line item 1 is invalid. The ‘quantity’ field should be a whole number. Documentation: https://docs.mollie.com/reference/handling-errors . Request body: {“status”:422,”title”:”Unprocessable Entity”,”detail”:”Line item 1 is invalid. The ‘quantity’ field should be a whole number”,”field”:”lines.1.quantity”,”_links”:{“documentation”:{“href”:” https://docs.mollie.com/reference/handling-errors” ;,”type”:”text/html”}}}. Field: lines.1.quantity This topic was modified 6 days, 13 hours ago by vanmeij . Hello @vanmeij Indeed, there is a gap in handling fractional quantities here. However, this is also a limitation from Mollie’s side: their API does not support fractional quantities at all. The challenge is that simply rounding the quantity to a whole number may introduce another issue. I will raise this with the developers. Kind Regards Krystian Thank you, because it is working in version 7.10 so is it a bug? Or is it a change on Mollie’s way to handle orders. It seems not that difficult to get this thing right. Also a musthave for some webshops right? Handle weights, liters or gallons, handle square meters etc. Hello @vanmeij Mollie’s API requires line item quantities to be whole numbers. Because of that, WooCommerce stores using plugins that allow decimal quantities (for example selling 1.5 kg, liters, square meters, etc.) currently receive a 422 error from Mollie and the payment fails entirely. The good news is that a fix has already been added to the sprint. Kind Regards Krystian @inpsydekrystian Thank you! Any idea when can we expect the fix? Hello @vanmeij The fix is currently planned for version 8.1.8 (the release after next). We are still discussing the best approach for the implementation to make sure the solution is handled properly. Kind regards, Krystian

Comments

5 shown
Krystian Syde 2026-05-22T11:04:00+00:00

Hello @vanmeij Indeed, there is a gap in handling fractional quantities here. However, this is also a limitation from Mollie’s side: their API does not support fractional quantities at all. The challenge is that simply rounding the quantity to a whole number may introduce another issue. I will raise this with the developers. Kind Regards Krystian

vanmeij 2026-05-22T11:34:00+00:00

Thank you, because it is working in version 7.10 so is it a bug? Or is it a change on Mollie’s way to handle orders. It seems not that difficult to get this thing right. Also a musthave for some webshops right? Handle weights, liters or gallons, handle square meters etc.

Krystian Syde 2026-05-28T06:52:00+00:00

Hello @vanmeij Mollie’s API requires line item quantities to be whole numbers. Because of that, WooCommerce stores using plugins that allow decimal quantities (for example selling 1.5 kg, liters, square meters, etc.) currently receive a 422 error from Mollie and the payment fails entirely. The good news is that a fix has already been added to the sprint. Kind Regards Krystian

vanmeij 2026-05-28T10:06:00+00:00

@inpsydekrystian Thank you! Any idea when can we expect the fix?

Krystian Syde 2026-05-28T11:05:00+00:00

Hello @vanmeij The fix is currently planned for version 8.1.8 (the release after next). We are still discussing the best approach for the implementation to make sure the solution is handled properly. Kind regards, Krystian