Ten that looked like a thousand
Prices are stored in the smallest unit, so the number in the database is a hundred times the price. Miss the conversion once and a cheap extra looks expensive.
Money is stored in the smallest unit. Ten ringgit is stored as 1000 sen. Standard practice, and it exists for a good reason: you cannot trust decimals with money, and integers never drift.
The cost is that the number in the database is not the number a person should read. Somewhere between storage and the screen, someone has to divide by a hundred. On one add-on, nobody did. A ten ringgit extra was offered to customers at a thousand.
Why this one is easy to miss
Nothing was broken in a way a computer could see. Both numbers are valid. Both display fine. There is no type error, because a price in sen and a price in ringgit are both just numbers.
That is the whole problem. The unit lives in your head, not in the value. Two variables can hold 1000 and mean completely different things, and the only thing keeping them apart is that everyone remembers which is which.
What I changed
The conversion happens once, at the edge, where the value is about to be shown. Before that point everything is in the smallest unit. After that point it is for display only and never goes back into a calculation.
The failure before was a value that had been half converted: turned into ringgit early, then passed through code that assumed sen. Once you allow both units to travel around, you have to remember which one you are holding, every single time.
One conversion, in one place, is easier than being careful everywhere.
What I keep from it
If a value can be in one of two units, put the unit somewhere the code can see it, not just in the variable name. A name is a comment that cannot be checked.
And prices deserve their own test, however boring it feels. It is a small bug that makes customers think you are expensive, which is an expensive impression for a one line fix.