The first discount in a shop is easy. Ten percent off, one code, one field on the order. It works, everyone is pleased, and it quietly establishes a shape that the second discount will not fit into.
The questions the first version never asks
Can two promotions apply at once? If a customer has a member rate and a voucher, do they stack, or does the better one win? Somebody has to decide, and if nobody does, the answer becomes whatever the code happens to do.
What is the discount applied to — the item, the order, or the shipping? These are different, and they behave differently when one item in the order is returned.
Does it apply before or after tax? Get that wrong and the invoice is not just inaccurate, it is inconsistent with what the accounts expect, which is a slower and more painful discovery.
And what happens to a discounted order that is partly refunded? The proportion has to come from somewhere, and if the discount was stored only as a single figure on the order, it cannot be worked out afterwards.
Store the reason, not just the result
The pattern that survives is to keep the discount as a line, not as a subtracted number. A row that says: this promotion, this rule, applied to these items, for this amount, at this moment.
That makes the total explainable — someone can look at an order from four months ago and see exactly why it came to what it came to. It also makes a refund calculable, and it makes the question “what did this campaign actually cost us?” a query rather than an investigation.
Rounding is a decision too
Percentages on multiple lines produce fractions of a rupiah, and where you round changes the total. Round each line, or round the order, but pick one and write it down, because the invoice, the payment gateway and the accounting export will each do it their own way if you let them.
The symptom of getting this wrong is small and endless: a total that differs by one rupiah between two screens, and a support conversation every time somebody notices.