Google Play rejection
Outside a few regional programs, digital goods sold inside an Android app have to go through Google Play Billing. Physical goods and real-world services stay on Stripe. Most rejected web-wrapped apps simply show their web checkout for a subscription inside the app; here are the three ways to fix that, and what the 2025 and 2026 regional changes do and do not change.
From $109 one-time per platform, or let our team do it all from $698.
Google's Payments policy has a simple core. If users pay for an app or buy digital things inside it (premium features, subscriptions, content, credits or virtual currency, an ad-free version, access to cloud software), the transaction goes through Google Play's billing system, unless an exception or one of Google's regional programs applies. Purchases of physical goods (groceries, clothing, electronics) and physical services (transport, food delivery, gym memberships, event tickets) are exempt and use your own payment provider, such as Stripe. A few other categories are exempt as well, including peer-to-peer payments, online auctions and tax-exempt donations.
The second half of the rule is about steering. Inside the app you may not lead users to another way of paying for digital goods: no links or buttons to a web checkout, no WebView that opens your Stripe page, no wording that encourages buying outside the app, unless a program you are enrolled in allows it. Google explicitly allows consumption-only apps: users log in and use what they paid for elsewhere, as long as nothing can be bought inside the app. For those apps, Google's Payments policy FAQ even allows mentioning other purchase options, as long as there is no direct link.
The Policy status entry cites the Payments policy and usually says that the app offers digital content, features or subscriptions through a payment method other than Google Play's billing system, or that it links users to one. The screenshot is typically your pricing page, an Upgrade banner or the Stripe Checkout page opened inside the app. For a live app the issue can arrive as a warning with a deadline and escalate to a removal if it is not fixed.
| You sell | Inside the Android app | Notes |
|---|---|---|
| A subscription to your app (SaaS plan, Pro tier) | Google Play Billing, or no purchase at all in the app | The most common Payments rejection for vibe-coded apps |
| AI credits, tokens, generations | Google Play Billing (consumable product) | Credits bought on your website can still be used in the app |
| Courses, templates, downloadable content | Google Play Billing | Digital content consumed in the app |
| An ad-free version | Google Play Billing | With the manual API, disableadmob=true turns ads off after the purchase |
| Physical products from your shop | Stripe or your shop checkout | Play Billing is not meant for physical goods |
| In-person services: bookings, cleaning, rides, food delivery, event tickets | Stripe | Physical services are exempt |
| Donations | Depends on the recipient | Tax-exempt donations are exempt; check the policy for your case |
My iOS WebView is finally approved. Thanks!!
The core rule has a growing number of regional exceptions, and this is the part of Play policy that changed most in 2025 and 2026:
What this means for you: these programs are opt-in, come with enrollment, user-interface and reporting requirements, apply only to users in the covered region, and do not make your web checkout fee-free. Until you are enrolled and compliant, treat the core rule as binding, and check Play Console and the Help Center for the current terms before you build anything around them.
WebViewGold triggers Play purchases from your web app: revenuecat://purchase?external_id=…&product=… with RevenueCat, or the manual inapppurchase:// and inappsubscription:// links, plus restoreinapppurchases:// and cancelinapppurchase://. It requires the Extended License; setup is in the Android in-app purchase docs and the RevenueCat guide.
Hide every way to buy digital goods inside the app: the pricing page, upgrade buttons, credit top-ups, the billing portal. Subscribers who paid on your website log in and get everything. It is the fastest fix and needs no new products, but it earns nothing inside the app.
If most of your users are in a covered region and the numbers work, enroll in the matching program, follow its user-interface and reporting rules, and offer the alternative only to eligible users. getstorelocation:// puts the Play Store country into storeLocation, which helps with regional pricing; check how the program defines eligible users before you branch on it.
If you sell physical products or in-person services, keep Stripe. Make sure nothing digital, such as a premium membership or downloads, is sold through the same checkout, because that part needs Play Billing.
Consumption-only takes an afternoon; Play Billing takes a day or two including product setup.
Pricing pages, upgrade banners, paywalls, buy-more-credits buttons, the Stripe customer portal, links in emails that open inside the app, and server redirects to Checkout after sign-up or when a trial ends. The reviewer will find the one you forget.
Set USER_AGENT in Config.java to the default user agent plus a token such as WebViewGoldApp, and check for it in the browser and on the server, so you can switch off redirects as well as buttons. The Stripe vs in-app purchase guide shows the full pattern.
Digital products: Play Billing or hidden. Physical products and services: Stripe. Write the decision down; your iOS app needs the same list, and Apple's rules differ (see the Guideline 3.1.1 guide).
The custom CSS file of the Android project applies only inside the app (custom CSS and JavaScript), so you can hide pricing and checkout elements there without touching your website, as shown below. Server-side redirects to Stripe need the user agent check.
Create the products in Play Console, connect RevenueCat or use the manual links, give purchases a successful_url that unlocks the account on your server, and test with license testers before you submit.
Opening the Stripe page in Chrome through EXTERNAL_LINK_HANDLING_OPTIONS or BROWSER_WHITELIST does not help. A link from the app to a web checkout for digital goods is still steering, wherever it opens.
Give the review account in Sign-in details the paid entitlement, describe in the instructions how paying works in the app (Play Billing or consumption-only), upload the new version and reply in Policy status.
Goes into the custom CSS file of the WebViewGold Android project. The selectors are examples; use the classes and IDs your web app really uses.
/* Hide every way to buy digital goods inside the Android app */
.pricing-table,
.upgrade-banner,
.buy-credits-button,
a[href*="checkout.stripe.com"],
a[href*="billing.stripe.com"],
a[href$="/pricing"] {
display: none !important;
}For the consumption-only route. The agent changes only what the app sees and leaves your website checkout alone.
My web app runs inside an Android app built with WebViewGold. Google Play rejected it under the Payments policy because the app sells [our Pro subscription / AI credits] through Stripe. The app sends a custom user agent that contains 'WebViewGoldApp'. When a page or request comes from the app: - Hide every pricing page, upgrade button, paywall, credit top-up and link to Stripe Checkout or the Stripe customer portal for digital products. - Remove server-side redirects to Stripe after sign-up or when a trial ends; show the normal app instead. - Show no text that encourages buying on the website, and no links to it. - Keep the checkout for physical products [list them, or write: none] unchanged. - Users who subscribed on the web keep full access after logging in. Outside the app, change nothing. List every payment entry point you found and every file you changed, so I can check each one on a phone.
Yes. Google regulates what happens inside the app. Your website, your emails and your marketing can sell any way you like, and people who subscribed there can log in to the app and use everything.
For US users Google no longer requires Play Billing and allows links to outside offers, but it handles this through its US alternative billing and external content links programs, with enrollment, reporting and service fees. Read Google's US help page and enroll before you ship a Stripe button to US users, and keep it away from users in other countries.
Usually because something digital is also for sale, such as a membership with app perks, digital downloads or a subscription for app features, or because the screens make it look like one. Check every product a reviewer can reach in the app.
No. WebViewGold also has manual links for one-time purchases and subscriptions. RevenueCat is useful when you sell on iOS and Android and want one place for entitlements and webhooks.
Yes. Using in-app purchases in an end product requires the WebViewGold Extended License, as the in-app purchase documentation states.
The principle is similar, but Apple's rules, exceptions and recent US changes differ in detail. Handle each store separately; the App Store side is covered in the Guideline 3.1.1 guide.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main page$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demo$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.