How to Monetize a PWA: Ads, Payments and Play Billing

How do you monetize a PWA?

You monetize a progressive web app (PWA) the same way you monetize a website, plus one extra set of rules for each app store you ship it to. On the web you can show ads such as AdSense, sell subscriptions or items with a payment provider such as Stripe, and add an offerwall where users earn your in-app currency. When you list the PWA on Google Play as a Trusted Web Activity (TWA), digital goods sold inside it must go through Google Play Billing unless an exception or an enrolled program applies. On iPhone, a PWA lives on the Home Screen outside the App Store, so Apple’s purchase rules only matter if you wrap it as a native app.

Policies below were checked on October 29, 2026. Store payment rules changed several times in 2025 and 2026, so read the live pages before you launch.

PWA monetization options at a glance

The same PWA code can run in a browser, on Google Play as a TWA, and on the iOS Home Screen. The rules differ in each.

Most PWAs combine two or three. How to monetize a tool website shows that mix for utility sites, and How to monetize an HTML5 web game covers browser games.

Web ads in a PWA

An installed PWA is still your website, so AdSense code works as it does in a browser, under the usual approval and placement rules. If AdSense turns you down, How to monetize a website without AdSense lists alternatives.

What about the Android package? The AdSense Program policies answer it under technical requirements for web content viewing frames for apps: besides the WebView API for Ads, they list “Chrome Custom Tabs and Trusted Web Activities” as supported viewing frames on Android. AdSense code still may not go in pop-ups, emails or software.

Two rules matter for apps that also reward users:

• The AdSense policies say that, except for rewarded inventory, publishers may not “compensate users for viewing ads or performing searches.” Never give coins for viewing or clicking normal display ads.
• Once the PWA is on Google Play, Play’s Ads policy also applies. It says “We consider ads and associated offers as part of your app,” bans interstitials that appear unexpectedly, and bans full-screen interstitials that cannot be closed after 15 seconds. Opt-in rewarded ads are exempt from the interstitial rules.

Taking payments on the web with Stripe

In the browser, no store sits between you and your users, so you can sell subscriptions, credits or products with any payment provider. Stripe’s Checkout documentation offers a full payment page (hosted by Stripe or embedded), an embedded form, and custom Elements, for one-time payments and subscriptions. Three details matter:

• Fulfill from the webhook. Stripe’s fulfillment guide says webhooks are required, because a customer can pay and lose their connection before your landing page loads. Listen for checkout.session.completed (and checkout.session.async_payment_succeeded for delayed methods), and make your fulfillment safe to run more than once for the same session.
• Register your domain for wallets. To use Apple Pay, Google Pay or Link in Elements or the embedded form, Stripe asks you to register the domain that shows them.
• Keep the balance on the server. Premium status and coins belong in your database, not in localStorage. Offerwall rewards reuse this.

Google Play Billing in a Trusted Web Activity

Android’s Trusted Web Activities overview describes a TWA as a way to open your own web app from your Android app using a protocol based on Custom Tabs. The user’s browser renders it full screen, and Digital Asset Links verify that app and site share a developer. Bubblewrap and PWABuilder generate the project.

What Google Play’s Payments policy requires

Play’s Payments policy, in short:

• Charging for in-app features, content or services (virtual items, subscriptions, an ad-free version) requires Google Play’s billing system unless an exception or program applies.
• Physical goods, peer-to-peer payments and some other categories must not use Play Billing.
• No steering users to other payment methods through buttons, links or messages, except under the alternative billing and external content links programs in eligible regions.
• In-app virtual currencies may only be used within the app or game title they were bought for.

The United States is a special case. Google’s update for developers serving US users says that from October 29, 2025, Google will not require Google Play Billing for US users, while its programs and fee reporting apply to developers who enroll. The page changed several times in 2026, including after a new settlement with Epic, so read it in full first. Checked on October 29, 2026.

How Play Billing works in a TWA

Chrome’s guide to receiving payments with Google Play Billing in a TWA (updated October 15, 2026) opens with the plain rule: “Apps on Google Play that sell digital goods or subscriptions must use Google Play Billing.” Your code uses the Digital Goods API to read products and purchases and the Payment Request API to buy. You need Chrome 101 or later, a Google Payments merchant account linked to Play Console, products set up there, a release on at least an internal testing track, and playBilling turned on in twa-manifest.json. One codebase can serve both channels. Adapted from the guide’s feature check:

if ('getDigitalGoodsService' in window) {
  try {
    const service = await window.getDigitalGoodsService('https://play.google.com/billing');
    // Play Billing is available: sell through Google Play
  } catch (e) {
    // Google Play Billing isn't available. Use another payment flow.
  }
}

Inside the Play build, users buy through Play; in the browser, the same button opens Stripe. Verify and acknowledge each purchase token on your backend: unacknowledged purchases are refunded and revoked after three days.

Apple’s limits on PWAs

iPhone and iPad run PWAs as Home Screen web apps, with limits:

• No install prompt. web.dev’s PWA installation guide says there is no browser prompt to install a PWA on iOS and iPadOS: users add it through Share, then Add to Home Screen, so show an in-page hint. Since iOS and iPadOS 26, WebKit says every site added to the Home Screen opens as a web app by default.
• Push only after install. WebKit’s Web Push for Web Apps on iOS and iPadOS post says push arrived for Home Screen web apps in iOS 16.4, and a web app may only ask for permission in response to a direct user action such as tapping a button. Push only reaches iOS users who installed the app.
• No thin wrappers. Apple’s App Review Guidelines (4.2) want apps to go “beyond a repackaged website.”
• In-app purchase in a native app. Guideline 3.1.1 requires in-app purchase to unlock features such as subscriptions and in-game currencies. On the US storefront, apps may link to other purchase methods; elsewhere that needs an entitlement. Checked on October 29, 2026.

So on iOS, most PWAs earn through the web: ads, Stripe and an offerwall all work in a Home Screen web app, because it is your website, not an App Store app. For a native iOS app, read Offerwalls in iOS apps: App Store rules first.

The offerwall path for a PWA

An offerwall lets users earn your in-app currency by completing advertiser offers, such as trying an app or a survey, and pays you per completed offer. It fits PWAs with accounts and something worth earning, such as credits in an AI tool or coins in a web game. What is an offerwall? explains the model.

Sharklio has SDKs for Android, iOS, Unity, Flutter and React Native. There is no dedicated PWA SDK, and you do not need one, because the offerwall is a web page. Use one of two web integrations:

• The floating Earn button. One script tag shows a corner button that opens the offerwall in a pop-up over your app. Add a floating Earn button to any website covers the options.
• The signed iframe. Give the wall its own Earn screen. For React or Next.js, the Next.js and React offerwall guide shows the server route and component.

Both use the same link, built on your server for the signed-in user. From the Offerwall link docs:

<iframe title="Offerwall" src="https://wall.sharklio.com/{APP_ID}?user_id={USER_ID}&amp;hash={HASH}"
  style="border:0;width:100%;height:100vh"></iframe>

The hash is an HMAC-SHA256 of the user ID with your link hash salt. Build it on your server; the salt must never reach your JavaScript bundle or service worker. The docs add a rule that matters here: the wall only loads inside frames and pop-ups on https pages of the website you registered for the app and its subdomains. A PWA served from that domain qualifies, and so does its TWA, because Chrome renders your own site. For a PWA wrapped in a WebView shell instead, see how to open an offerwall in a WebView safely.

Credit users from the postback, never from the page

Sharklio sends a signed server-to-server postback to your server for every credit and every reversal. Your handler checks the hash, credits each transaction ID once, takes rewards back on reversals, and answers with a 2xx code. What is a postback URL? explains the flow, and the Node.js postback guide has a working handler.

Your PWA just reloads the balance from your server when the pop-up closes or the app returns to the foreground. Cache your app shell offline, but never the balance or the offerwall link.

Rewards inside a TWA on Google Play

Earning currency from offers is not a purchase, and Play’s Payments policy does not mention earning currency. Other Play policies still apply to a TWA’s rewards feature:

• No rewards for ratings, reviews or installs as the core feature. Play forbids incentivized ratings and reviews and apps whose main function is rewarding installs of other apps. Incentivized installs and Google Play policy walks through the pages that apply.
• Your app needs its own purpose. Play’s Spam policy bans apps whose primary purpose is to drive affiliate traffic to a website, and webviews of a website without the owner’s permission. A TWA of your own useful PWA with an Earn screen is fine. A TWA that is just an offerwall is not.
• Selling the same coins still needs Play Billing. If users can also buy the currency they earn, the purchase side follows the Payments policy above.
• Declare the data. Google’s Data safety guide counts data collected from a webview opened from your app. A TWA is not a WebView, but it opens your own content, so declare what your PWA and its offerwall collect.
• Audience. Sharklio requires end users to be at least 16, with parental permission under 18, so keep the Earn screen away from younger users and out of apps aimed at children.

Users on VPNs, proxies, Tor or data center networks are blocked from the wall, so it does not fit VPN or proxy apps.

How to add Sharklio to your PWA

Setup is the same whether users open your PWA in a browser, from the Home Screen, or from Google Play.

1. Apply as a publisher at sharklio.com. Applications are reviewed by hand; once approved, apps you add are live right away.
2. Add your PWA as an app with its https domain. Set the currency name, icon, conversion rate, user split and wall design in the live preview.
3. Add an endpoint behind your sign-in that returns the signed offerwall link for the current user, then show it with the floating Earn button or an iframe on your Earn screen, as described in the Offerwall link docs.
4. Save your postback URL and credit users only from the signed postback, including reversals, following the Postbacks docs.
5. Use Open as a test user and Send a test postback in Integration status on the Integration tab, then open the wall in your TWA build and as a Home Screen web app on a normal mobile connection. Test your app before launch has the full checklist.
6. Put the Earn entry in your main navigation, next to the balance (see offerwall placement).

Frequently asked questions