# Monetization

> Ads, web payments, digital goods, subscriptions, and affiliate links for a PWA, and which store or ad-network policy governs each on the web and in a store.

A PWA earns money through advertising, web payments, digital goods, subscriptions, or
affiliate links, and the rule that governs each path depends on the channel, not on the code:
the same checkout is unrestricted when the app is installed from the browser and subject to
Google Play's billing policy when the same origin ships inside a Trusted Web Activity.

## How it works

Store policies attach to the package, not to the origin. The browser-installed copy of your
PWA is bound only by the ad network's and payment provider's terms; the Play or Microsoft Store
copy of the same origin inherits that store's payments section as well.

### Advertising

Google's AdSense Program policies (last updated 2026-08-04) allow AdSense code on web pages and
forbid it when "integrated into a software application (does not apply to AdMob) of any kind,
including toolbars". The same policy lists the viewing frames in which web ads may be shown
from inside an app: on Android, "Chrome Custom Tabs and Trusted Web Activities"; a plain
`WebView` must instead register through the WebView API for Ads with the Google Mobile Ads SDK.
A PWA installed from the browser is a web page rendered by that browser, so the web rules
apply; a TWA is a named frame; a native shell around a `WebView` falls under the SDK path.
Network-by-network detail is on [Ad networks](/ecosystem/ad-networks/).

### Web payments

On the open web a PWA charges through the [Payment Request API](/compatibility/payment-request/),
a wallet (Apple Pay, Google Pay), or a provider's JavaScript SDK, and no store takes a share.
The trade-off is that the browser, not a store, decides which payment methods exist: Firefox
ships Payment Request disabled behind `dom.payments.request.enabled`, and Safari surfaces only
Apple Pay through it. The method coverage is on [Payments](/ecosystem/payments/).

### Digital goods inside a store build

Google Play's Payments policy, section 2, requires Google Play's billing system for apps
"requiring or accepting payment for access to in-app features or services" unless sections 3,
8, or 9 apply; section 3 lists physical goods, physical services, bills, peer-to-peer payments,
and gambling as out of scope. Inside a TWA the web page reaches Play billing through the
[Digital Goods API](/reference/capabilities/digital-goods/) in Chrome 101 and later: the page
calls `window.getDigitalGoodsService('https://play.google.com/billing')`, then passes the same
string as `supportedMethods` to `PaymentRequest` with `{ sku }` as method data. The Microsoft
Store is narrower: policy 10.8.1 (version 7.20, effective 2026-10-22) requires the Store
in-product purchase API only for games and for products on Xbox consoles; other PC products may
use "a secure third-party purchase API". Apple's guideline 3.1.1 requires in-app purchase for
unlocking features, but it applies to App Store apps, and a PWA has no App Store route.

### Subscriptions and affiliate links

A subscription is "subscription services" in Play's list of purchases that require Play
billing, so a TWA must sell it through the Digital Goods API, while the browser-installed copy
keeps using the provider's recurring billing. Affiliate links need no API, and the limit is a
policy one: Play's Spam policy rejects apps "whose primary purpose is to drive affiliate traffic
to a website", so a TWA whose main content is outbound deals is a listing risk even though the
same page is fine as a browser install.

| Path | Browser install | Trusted Web Activity (Play) | Microsoft Store package |
|---|---|---|---|
| Advertising | AdSense web rules | AdSense web rules (named frame) | AdSense web rules |
| One-off digital goods | Any PSP | Play billing via Digital Goods API | Any secure PSP unless a game |
| Subscriptions | Any PSP | Play billing via Digital Goods API | Any secure PSP unless a game |
| Physical goods | Any PSP | Any PSP (Payments policy §3) | Payment request or third-party API (10.8.2) |
| Affiliate links | No rule | Spam policy if primary purpose | 10.1.1 accurate representation |

## Observed behaviour

:::observed
Chrome's Play Billing guide (updated 2021-01-26) states that `getDigitalGoodsService` is
`undefined` on a page served over `http`, and that outside a Play-installed TWA the call
rejects unless the flag `chrome://flags/#enable-debug-for-store-billing` is enabled on an
Android 9 or later device in developer mode. Enabling billing in Bubblewrap 1.8.2 or later is
one edit to `twa-manifest.json`, `"features": { "playBilling": { "enabled": true } }`, followed
by `bubblewrap update` and `bubblewrap build`.
:::

The same guide notes two costs of the Play path: `paymentDetails.total` is required by
`PaymentRequest` but ignored by Play billing, and a purchase that the backend does not
acknowledge is refunded and revoked after three days.

## See also

- [Google Play Payments policy](https://support.google.com/googleplay/android-developer/answer/9858738) (support.google.com)
- [AdSense Program policies](https://support.google.com/adsense/answer/48182) (support.google.com)
- [Receive payments via Google Play Billing with the Digital Goods API](https://developer.chrome.com/docs/android/trusted-web-activity/receive-payments-play-billing) (developer.chrome.com)
- [Payments](/ecosystem/payments/)
- [Ad networks](/ecosystem/ad-networks/)
- [Digital Goods API](/reference/capabilities/digital-goods/)
- [Monetize a PWA](/guides/monetization/)

← Back to the [Ecosystem](/ecosystem/) overview.