Most developers lose money not because their app is bad, but because their monetization is configured wrong. A missing merchant account, a misconfigured subscription base plan, or an AdMob SDK without the right consent flow can silently turn off revenue for weeks. This tutorial walks through the complete Google Play monetization setup — IAP, subscriptions, and AdMob — the way it should be done in 2026.
By the end, you will have a working payment pipeline: products defined in Play Console, the Play Billing Library wired into your app, ad units serving real ads, and a test workflow that proves everything works before your first user pays you.
Step 1: Complete Your Merchant Account Before Anything Else
The #1 reason monetized apps fail is an incomplete payments profile. Play Console will not let you create products, and your app will not earn a cent, until your merchant account is fully verified. This includes:
- Tax information: Your W-8BEN (non-US) or W-9 (US) form filed, and — for non-US developers — your US Tax PIN requested. Your first payout is held until the PIN arrives by mail, which takes 2-4 weeks.
- Bank account: A valid payout bank account in a supported country, with the exact legal name matching your developer account.
- Identity verification: Personal or organization documents matching the account holder name.
Pro tip: Complete tax + bank setup the same day you create your developer account. Do not wait until your app is ready — payment profile verification has no "rush" path, and it blocks product creation entirely.
Step 2: Create Your Products in Play Console
Once the merchant account is verified, open Monetize → Products in Play Console and create two types of items:
In-App Products (one-time)
- Product ID must be lowercase, and it becomes permanent — you cannot delete it later, only deactivate it. Choose carefully, e.g.
coin_pack_100. - Set price, or leave it unset and price it per-country in the pricing template for finer control.
Subscriptions
Subscriptions in 2026 use the base plan + offer structure, which replaced the old "subscription with phases" model:
- Create a base plan per price point — e.g.
monthly,yearly. A base plan cannot be edited after creation; you clone it instead. - Attach offers to base plans for free trials (
trial_7d), intro pricing, or win-back discounts. Offers can be edited later, base plans cannot. - Set the renewal grace period (default 7 days) and enable Account Hold so users keep access during payment retries.
- In 2026, Google also requires you to declare subscription cancellation mechanics clearly in your store listing — do this in the app content section.
Step 3: Integrate the Play Billing Library
Your app talks to Google Play through the Play Billing Library. The 2026 baseline is Billing Library 7.x, which requires an updated targetSdk and Kotlin-first APIs. The core flow:
- Add the dependency to your
build.gradle:com.android.billingclient:billing-ktx:7.x.x - Connect a
BillingClientwithPendingPurchasesParamsenabled — required to recover purchases made while the app was closed or on another device. - Query products with
queryProductDetailsAsync()using your product IDs. - Launch purchase with
launchBillingFlow(), passing theBillingFlowParams. - Handle the purchase result in
onPurchasesUpdated(), acknowledge every purchase withacknowledgePurchase()— unacknowledged purchases are auto-refunded after 3 days. - For subscriptions, listen to
onPriceChangeConfirmation()for price increases, and usequeryPurchasesAsync()on every app start to restore entitlements.
Do not build your own payment layer on top of Google Play billing — policy requires all digital goods to use Play's billing system, and bypassing it (external payment links, own SDKs) is a top suspension trigger in 2026.
Step 4: Add AdMob the Compliant Way
Ads are the second revenue stream, and AdMob integration has three non-negotiable parts in 2026:
- SDK + manifest: Add the AdMob SDK, configure your
AdMob App IDinAndroidManifest.xml, and create ad units in the AdMob console. Banner, interstitial, rewarded, and native each need their own unit ID. - Privacy manifest & data safety: AdMob's SDK collects identifiers, so your app's Data Safety form must declare it, and the SDK must appear in your privacy manifest audit. Apps with undeclared ad SDKs face enforced removal in 2026 — this is now automated.
- Consent: If you serve ads in the EEA/UK, you must use a certified consent management platform or Google's UMP (User Messaging Platform) SDK, and pass consent to AdMob before loading ads. Serving personalized ads without valid consent is a direct policy violation.
Testing is free: Use test ad unit IDs (ca-app-pub-3940256099942544/6300978111 for banner, etc.) during development — real ads to a test device risk an AdMob account ban for invalid traffic.
Step 5: Wire Up Your Backend (Receipt Validation)
For anything beyond a casual app, validate purchases server-side. Use the Google Play Developer API (purchases.products.get / purchases.subscriptions.get) to confirm purchase state on your backend, and use Real-time Developer Notifications (RTDN) via Pub/Sub to track subscription events — renewals, cancellations, and price changes — without polling.
This is also where you attach entitlements: grant premium features, update the user's ad-free status, or extend subscription access in your own database. Never grant entitlements from client-side data alone — it is trivially spoofable.
Step 6: Test Everything Before Launch
Monetization code that works in production is rare without a structured test pass. Set up:
- License testing: Add test accounts (up to 20) under Setup → License testing — testers can buy with test cards and never get charged.
- Internal testing track: Roll out the app to your testers, then buy every product, cancel a subscription, restart the app, and confirm entitlements restore.
- AdMob test ads: Enable test mode and verify each ad format renders correctly.
- Purchase recovery: Uninstall the app mid-purchase, reinstall, and confirm the pending purchase is recovered and acknowledged.
Common 2026 Pitfalls to Avoid
- Payment hold at first payout: Almost always the US Tax PIN not yet received. File tax forms the day you register, not the day you earn.
- Undeclared ad SDK: AdMob must be in your Data Safety form and privacy manifest before submission — retroactive fixes trigger full re-review.
- Unacknowledged purchases: Missing
acknowledgePurchase()= automatic refunds after 3 days. This is the most common "revenue leak" in new billing integrations. - Editing a base plan: You cannot. Plan for price changes by cloning the base plan and deprecating the old one, and always announce price changes 30 days ahead via Play Console.
Final Checklist
- Merchant account verified: tax form + bank + identity
- US Tax PIN requested (non-US developers)
- IAP product IDs created and priced
- Subscription base plans + trial offers configured
- Billing Library 7.x integrated, purchases acknowledged
- AdMob SDK declared in Data Safety, consent flow added for EEA
- Server-side validation + RTDN webhooks live
- License testers passed full purchase flow
Monetization setup is a one-time 3-day task that decides your revenue for the next 3 years. Do it in this order, test it end-to-end, and your first payout will arrive without drama. Skip a step, and you will find out three weeks after launch — the hard way.