In some rare cases, GST rounding on high-quantity, low-cost items can cause the final order total to differ depending on whether the order is created via the website checkout or via the AddOrder API.
Example
Product price: $0.35 inc GST each($0.32 ex GST)Quantity: 30
What the customer expects (and what the website shows)
On the Neto website, the customer sees:
= $10.50 inc GST The order is saved in Neto as $10.50, and the customer is charged $10.50.
What happens when the same order is created via the AddOrder API
When we create the order via the AddOrder API, the order total is calculated differently in the backend.Instead of using the displayed inc-GST unit price ($0.35), the backend calculates from the ex-GST price:
- $0.32 ex GST × 1.10 = $0.352 inc GST
Because this introduces a third decimal place, Neto then multiplies using that exact value:
= $10.56 inc GST So the order appears in the Neto backend as $10.56, even though the customer was charged $10.50.This results in a $0.06 “amount owing” discrepancy on the order.
Important note
When we submit an AddOrder request, we are currently sending SKUs only, so Maropost/Neto performs a live lookup and calculates pricing internally.We can send the unit price through with the order to force the totals to match the website checkout, however this would mean the order is no longer using a true live price lookup (which could matter in rare cases where a price changes between the customer placing the order and the API order being submitted).
Can this API endpoint please have this bug fixed.
