在 Android 中销售应用内产品的培训课程建议在发出购买请求时使用有效负载：
第五个参数包含一个“开发人员有效负载”字符串，您可以使用它来发送有关订单的补充信息（它可以是一个空字符串）。通常，这用于传递唯一标识此购买请求的字符串令牌。如果您指定字符串值，Google Play 会将此字符串与购买响应一起返回。随后，当您查询此次购买时，Google Play 会返回此字符串以及购买详情。
安全建议：最好传入一个字符串，以帮助您的应用程序识别进行购买的用户，以便您以后可以验证这是该用户的合法购买。对于消耗品，您可以使用随机生成的字符串，但对于非消耗品，您应该使用唯一标识用户的字符串。
实施 IAB 购买页面有类似的建议，另外建议应在您自己的安全服务器上检查有效负载值：
安全建议：当您发送购买请求时，创建一个唯一标识此购买请求的字符串令牌，并将此令牌包含在 developerPayload 中。您可以使用随机生成的字符串作为令牌。当您收到来自 Google Play 的购买响应时，请务必检查返回的数据签名、orderId 和 developerPayload 字符串。为了增加安全性，您应该在自己的安全服务器上执行检查。确保验证 orderId 是您之前未处理的唯一值，并且 developerPayload 字符串与您之前发送的购买请求的令牌相匹配。
查看 Google 用于演示 API 的 Trivial Drive 应用程序的源代码，我发现了以下警告：
* 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.
因此，从所有这些消息来看，使用随机数/字符串作为有效负载听起来是个坏主意。此外，在阅读了最后一个警告之后，将设备 ID 作为有效负载也传递听起来是个坏主意，因为对于不同设备上的同一用户，它会有所不同。那么开发人员有效载荷应该使用什么？
我的应用程序提供了用户无需登录任何服务即可访问的本地功能。所以没有“用户”的概念，也没有服务器端组件。应用内购买请求是针对从应用中删除广告的升级。像这样的应用程序使用有效负载功能是否有意义，或者我最好只使用一个空字符串并让它容易受到重放攻击？