Developer payload has historically been used for various purposes, including fraud prevention and attributing purchases to the correct user. With versions 2.2 and higher 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 in version 2.2 and were removed in version 3.0. Note that your app can continue to retrieve developer payload for purchases made using either previous versions of the library or AIDL.
For a detailed list of changes, see the Google Play Billing Library 2.2 release notes. and Google Play Billing Library 3.0 release notes.
Purchase verification
To ensure purchases are authentic and not forged or replayed, Google recommends
using the purchase token (obtained from the
getPurchaseToken()
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.
Purchase attribution
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.
Use the
setObfuscatedAccountId()
and
setObfuscatedProfileId()
parameters in
BillingFlowParams
and retrieve them using the
getAccountIdentifiers()
method in the
Purchase object.
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
getPurchaseToken
method in the Purchase
object. This data can be persisted by passing the purchase token and metadata
to your backend when your
PurchasesUpdatedListener
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
PurchasesUpdatedListener
is called, your app will discover the purchase once your app resumes and calls
BillingClient.queryPurchasesAsync().
You can then send the values retrieved from the Purchase object's
getPurchaseTime(),
getSku(),
and getPurchaseToken()
methods to your backend server to look up metadata, associate the metadata
with the purchase token, and continue processing the purchase. Note that the
timestamp you initially stored won't exactly match the value from the Purchase object's
getPurchaseTime(),
so you would need to compare them in an approximate way. For example, you can check
if the values are within a certain time period of each other.