Quick answer: Test pricing localization by treating money as the highest-stakes data in your game. Verify each region shows the correct local price tier, the right currency symbol and placement, and rounding that never misrepresents what a player will be charged. The dangerous bugs are a price displayed in one currency but charged in another, a misplaced symbol, and rounding that drifts from the store's actual amount.
Nothing erodes trust faster than money displayed wrong. A player sees one price, gets charged another; a currency symbol lands on the wrong side and the number looks absurd; a sale percentage rounds to a figure that does not match the actual discount. Pricing localization sits at the intersection of formatting, region detection, and your store platform's own price tiers, and a bug in any of them can mean a refund, a chargeback, or a one-star review about being overcharged. QA here is non-negotiable because the cost of error is real money and real trust. This post covers how to test local prices, currency display, and rounding rigorously.
Trust the store's price tiers, not your own math
Most platforms define price tiers per currency, and the prices in those tiers are deliberately not naive conversions of a base price, they are rounded to locally sensible amounts and adjusted for tax inclusion rules. The first and most important test is that your game displays the platform's actual tier price for each region, not a price you computed yourself by multiplying a base value by an exchange rate. Self-computed prices will diverge from what the store charges, and that gap is a charged-the-wrong-amount bug.
Test that your display reads the canonical price from the store for the player's region, and that it updates if the store's tier changes. Where your game shows prices outside a purchase flow, like in a shop preview, confirm those previews use the same source of truth. The recurring failure is two pricing paths, one for display and one for the actual charge, that drift apart. They must resolve to a single number, and that is exactly what you verify.
Test currency display and formatting
Currency formatting is deceptively complex: the symbol differs, its position differs, the decimal and grouping separators differ, and some currencies have no minor units at all. Test a representative spread of currencies and confirm the symbol, its placement before or after the amount, the separators, and the decimal places are all correct for each locale. A price that reads correctly for one currency can look broken or even wrong by a factor of a hundred in another if separators are mishandled.
Test the layout consequences too. Some currency strings are much longer than others, and a button sized for one can truncate or overflow with another, hiding part of the price. Confirm the UI accommodates the longest realistic currency string without clipping the amount. A truncated price is not just ugly; it can show a different number than the player is charged, which is the failure you most need to prevent. Formatting bugs are the ones players screenshot.
Get rounding and discounts exactly right
Rounding is where small errors become trust problems. Test that any rounding your game performs matches the store's rounding, and ideally that you avoid rounding at all by displaying the store's exact tier price. When you show derived figures, like a per-item price in a bundle or a discounted price, confirm the math rounds consistently and never shows a figure the player will not actually be charged. A penny of drift looks like dishonesty even when it is a harmless display artifact.
Discounts deserve focused testing because they combine arithmetic and display. Test that a percentage off is computed against the correct base, that the resulting price matches the store's discounted tier, and that the displayed savings are accurate. Test edge cases like stacked discounts, free items, and prices that round to a whole unit. Players scrutinize sale prices closely, and a discount that does not add up, even by a rounding cent, undermines confidence in every price you show.
Verify region detection drives the right price
Localized pricing only works if you correctly identify the player's region, and that signal can come from the store account, the device locale, or an IP, which can all disagree. Test that you use the authoritative source, usually the store account that will actually be billed, rather than a device locale that can be set arbitrarily. A player whose device is in one language but whose store account is in another region must see the price tied to the account that pays.
Test the mismatch and travel cases. A traveling player, a VPN, or a recently changed store region should resolve to a single coherent price, and the price shown must match the price charged at checkout. Confirm there is no window where the display reflects one region and the transaction another. This alignment between detected region, displayed price, and charged amount is the whole game, and every test here is really checking that those three never disagree.
Setting it up with Bugnet
Pricing bugs are reported emotionally and imprecisely, often as I was overcharged with no detail about region or currency. Bugnet's in-game report button captures device and platform context automatically, so a pricing complaint arrives with the locale, the platform, and the build, which is frequently the only way to find that the reporter is in a currency where your formatting or region detection misfires. That context turns an alarming refund request into a reproducible localization bug you can actually fix.
Pricing bugs concentrate in specific currencies and regions, so Bugnet's occurrence grouping folds duplicate reports into one issue with a count and shows you which locale is generating the most pricing complaints. Add custom fields for currency and region, then filter the dashboard to see whether the problem is a formatting glitch in one currency or a region-detection mismatch in another. Because money bugs are high severity, having them grouped and ranked in one dashboard lets you triage the ones costing real trust first.
Make pricing a pre-release sign-off
Because pricing errors cost money and reputation directly, treat a localized-pricing pass as a mandatory sign-off before any release that touches the store, prices, or formatting code. Walk a representative set of currencies through display and an actual sandbox purchase, confirming the shown price equals the charged price every time. This is more involved than reading a few strings, but a single mismatched currency shipped to a real market produces refunds and reviews you cannot easily undo.
Keep a standing matrix of currencies and regions in your test plan, and expand it whenever you enter a new market. Re-run it on store SDK updates, since platform pricing behavior can change underneath you. The studios that monetize cleanly across regions are the ones who treat displayed money as load-bearing data, verified against the actual charge, rather than trusting that a formatting library got every locale right. With money, the cost of one wrong number is far higher than the cost of testing them all.
Displayed money is load-bearing. Read store tier prices, format per locale, and verify the shown price equals the charged price for every currency.