training class for Selling In-app Products in Android建议在发出购买请求时使用有效负载：
第五个参数包含一个'developer payload'字符串，您可以使用该字符串发送有关订单的补充信息（它可以是空字符串）。通常，这用于传递唯一标识此购买请求的字符串标记。如果您指定字符串值，Google Play会将此字符串与购买回复一起返回。随后，当您对此次购买进行查询时，Google Play会将此字符串与购买详情一起返回。
安全建议：最好传入一个字符串，帮助您的应用识别购买的用户，以便以后验证这是该用户的合法购买。对于消耗品，您可以使用随机生成的字符串，但对于非消耗品，您应该使用唯一标识用户的字符串。
Implementing IAB Purchase page有类似的建议，另外建议应在自己的安全服务器上检查有效负载值：
安全建议：当您发送购买请求时，请创建一个唯一标识此购买请求的字符串标记，并将此标记包含在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作为有效负载传递也是一个坏主意，因为对于不同设备上的同一用户而言它将是不同的。那么开发者有效负载应该用什么呢？
我的应用提供了用户可以访问的本地功能，而无需登录任何服务。所以没有“用户”的概念，也没有服务器端组件。应用内购买请求适用于从应用中删除广告的升级。这样的应用程序是否有意义使用有效负载功能，或者我最好只使用空字符串并使其容易发生重放攻击？
答案 0 :(得分：14)
我对InApp采购的了解来自较旧的v2库。我没有使用过最新的v3。但是，希望我仍然可以提供帮助。
是的，使用开发者有效负载作为增加的安全功能肯定会有所帮助，但无论你是否应该是一个客观的困境可能更主观。在我的情况下，我的客户已经有一个混合服务器，因为客户必须在购买之后下载200mb的文件。我们使用开发人员有效负载来存储有关授权下载的文件的信息。此信息对于告诉应用程序如何处理下载的文件至关重要。
我们仍然通过使用服务器调用覆盖本地verifyPurchase()方法来提供额外的安全性。 IE，提供我们自己的随机数来检查。在本地做这件事并不十分安全。
至于你的情况，我说这是风险与成本的问题。您的应用被黑客攻击和客户绕过购买的风险与实施增加的安全性的成本相比有多大。如果您的应用程序被下载超过100,000次，那么您将面临相当大的风险。如果超过100万次，则存在高风险。如果只有几千，那么盗版可能会忽略你的App。如果选择添加的安全性，则需要启动并运行服务器，然后添加App和服务器所需的所有代码和握手。所有这些都需要时间和金钱。特别是在应用程序生命周期内支付服务器费用。