Google Play In-App Purchase Pricing by Country: The Complete Walkthrough
A walkthrough of Google Play in-app purchase pricing by country: console mechanics, Pricing Templates deprecation, and what auto-conversion misses.
💡 TL;DR
Google Play accepts arbitrary local-currency prices per country (no tier ladder like Apple). The Pricing Templates feature was removed Oct 2025. Auto-conversion misses local purchasing power. Here's the walkthrough.

Most pricing localization content gets written for the App Store. Apple takes the spotlight because the price-point ladder is more constrained, the rules feel more rigid, and the developer documentation is louder. Google Play is the other half of the catalog for anyone shipping cross-platform, and its pricing system works very differently.
This post walks through Google Play in-app purchase pricing by country end to end: how the system handles per-country prices, what the Pricing Templates deprecation on October 27, 2025 changed, what auto-conversion gets right and wrong, and how to keep your Google Play prices working as currencies and tax rules drift.
I've managed pricing across both stores for 8 apps over more than a decade. The mistakes I see indie devs make on Google Play are different from the ones they make on the App Store, and the fixes are too.
What Google Play offers for per-country pricing
Google Play accepts arbitrary local-currency prices for in-app purchases and subscriptions on a per-country basis. There is no tier ladder. If you want to charge ₹487 in India and R$49,90 in Brazil, you can. The console accepts the numbers as you type them, snapping only to the country's currency conventions for decimal places.
This is the first big structural difference from the App Store. Apple offers around 900 price points per currency in a predefined ladder, and you pick the closest tier to your intended price. Google Play has no equivalent constraint. The flexibility makes Google Play feel simpler at first, but it also means there's no ladder to fall back on when you don't have a clear pricing strategy of your own.
A few specifics worth knowing on the mechanics.
The console exposes per-country pricing under Monetize with Play > Products > One-time products for one-time purchases, and Monetize with Play > Products > Subscriptions for auto-renewable subs. Each product has its own pricing surface, separate from your store listing localization (which is managed under Grow > Store presence). Listings and prices are independent: you can price a country without listing in its language, or list in a language without pricing the corresponding country.
Google Play uses local currency for almost every supported country. Unlike Apple, which quotes USD in some smaller storefronts, Google Play's billing infrastructure handles local currency in every market it serves. That removes one source of confusion when you're trying to reason about what a user actually sees.
For the broader framing of why pricing belongs alongside language, metadata, and assets in a full localization strategy, see the pillar post: App Store Localization: Beyond Language Translation.
Setting per-country prices in Google Play Console
Here's the actual workflow for setting custom per-country prices on a Google Play product.
- Open Google Play Console and select your app.
- Go to Monetize with Play > Products > One-time products (or Subscriptions if you're pricing a subscription).
- Click into the product you want to localize.
- Set your default price in your account's primary currency. Google Play uses this as the base for auto-conversion in markets where you haven't set a custom price.
- Look for "Set prices for specific countries" (label varies slightly by Console version).
- Toggle the country override and enter the local-currency price.
- Save.
For subscriptions, the workflow has an extra layer because base prices and offers (introductory pricing, free trials) are separate. Each base subscription has its own per-country pricing under the subscription product. Each offer attached to that subscription can also have country-specific eligibility.
Two practical notes from running this across multiple apps.
Currency formatting is automatic. Type 49.90 and Google Play will display R$ 49,90 to a Brazilian user with the comma decimal separator. You don't need to manually format per locale.
There's no bulk-edit-by-country UI in the standard Console. Setting per-country prices for one product across 175 countries is a click-per-country operation. This is one of the structural reasons developers reach for tooling once they have more than a handful of products. The full execution playbook including this kind of workflow lives in Localized Pricing for Mobile Apps: The Complete Guide.
Tax handling on the developer side differs between the two stores. End users in jurisdictions that require tax-inclusive display typically see tax-inclusive prices on both stores, but how prices are configured by developers and how taxes are reported in financial reports differs. Worth checking on a per-region basis if you want display prices to match precisely across stores.
What the Pricing Templates deprecation changed
Until October 27, 2025, Google Play offered a feature called Pricing Templates that let you define a price across countries once and apply it to multiple products. It made bulk localized pricing manageable for catalogs of any size.
That feature is gone.
Google removed Pricing Templates on October 27, 2025, and per-country pricing is now strictly per-product. If you have ten in-app purchases and you want consistent country-specific prices across all of them, you need to set those prices on every single product individually.
For an indie dev with one or two SKUs, the change is a minor inconvenience. For a developer with a multi-app catalog and ten in-app purchases per app, it is a structural shift that meaningfully increases the manual work of maintaining localized prices.
I covered the deprecation in detail in Google Play Pricing Templates Are Gone. Here's What to Do Now. Short version: you either accept the additional manual workload, automate via the Play Developer API, or use a tool that handles the per-product per-country sync for you.
What auto-conversion gets right and wrong on Google Play
Google Play, like the App Store, supports auto-conversion. You set a default price in your primary currency, and Google generates equivalent prices for every other country you haven't manually overridden.
The mechanics are similar to Apple's. The shortcomings are similar too.
Auto-conversion solves currency math. It does not solve pricing strategy. The number Google Play generates for a market like India or Indonesia is roughly equivalent to your USD price at current exchange rates, with local tax adjustments folded in where applicable. That number is correct in an FX sense and frequently wrong in a purchasing-power sense.
The gap between an auto-converted Google Play price and a Purchasing Power Parity-adjusted price can be 2x to 3x in price-sensitive markets. A $19.99 base price might auto-convert to roughly ₹1,900 in India, while the PPP-appropriate localized price for the Indian market is closer to ₹650 to ₹700 once you apply rounding to native price endings. The full reasoning behind those numbers and a country-by-country reference live in the App Store-side companion post: App Store Pricing by Country: The Developer's Reference. The same purchasing-power gaps apply to Google Play, with mechanical differences in how taxes are folded in.
There are also two failure modes specific to Google Play.
First, once you set a manual override, Google Play stops auto-adjusting that country going forward. Same as Apple: manual prices freeze, regardless of whether your base price changes or local FX moves. If you set a manual ₹487 in India in 2024 and never revisited it, your 2026 Indian users are still seeing that price even though the local economy has shifted underneath.
Second, Google Play's auto-conversion handles tax differently from Apple's at the developer-configuration layer. End users on both stores typically see tax-inclusive prices in jurisdictions that require it, but the underlying mechanics (how the developer enters the base price, how each store reports tax in financial reports) differ. The practical implication: if you're trying to make Apple and Google Play prices match precisely for a given country, expect to verify per region rather than trust an automatic alignment.
For why these auto-conversion gaps quietly drag conversion rates and store rankings, see How App Store Pricing Affects Your ASO Rankings. The same dynamics apply to Google Play, since Google Play's algorithm also weighs conversion as a discovery signal.
Where Google Play diverges from the App Store
The practical differences worth keeping in mind:
Currency: Google Play uses local currency for billing in most markets it serves. Apple quotes USD in a handful of smaller territories. If you're manually setting prices, this shows up as Google Play accepting any local-currency string in those markets while Apple sometimes only accepts USD for the same country.
Price flexibility: Google Play accepts arbitrary local-currency prices. Apple snaps to one of around 900 price points per currency. A PPP-adjusted price on Google Play can land exactly on the number your strategy produces; the same price on Apple gets snapped to the nearest tier on the ladder, which can shift it slightly.
Tax handling: Differs at the developer-configuration layer between the two stores. End users typically see tax-inclusive prices on both stores in jurisdictions that require it, but the developer-side mechanics differ. Verify per region if cross-store display alignment matters.
Subscription pricing: Both stores require separate handling for subscriptions. Both stop auto-adjusting subscription prices once they're set. Google Play has additional structure around base subscriptions plus offers (intro pricing, free trials), each with their own country-specific configuration.
Bulk operations: Apple's price-point ladder makes bulk-by-territory manageable through the API. Google Play's removal of Pricing Templates means bulk per-country pricing across products now requires the Play Developer API or external tooling.
The two stores are converging in some ways and diverging in others. The most important thing for an indie dev is to stop treating "App Store pricing" and "Google Play pricing" as one decision. They have different mechanics, different failure modes, and different defaults.
Maintaining Google Play prices over time
Pricing maintenance on Google Play follows the same rhythm as on the App Store. Currencies drift. Tax rules change. Purchasing power shifts. Manually set prices freeze in place while the world moves around them.
The full maintenance argument and the recommended cadence live in Localized Pricing Maintenance: Why Set-and-Forget Doesn't Work. Short version that applies cleanly to Google Play.
Quarterly review of all per-country prices. Sort by country-level conversion rate from the Play Console's statistics dashboard. Investigate any market where CVR has dropped versus the trailing average. Adjust prices that have drifted off-target.
Monthly spot-checks on volatile markets. Turkey, Argentina, sometimes Nigeria and Indonesia. The lira and peso move enough that quarterly is too slow.
Ad-hoc reviews on platform announcements. Google Play also issues periodic policy and tax updates. Subscribe to the Play Console announcements feed and treat each one as a trigger to revisit affected storefronts within a week.
For multi-app catalogs, the bigger structural challenge is that Google Play's removal of Pricing Templates means per-country pricing is now per-product. A quarterly review across 10 apps with 8 in-app purchases each is 80 product-level pricing decisions, every quarter, on Google Play alone. Most indie devs underestimate this work until they're behind on it.
What it adds up to
Google Play in-app purchase pricing has more flexibility than Apple's price-point ladder, and the flexibility cuts both ways. There's no ladder to fall back on, no Pricing Templates to share configurations across products anymore. Every country, on every product, is your call.
If you have a clear pricing strategy of your own, Google Play executes it cleanly. If you don't, the auto-conversion default is roughly equivalent to your home-country price in local currency, which is a defensible launch position and a poor long-term answer.
If you want the localized prices, per-country rounding, and one-tap Google Play push handled for you, PricePush calculates Purchasing Power Parity baselines for 190+ countries, applies your chosen rounding rules per store (Apple and Google can have different patterns), and pushes updates to both stores from one place. Free tier covers one app without a credit card. Paid plans on the pricing page.
Antonio Founder, PricePush
Ready to automate app pricing updates?
PricePush helps you ship localized App Store and Google Play pricing in minutes.
Start Free Trial
