Google Play revenue

Google Play does not send a purchase to a URL directly. It publishes a message to a Pub/Sub topic in your Google Cloud project, 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 you grant. Three Google-side pieces, and all three have to exist before a single sale books.

There is no shared secret for this 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 endpoint also refuses any notification whose packageName is not this app's.

• 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 and to a Google Cloud project as an editor. The Cloud project must be the one linked under Play Console → Setup → API access (link one there if none is).
• The app sets obfuscatedAccountId on every purchase -- see your framework's SDK page. Without it sales book, but as unattributed.

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.

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.