What should be the developer payload in android in-app billing v3 api?

Question

I am implementing in-app billing in my app to unlock premium features. The in-app billing sets up correctly. Everything seems fine except the 'developer payload' thing.

The sample app says

 /*
     * TODO: verify that the developer payload of the purchase is correct. It will be
     * the same one that you sent when initiating the purchase.
     *
     * WARNING: Locally generating a random string when starting a purchase and
     * verifying it here might seem like a good approach, but this will fail in the
     * case where the user purchases an item on one device and then uses your app on
     * a different device, because on the other device you will not have access to the
     * random string you originally generated.
     *
     * So a good developer payload has these characteristics:
     *
     * 1. If two different users purchase an item, the payload is different between them,
     *    so that one user's purchase can't be replayed to another user.
     *
     * 2. The payload must be such that you can verify it even when the app wasn't the
     *    one who initiated the purchase flow (so that items purchased by the user on
     *    one device work on other devices owned by the user).
     *
     * Using your own server to store and verify developer payloads across app
     * installations is recommended.
     */

The sample app uses an empty string as developer payload. My question is what string to use as a developer payload? Can I use the user's primary email ID?

Answer 1

For me a random string isn't useful as firstly, it needs to be dependent on the user who bought it, not the device it was bought on. Secondly, it's a non-consumable item, so an empty string may suit, but isn't ideal.

So my way around it is to create an encrypted hash based on a key. Each time a purchase is made, it's uniquely identifiable since the hash should never be the same (this depends on the hashing method, such as bcrypt).

Since the key is the same on all the devices, it's easy to decrypt and verify that the secret message is correct.

In order for the key to remain a secret, I've used various string manipulation functions to mask it so it's not stored in a visible manner.

An example of the text maniluation can be found here: Android In App Billing: securing application public key

String Base64EncodedPublicKey key = DecrementEachletter("Bl4kgle") + GetMiddleBit() + ReverseString("D349824");

This method of creating a hash based on a key allows the payload to be unique and identifiable, at the same time as being reasonably secure. It's not bulletproof, but it sure makes it hard to crack.