Google Play revenue

Google Play does not send a purchase to a URL directly. It publishes a message to a Pub/Sub topic, and a push subscription on that topic delivers it to us. The message is thin -- it names the purchase token and the event, not the price or the buyer -- so we then ask the Play Developer API for the rest, using a service account that has been invited to your Play Console. Three Google-side pieces, and all three have to exist before a single sale books.

There are two ways to provide them, and the app's Revenue tab is where you choose. With the managed setup the topic and the service account are ours: you invite our account and paste our topic, and a Verify button proves both before the first purchase. With your own Google Cloud project you build all three yourself and point the push at your app's notification URL. Both book identically -- the same renewals, refunds, trials and test purchases, through the same code -- so the choice is only about who owns the plumbing, and it can be changed later without losing anything already booked.

There is no shared secret for either webhook, deliberately. The amount, currency and buyer are read from Google's API, never from the notification body, so a forged notification would need a purchase token Google actually resolves -- and resolving one just re-books a real purchase that deduplication then rejects. The managed endpoint additionally accepts only pushes Google signed for our own subscription, and every notification is routed by its packageName to the app whose owner verified it.

• The app is on a Play track (internal testing is enough) and its package name on the App details tab matches the listing exactly.
• Access to the Play Console as an admin (to invite a user). For your own project you also need a Google Cloud project as an editor.
• The app sets obfuscatedAccountId on every purchase -- see your framework's SDK page. Without it sales book, but as unattributed.

On the app's Revenue tab choose Managed by ROAS Sensor. The tab shows a service account email and a topic name; nothing is created in Google Cloud on your side, because Play Console allows the notification topic to live in any Cloud project, and the service account can be invited from any project.

1. 1Play Console → Users and permissions → Invite new users. Paste the service account email from the Revenue tab. Under App permissions add this app and tick "View app information and download bulk reports" and "View financial data, orders and cancellation survey responses". The second is the one revenue depends on; without it Google answers *insufficient permissions* and nothing books.
2. 2Play Console → Monetise with Play → Monetisation setup → Google Play Billing. Turn on real-time developer notifications, paste the topic name from the Revenue tab, choose Subscriptions, voided purchases and all one-time products, Save -- then click Send test notification.
3. 3Back on the Revenue tab, press Verify. It checks that we can read this app's purchases with the account you invited, and that a notification (the test counts) has reached our topic. Each check that fails says which Play Console screen fixes it.

A notification that arrives before you press Verify is held, not dropped, and books the moment verification passes -- so pasting the topic first, the natural order, loses nothing. Only one workspace can verify a given package name; the check that we can read your app is Google confirming you own it.

Choose Your own Google Cloud project on the Revenue tab. You build the topic, the push subscription and the service account, and point the push at the app's own notification URL. The rest of this page is that path.

1. 1Google Cloud → Pub/Sub → Topics → Create topic. Any name, e.g. roas-play-notifications.
2. 2On the topic → Permissions → Add principal: [email protected], role Pub/Sub Publisher. Play Console refuses the topic in step 5 without this.
3. 3On the topic → Create subscription. Delivery type Push -- not Pull, which is the console's default and delivers nothing. Endpoint URL: copy it from the app's Revenue tab (*Or take Google Play revenue directly*). It has this shape:
4. 4Google Cloud → APIs & Services → Enable APIs: enable the Google Play Android Developer API on this project. Without it every purchase lookup fails with SERVICE_DISABLED.
5. 5Play Console → Monetise → Monetisation setup → Real-time developer notifications: paste the topic's full name, projects/<project-id>/topics/<topic>, Save, then Send test notification.

https://api.roassensor.com/api/tracking/webhooks/play/YOUR_PUBLIC_KEY

The test notification proves the whole pipe -- Play → Pub/Sub → us -- before a single purchase exists. We answer it 200 and deliberately book nothing.

A notification acknowledges and Play stops retrying whether or not we could read the purchase. So a missing or under-permissioned service account fails silently: everything looks healthy and nothing books.

1. 1Google Cloud → IAM → Service accounts → Create. Any name, e.g. roas-play-reader. No Cloud IAM role is needed.
2. 2Keys → Add key → JSON. Download the file. This is the credential; treat it as one.
3. 3Play Console → Users and permissions → Invite user: the service account's email address. Under App permissions, add this app and tick "View financial data, orders and cancellation survey responses". Linking the account elsewhere is not enough; without this exact permission Google answers *insufficient permissions*. A fresh grant can take a few minutes to take effect.
4. 4In the panel → Revenue tab → Play service account → Add: paste the whole JSON file. It is saved as a connection on your account -- one service account covers every Android app in the same Cloud project -- and selected for this app.

Play Console → Setup → Licence testing. Accounts listed here purchase with *"Test card, always approves"* and are never charged. The setting is account-wide, not per app. Their purchases arrive flagged is_test, are attributed normally, and are excluded from every reported figure and from the conversions pushed back to your ad accounts.

Test subscriptions run on an accelerated clock (a yearly plan renews every 30 minutes), which is what lets you verify renewals in an afternoon.

Renewals are the revenue. Each one books as its own conversion, with its own order id, and credits the campaign that won the original install.

Two subscription cases need care:

• A free trial books ₹0 / $0 on day one. SUBSCRIPTION_PURCHASED fires when the trial *starts*, and Play reports the plan's price rather than what was charged. The line item's offerPhase names the phase, so the trial period books zero -- still written, still attributed, so trial starts stay countable -- and the first paid period arrives later as its own notification.
• Plan changes issue a fresh purchase token and report the *plan* price rather than the prorated amount actually charged. If your tiers can be switched mid-period, tell us.

Everything the managed setup can get wrong is on the Revenue tab, because both halves of it are checks. Press Verify first -- it names the failing half and the screen that fixes it -- then work down this table.

Anything Play sent while a step above was wrong is not lost. Notifications that arrive before verification are held and booked when Verify passes; after that, a failed delivery is retried by Google for seven days.

Work down in order. Each step points at exactly one fix, and the first three are where every stalled Play integration we have seen was stuck.

If a purchase was made while a step above was wrong, we can re-resolve it once the step is fixed -- ask us, with the time of the purchase.