What is the purpose of the “developer payload”? Wh

问题:

The Android docs say that its meant for "supplemental information about an order" but at the same time it also says not to use this to send "actual data or content".

So what is the purpose of this "developer payload"? Why does this feature exist? Can you describe a real-world practical example of how I can use it in my own In-app Billing implementation?

回答1:

As aromero mentioned the developer payload field is limited in size. This is why the docs recommend not to use this key to send data or content.

What you do instead is save the content to a database somewhere (e.g. on the user's device or your own server), and then put the record's index in the developer payload field. When you receive it back via the PURCHASE_STATE_CHANGED broadcast intent, you can associate it with the data in your database.

Note that the developer payload is not sent by the Market when using any of the test android item ids. You have to be using real in app purchase items.

Also, according to this (I have not verified this yet), you will not be receiving the developerPayload in DEBUG MODE. You need to sign your application to RELEASE MODE to receive developerPayload.

Lastly, as you commented below, the returned JSONObject (in response to GetPurchaseInformation) already includes orderId, productId, purchaseTime and more. So "developer payload" should actually be used for anything but to identify the purchase... i.e. the answer is the opposite of what has been suggested below. What you can use "developer payload" is to add some information not in the JSONObject, like purchaser's additional details (e.g. GPS location if enabled, device brand & model, etc.).

回答2:

The accepted answer is misleading and the last paragraph is plain wrong. Here's what the official documentation has to say about it.

You should pass in a string token that helps your application to identify the user who made the purchase, so that you can later verify that this is a legitimate purchase by that user. For consumable items, you can use a randomly generated string, but for non-consumable items you should use a string that uniquely identifies the user.

When you get back the response from Google Play, make sure to verify that the developer payload string matches the token that you sent previously with the purchase request. As a further security precaution, you should perform the verification on your own secure server.

The payload may help you prevent to identify users who circumvented Google Play Service API or your app somehow by sending the payload to your server where you can check whether this user ever purchased the item. Presumably circumventing the GPS will get your app fooled with the purchase certificate. But if you have all the user IDs of people who actually did honestly purchase the item saved on your server - it would be easy to validate the purchase based on the user ID. The problem here - google made it impossible to rely on it unless you have all your users "logged in" in some way.

回答3:

The docs provide a real example:

A developer-specified string that can be specified when you make a REQUEST_PURCHASE request. This field is returned in the JSON string that contains transaction information for an order. You can use this key to send supplemental information with an order. For example, you can use this key to send index keys with an order, which is useful if you are using a database to store purchase information. We recommend that you do not use this key to send data or content.

You can use this field to identify the item the user is purchasing. When you issue a REQUEST_PURCHASE request you can put additional information using DEVELOPER_PAYLOAD. When you get the response from PURCHASE_STATE_CHANGED you'll get this info back in the developerPayload field, so you can identify the order.

This field is limited to 256 chars and it's unencrypted (you can verify the signature though), it's not meant to store actual content.

回答4:

I hope this will help:

Security Recommendation: When you send a purchase request, create a String token that uniquely identifies this purchase request and include this token in the developerPayload.You can use a randomly generated string as the token. When you receive the purchase response from Google Play, make sure to check the returned data signature, the orderId, and the developerPayload String. For added security, you should perform the checking on your own secure server. Make sure to verify that the orderId is a unique value that you have not previously processed, and the developerPayload String matches the token that you sent previously with the purchase request.

More information here.