DEV Community

Cover image for Localized Pricing and Currency Display Testing on Real Devices
Bhawana
Bhawana

Posted on

Localized Pricing and Currency Display Testing on Real Devices

A customer in London expects £55. A shopper in Tokyo expects ¥6,278. Show the wrong currency and the sale is gone. It's not a subtle UX problem. It's an instant trust killer.

Most teams still test localization by toggling browser language settings or spoofing GPS coordinates. Both approaches miss the one thing e-commerce platforms actually use to determine pricing: the IP address. Server-side geo-detection doesn't care what language Chrome is set to. It checks where the traffic is coming from. If the test traffic isn't coming from a real IP in the target country, the test isn't seeing what real customers see.

Proper localization testing needs real IPs, real devices, and full pricing-flow validation from product listing to checkout. This guide walks through how to do exactly that using TestMu AI's Real Device Cloud, with Gymshark and Amazon as test subjects.

The Setup: Real Device, Real Browser, Real Geolocation

For this testing session, the setup was:

  • Device: Samsung Galaxy S25 Ultra (Android 16)
  • Browser: Google Chrome
  • Test Sites: Gymshark and Amazon
  • Geolocations: United Kingdom, Japan, United States

TestMu AI provides access to 10,000+ real devices across multiple geographies. The IP Geolocation feature routes the session through infrastructure in the target country, so e-commerce platforms receive a legitimate foreign IP, exactly as they would from a real customer.

No VPNs, no browser extensions, no tricks. Just a real device with a real IP in the right country.

Test 1: Gymshark UK Pricing

The first test started from the TestMu AI dashboard. A browser session launched on the Galaxy S25 Ultra, navigated to gymshark.com.

Setting the geolocation:

From the left toolbar, click IP Geolocation, search for "United Kingdom," and select it. A toast confirms "Location updated to United Kingdom."

Gymshark immediately detected the UK IP. A popup appeared asking "ARE YOU IN THE RIGHT PLACE?" with UK pre-selected. After confirming, the site loaded the UK storefront.

What showed up on screen:

The URL changed to uk.gymshark.com. Prices displayed in British Pounds: £50, £38, £55. The promotional banner showed UK-specific messaging: "Free standard shipping on orders over £75."

This is exactly what a real UK customer would see. Correct currency symbol, proper formatting, localized promotions. No guesswork, no assumptions about what the server should return.

Test 2: Amazon Japan Pricing

Next, amazon.com with the Japan geolocation active.

Amazon detected the geographic signal and displayed a banner: "We're showing you items that ship to Japan." Product prices appeared in Japanese Yen: ¥6,278, ¥1,004, ¥3,298. Proper formatting across the board, no decimals, correct symbol placement, comma separators.

Everything looked right. Until it didn't.

The Bug: Mixed Currency on Japan Homepage

While scrolling the homepage, one promotional section displayed "Apparel under $25." USD pricing on a page that was otherwise fully localized to Japan with JPY everywhere else.

A Japanese customer would see mixed currencies on the same page. ¥6,278 on one row, $25 on the next. That's not a minor formatting inconsistency. That's genuine price confusion for anyone trying to understand what they're about to pay.

Why IP Geolocation Caught This

This is exactly the kind of bug that only surfaces through real IP geolocation testing. Browser language settings wouldn't catch it. GPS spoofing wouldn't catch it. Neither approach triggers Amazon's server-side geo-detection, which is what controls the pricing and content served to each region.

The promotional content block was likely hardcoded with USD rather than being dynamically localized. Without a real Japanese IP address hitting the server, this bug stays hidden through every other type of testing.

Test 3: Multi-Device Comparison (Japan vs US)

TestMu AI's Multi-Device Testing feature allows two devices to run side-by-side, each with independent IP geolocation:

  • Left device (Galaxy S25 Ultra): Japan geolocation
  • Right device (Galaxy S25): US geolocation

Both devices loaded amazon.com simultaneously. The results were dramatically different.

Japan device: Product search results with JPY pricing, "Deliver to Japan" banner, "Ships to Japan" on listings.

US device: Completely different homepage. Luxury brand showcases (Louis Vuitton, Van Cleef & Arpels), "Shop the premium spring edit" section, "Up to 15% off luxury gifts" promotion.

Same URL. Same moment. Radically different experiences. Amazon doesn't just swap the currency. It serves entirely different homepage content, merchandising, and promotional campaigns based on geography.

Without multi-device testing with independent geolocations, these regional differences would be completely invisible to the testing team. And if they're invisible in testing, they're unvalidated in production.

Why These Findings Matter for Localization QA

The IP Layer Is Non-Negotiable

Both Gymshark and Amazon rely on IP address geolocation as the primary signal for determining which pricing to display. Changing browser language settings or using a browser extension to spoof location would not have triggered these responses. The server-side systems specifically check the incoming IP address.

This is why testing on a real device cloud with actual IP geolocation simulation is essential. TestMu AI routes session traffic through infrastructure in the target country, so the e-commerce platform's servers receive a legitimate foreign IP. The same mechanism that serves content to real customers serves content to the test session.

Real Devices Catch Real Rendering Issues

Emulators can approximate how a price might appear, but they can't replicate the actual rendering pipeline of physical hardware. The Samsung Galaxy S25 Ultra's display, its font rendering engine, and Chrome's layout calculations on that specific chipset all contribute to how the price ultimately appears.

Consider the Japanese Yen prices on Amazon. The ¥ symbol and the numbers need to align correctly within the price container. On a real device, it's possible to observe whether the symbol clips, whether numbers wrap unexpectedly on smaller containers, or whether the font weight renders the currency legibly. These are hardware-dependent behaviors that emulators miss entirely.

Multi-Device Testing Exposes Regional Differences

Running the same test on two devices simultaneously, each with a different geolocation, reveals how dramatically the customer experience varies by geography. In the Amazon test, the Japan-geolocated device showed product search results with JPY pricing, while the US-geolocated device showed a completely different homepage with luxury brand showcases.

This isn't just a currency swap. It's a fundamentally different merchandising strategy, different content curation, and a different user journey. Without multi-device testing with independent IP geolocations, these regional differences would be invisible to QA.

Building a Localized Pricing Test Checklist

Based on these findings, here's a practical checklist for validating localized pricing on any e-commerce site:

Pre-Test Setup
Identify target geographies (start with the top 3-5 revenue markets). Document expected currency for each geography (GBP, EUR, JPY, INR). Note expected formatting conventions: decimal separator, thousands grouping, symbol position. List specific products to test across a range of price points.

IP Geolocation Validation
Set geolocation to the target country. Confirm the site detects the new location (look for country selector popups, redirects, or banners). Verify URL changes if the site uses country-specific domains (e.g., uk.gymshark.com).

Currency Display Validation
Correct currency symbol appears (£, €, ¥, ₹). Symbol position matches local convention (before or after the number). Decimal handling is correct (no decimals for JPY/KRW, comma decimals for EUR in some countries). Thousands separator matches local convention (comma, period, space, or apostrophe). Prices are properly rounded with no raw conversion artifacts like £47.213.

Price Consistency Validation
Prices remain consistent from product listing to product detail page. Cart summary shows the same currency and formatting. Checkout preview maintains currency consistency. Promotional discounts apply in local currency.

Cross-Device Validation
Test on at least two screen sizes (flagship + mid-range). Verify price containers don't overflow or clip. Confirm currency symbols render correctly across devices.

From Manual Testing to Automated Regression

The manual workflow demonstrated here (set geolocation, browse products, validate pricing) is ideal for exploratory testing and initial validation. For ongoing regression testing, TestMu AI also supports IP geolocation in automated Appium test scripts.

This means localized pricing checks can integrate directly into the CI/CD pipeline. Before each release, automated tests run against production URLs, simulate visitors from each target geography, and assert expected currency symbols and price formats. Any regression, like a deployment that breaks GBP formatting, triggers an alert before it reaches customers.

The same real device cloud that powers manual testing also executes automated tests, so the IP geolocation accuracy and device fidelity remain identical in both scenarios.

The Cost of Getting This Wrong

Localized pricing is where global revenue meets local trust. A customer seeing the right currency with proper formatting feels like the site was built for them. Mixed currencies or wrong symbols make them feel like an afterthought.

In a single testing session, this workflow validated Gymshark's UK pricing (£50, £38, £55), caught a real localization bug on Amazon Japan ("$25" on a ¥-priced page), and revealed that Amazon serves entirely different homepage experiences to US vs Japan customers.

Every global e-commerce team should be running these tests. The setup takes minutes on TestMu AI's Real Device Cloud. The alternative, shipping localization bugs to production, costs far more than the time invested in catching them.

Top comments (0)