The discount value to apply. For 'Percentage' type, this represents the percentage value (For example, “10” for 10% off). For 'FixedAmount' type, this represents the fixed monetary amount to deduct from the line item price. Commonly used for discount calculations and displaying the discount value to merchants.
*/
amount: number;
But in real life, with POS UI Extensions 2026-07, it’s always the FixedAmount, even when the type is percentage.
Adding our findings, because we hit this same behavior from a different angle and it took us a while to work out what was happening — hopefully this saves someone the same detour and helps narrow down the root cause.
We can confirm what @dsnvs reported on 2026-07 (POS 11.10.x): the documentation for Discount.amount appears to be correct for writes (we set amount: "10" with type Percentage and POS correctly applies 10%), but the returned cart reports the computed dollar total in that same field — amount: 67.2 for a 12% discount on a $560 line.
Where this becomes more than a display quirk is bulkCartUpdate. Since CartUpdateInput.lineItems replaces the whole line-item set, an extension that adds or edits one line needs to echo the merchant’s other lines back — and the natural way to do that is to pass back the line as it appears in the cart. Because the read and write shapes differ, that echo isn’t a no-op:
Percentage: the read value 67.2 (dollars) gets re-applied as 67.2 percent, so the next read shows 376.32. On the following round-trip the derived percentage passes 100, and at that point bulkCartUpdate resolves normally but the cart doesn’t change — which is hard to detect and recover from, since there’s no error to catch.
FixedAmount: the read value is the line total, but the written value behaves per-unit. A $5/unit discount on a qty-2 line reads back as 10, and echoing that produces a $20 total, then $40 — it grows on each round-trip whenever quantity is above 1.
Cart-level cartDiscounts of type Code round-trip fine in our testing, so this seems specific to line-level manual discounts.
For now we’re working around it by avoiding bulkCartUpdate whenever a line carries a manual discount and using the sequential cart APIs instead, which works but gives up the single-round-trip benefit that made bulkCartUpdate attractive in the first place.
A couple of questions that would really help us:
Is the returned amount intended to be the computed dollar value (and the docs will be updated), or is the read side the bug here? Either way, is there a recommended way to reconstruct the original discount input from a cart line so an echo can be made lossless?
Is bulkCartUpdate resolving without applying (when a derived discount is invalid) expected behavior? A surfaced UserError there would make this failure mode much easier for extensions to handle gracefully.