Add real-time developer notifications

Overview

Google Play Billing provides server push notifications that let you monitor
state changes for Play-managed subscriptions. By enabling Real-Time Developer
Notifications, you'll receive a purchase token directly from Cloud Pub/Sub
anytime there is an update to an existing subscription.

Real-time developer notifications do not provide full information about the
state of the subscription, such as whether the user is currently entitled to
access subscription content. When you receive the token, you should always use
the purchase token to query the
Google Play Developer API to get the full
information and update your backend with the user's current entitlement status.

Notification types might change in the future. You should be able to handle
unrecognized notifications types, and you should always rely on the Google
Play Developer API for critical business logic.

Setup Cloud Pub/Sub

Cloud Pub/Sub is a fully-managed real-time
messaging service allowing you to send and receive messages between
independent applications. It delivers low-latency, durable messaging that helps
you quickly integrate systems hosted on the Google Cloud Platform
and externally.

Google Play Billing uses the Cloud Pub/Sub
to publish push notifications on topics to which you subscribe.

Establish prerequisites

To receive the push notifications, you must create secure backend server to
consume the messages sent to your topic. Your server can use the
Cloud Pub/Sub Client Libraries
libraries to consume the messages.

Create a topic

To start receiving the notifications, you need to create a topic to which the
Google Play Billing should publish the notifications. To create a topic:

Enable real-time developer notifications for your app

Scroll to the Real-time developer notifications section at the bottom of
the page.

Figure 4. Real-time developer notifications section.

In the Topic name field, enter the full Cloud Pub/Sub topic name that you
configured earlier. The topic name should be in the format of projects/{project_id}/topics/{topic_name} where project_id is
the unique identifier for your project and topic_name is the name of the topic
created earlier.

Click Send Test Message to send a test message. Performing a test publish
helps ensure that everything is setup and configured properly. If the test
publish succeeds, a message is displayed stating that the test publish was
successful. If you have a subscriber running for this topic, it should receive
this test message.

If the publish fails, an error is shown. Ensure that the topic name is
correct and that
google-play-developer-notifications@system.gserviceaccount.com
service account has Pub/Sub Publisher access to the topic.

Click Update Topic.

Change topic name

To change the topic name without dropping messages, perform the following steps:

Create and configure the new topic and subscription.

Begin reading and processing messages published to the new topic.

Update the topic name for that app in the Play Console.

Using Stackdriver or the Cloud Developer Console, wait for the old topic to
stop receiving messages while ensuring the new topic is receiving messages.

Delete a topic

Note: Deleting the topic in Pub/Sub before removing the
name can result in dropped messages. You must re-setup the topic using Pub/Sub
to fix this issue.

Scale notification processing

Due to the variety of notifications that can potentially be sent to the Pub/Sub
topic, it may not be practical for you to have a single binary processing of all
the notifications. There are variety of options to research when deciding how
to scale your notification processing. These options include:

Using push and pull style notifications.

Setting up multiple subscriptions for a topic.

Republishing the notification message to other Pub/Sub projects.

For example, a single subscription can have multiple processes pulling messages
from that subscription. The messages from that subscription is divided
between the readers automatically. Each of these processes can then process the
notification or route the request to a more specialized service.

New notification types may be added over time. Subscribers should be ready to
gracefully handle new notifications if they appear, usually by acknowledging the
received message.

Note: If you choose to use a push subscription, register your
endpoints before adding the push endpoint. For more information, see
Registering endpoints

Monitor notification traffic

To monitor notification traffic, use the Google Stackdriver
service. This service allows you to monitor traffic on a topic and
set up alerts for certain conditions. For example, you can alert if your
unacknowledged message count is too high (likely meaning there is a problem with the
subscribers) or if the publish count is too low (likely meaning there is an
issue publishing to the topic).

Determine pricing and quotas

Estimate data usage

The data portion of the subscription notification is approximately 1KB of data
per request. Each publish and pull require a separate request, or approximately
2KB of data per notification. The number of notifications per month depends
on your billing cycle and your users' behavior. You should expect at least
one notification for each user during a billing cycle.

SLA

The real-time developer notifications service does not offer an official
latency SLA. However, most notifications should be published within a few
seconds of the event occurring. You should monitor usage metrics on your
Stackdriver page, such as number of unacknowledged Messages, to ensure you are
processing all messages in a timely manner.

JSON Specification

Each publish made to a Pub/Sub topic contains a single base64-encoded
DeveloperNotification with the following fields: