Developer payload has historically been used for various purposes, including fraud prevention and attributing purchases to the correct user. With version 2.2 of the Google Play Billing Library, intended use cases that previously relied on developer payload, are now fully supported in other parts of the library.
With this support in place, we have deprecated developer payload, starting with version 2.2 of the Google Play Billing Library. Methods associated with developer payload have been deprecated and will be removed in a future library release. Note that your app can continue to retrieve developer payload for purchases made using previous versions of the library or via AIDL.
For a detailed list of changes, see the Google Play Billing Library 2.2 release notes.
To ensure purchases are authentic and not forged or replayed, Google recommends
using the purchase token (obtained from the
method in the
Purchase object) along
with the Google Play Developer APIs to verify purchases are authentic.
For more information, see
Fight fraud and abuse.
Many apps, particularly games, need to ensure that a purchase is correctly attributed to the in-game character/avatar or in-app user profile that initiated the purchase. Starting with Google Play Billing Library 2.2, your app can pass obfuscated account and profile identifiers to Google when launching the purchase dialog and have them returned when retrieving a purchase.
Associate metadata with a purchase
Google recommends storing metadata about a purchase on a secure backend
server that you maintain. This purchase metadata should be associated with the
purchase token obtained using the
method in the
object. This data can be persisted by passing the purchase token and metadata
to your backend when your
is called after a successful purchase.
To ensure metadata is associated in the case of purchase flow interruptions, Google recommends storing the metadata on your backend server prior to launching the purchase dialog and associating it with your user’s account ID, the SKU being purchased, and the current timestamp.
If the purchase flow is interrupted before your
is called, your app will discover the purchase once your app resumes and calls
You can then send the values retrieved from the
methods to your backend server to look up metadata, associate the metadata
with the purchase token, and continue processing the purchase.