CODEWITHSUNDEEP
androidin-app-billingpayload
user1300214
user1300214

Reputation:

Developer payload and server back-end interaction (Google In App Billing)

Is the following approach necessary and/or best practice?

  1. In my client call a back end server end point getRandomString with a sign in token to uniquely identify the user.
  2. The server generates a random string and adds it to the user's list of available random strings
  3. The client uses this random string as the developer payload.
  4. When I come to verify the purchase token on the server I check that the developer payload is one in the users "random string" array.
  5. If it's in the list, remove it, and validate the purchase, otherwise decline validation.

I can't find much in the way of guidance on this either in Google Docs, or on SE or posts seem to be from 5 years ago.

Is the above approach the right way to go. And also, is using developer payload actually necessary?

Upvotes: 0

Views: 1666

Answers (1)

user1300214
user1300214

Reputation:

I think I've identified the source of the confusion on Developer Payload now. Years back when I was coding with InAppPurchasing developer payloads was an additional parameter in the launchPurchaseFlow function, but the new Billing Library with its launchBillingFlow does not support the developer payload any more. It is apparently now classed as a legacy field. See here for example. And in this Google post, we have confirmation:

Hi

The field developerPayload is a legacy field, kept to maintain the compatibility with old implementations, but as mentioned on Purchasing In-app Billing Products page (https://developer.android.com/training/in-app-billing/purchase-iab-products.html), this field isn't always available when completing tasks related to In-app Billing. And since the library was designed to represent the most updated development model, we decided to don't support developerPayload in our implementation and we have no plans to include this field into the library.

If you rely any important implementation of your in-app billing logic on the developerPayload, we recommend you change this approach, because this field will be deprecated at some point (or soon). The recommended approaches is to use your own backend to validate and track important details about your orders. For more details, check the Security and Design page (https://developer.android.com/google/play/billing/billing_best_practices.html).

Thanks

Upvotes: 1

Related Questions