跨会话/设备处理应用内购买/消耗品? [英] Handling in-app purchases / consumable products across sessions/devices?

问题描述

我的问题集中在使用 Google 的 In-App Billing API 处理消耗品的应用内购买.(https://developer.android.com/google/play/billing/api.html#consumetypes)

他们的文档将消耗品描述为:

<块引用>

消耗品

相反，您可以对可以多次购买的产品实施消费.通常，这些产品会提供某些临时效果.例如，用户的游戏角色可能会在他们的库存中获得生命值或获得额外的金币.在您的应用程序中分配所购买产品的好处或效果称为供应被管理产品.您负责控制和跟踪向用户提供受管理产品的方式.

消耗品是可以多次购买的东西(如游戏货币、游戏内物品或使用的升级等)，而非消耗品只能购买一次(无广告、皮肤/角色等)

在消费购买的文档中 (https://developer.android.com/training/play-billing-library/purchase-iab-products.html)，它还提到:

<块引用>

如何在应用中使用消费机制取决于您.通常，您会为用户可能想要多次购买的具有临时利益的产品实施消费，例如游戏货币或可补充的游戏代币.您通常不希望对购买一次并提供永久效果(例如高级升级)的产品实施消费.

您有责任控制和跟踪向用户提供应用内商品的方式.例如，如果用户购买了游戏内货币，您应该使用购买的货币数量更新玩家的库存.

我的问题是如何跟踪用户的消费品库存?文档和各种视频似乎很快掩盖了这一点，基本上是说应用程序在确认购买成功时必须应用消耗品的效果.但这并不是真正的全貌.如果用户退出并使用不同的帐户重新登录怎么办?或者他们换了一部新手机，他们应该在这部手机上有产品.

您无法真正将购买记录保存在 SharedPreferences 或永久缓存中，因为它与手机相关联.如果用户使用不同的手机登录，那么他们应该可以享受所有购买的好处.

以下面的例子为例:

一场比赛开始时玩家有 1000 金币.玩家通过应用内购买再购买 500 金币，然后花费 200 金币.如果玩家购买新手机并在该手机上安装该应用，他们应该有 1300 金币.

这通常是如何完成的?

您是否需要运行一个私人服务器来跟踪此类物品的购买/消费情况，并与 Google 分开?

谢谢！！

解决方案

我自己正在实施应用内购买.

<块引用>

您是否需要运行一个私人服务器来跟踪此类物品的购买/消费情况，并与 Google 分开?

当然是，正如 Google 在安全最佳做法

<块引用>

强烈建议在您信任的服务器上验证购买详细信息.但是，如果您无法使用服务器，仍然可以在设备上的应用中验证这些详细信息.

你的第二个问题

<块引用>

如果用户退出并使用其他帐户重新登录怎么办?

将 orderId 绑定到帐户或设备.在第一种情况下，您可以在用户切换设备时轻松管理购买(获得私人服务器的另一个原因).而在第二种情况下，您可以允许在同一设备上切换帐户.所以选择哪一个取决于你.

您需要将本地消费同步到服务器.

这是验证购买的流程:

<块引用>

1. 用户点击购买"按钮.
2. 使用谷歌付款.
3. 应用从谷歌接收收据"并将其存储在本地
4. 将此收据"发送到服务器.
5. 服务器将purchaseToken"发送到 Google Play Developer API 进行验证
6. Google Play Developer API 发送带有状态代码的响应.
7. 将 RECEIPT 存储在服务器数据库中(如果我们保留用户的购买历史记录).

这是消费产品的流程:

<块引用>

1. 用户打开应用.
2. 应用通过从本地存储中读取来为资源分配值.
3. 应用尝试与服务器同步.(检查上次更新的时间戳)

不同的场景:

同步成功:从服务器分配资源值.在本地存储中设置新检索到的值.

同步失败:保留资源值并重试.

4. 用户使用资源.
5. 应用更新资源中的本地值并与服务器同步.(检查上次更新的时间戳)

我使用了以下文章:

• 教程:如何在 Android 中实现应用内计费 LINK
• 关于实施应用内购买的文章LINK.
• 如何在服务器端验证 android 应用的购买(谷歌在应用计费 v3 中播放)LINK.
• 另一个 SO 答案LINK.
• 另一个 SO 答案LINK.
• 代码项目示例 LINK.

My question is centered around handling in-app purchases for consumables with Google's In-App Billing API. (https://developer.android.com/google/play/billing/api.html#consumetypes)

Their documentation describes consumables as:

Consumable products

In contrast, you can implement consumption for products that can be made available for purchase multiple times. Typically, these products provide certain temporary effects. For example, the user's in-game character might gain life points or gain extra gold coins in their inventory. Dispensing the benefits or effects of the purchased product in your application is called provisioning the managed product. You are responsible for controlling and tracking how managed products are provisioned to the users.

A consumable item is something that could be purchased several times (like in game currency, an in game item or upgrade that is used, etc.), whereas a non-consumable can only be purchased once (no-ads, a skin / character, etc.)

In the documentation on consuming a purchase (https://developer.android.com/training/play-billing-library/purchase-iab-products.html), it also mentions:

How you use the consumption mechanism in your app is up to you. Typically, you would implement consumption for products with temporary benefits that users may want to purchase multiple times, such as in-game currency or replenishable game tokens. You would typically not want to implement consumption for products that are purchased once and provide a permanent effect, such as a premium upgrade.

It's your responsibility to control and track how the in-app product is provisioned to the user. For example, if the user purchased in-game currency, you should update the player's inventory with the amount of currency purchased.

My question is how to keep track of user inventory for consumable products? The documentation and various videos seem to quickly gloss over this, basically saying the app must apply the effects of the consumable when it gets confirmation of a successful purchase. But that isn't really the full picture. What if a user signs out and signs back in with a different account? Or they switch to a new phone, they should have the product on that phone.

You can't really save record of the purchase in SharedPreferences or a persistent cache because it is tied to the phone. If a user signs in on a different phone then they should have the benefits of all the purchases they made.

Take the following example:

A game starts players with 1000 gold. Player buys 500 more gold through an in-app purchase, then spends 200 gold. If player buys a new phone and installs that app on that phone, they should have 1300 gold.

How is this normally accomplished?

Do you need to run a private server that keeps track of purchases/consumption of such things separate from Google?

Thanks!!

解决方案

I am implementing in-app purchase myself.

Do you need to run a private server that keeps track of purchases/consumption of such things separate from Google?

Yes of course as Google suggests in Security Best Practices

It's highly recommended to validate purchase details on a server that you trust. If you cannot use a server, however, it's still possible to validate these details within your app on a device.

Your second question

What if a user signs out and signs back in with a different account?

Tie the orderId to account or device. In the first case, you can easily manage the purchase when the user switches the devices(another reason to get a private server). While in the second case you can allow switching accounts on the same device. So it's up to you which one to select.

You need to Synchronize local consumption to the server.

This is the flow for Verifying the purchase:

1. User clicks "BUY" button.
2. Makes payment with google.
3. App receives "receipt" from google and store it locally
4. Send this "RECEIPT" to the Server.
5. The Server sends the "purchaseToken" to Google Play Developer API for validation
6. The Google Play Developer API sends response with status code.
7. Store the RECEIPT in the server database (If we you to keep history of purchases by users).

This is the flow for Consuming the product:

1. The user opens the app.
2. App assigns values to the Resources by reading from local storage.
3. App tries to synchronize with the Server.(checks last updated timestamp)

Different scenarios:

Synchronization Successful: Assigns Resource values from the server. Set newly retrieved values in the local storage.

Synchronization Failed: Keep Resource values and try again.

4. User consumes the Resource.
5. App updates local values in Resource and sync with the server.(checks last updated timestamp)

I used Following articles:

• Tutorial: How to Implement In-app Billing in Android LINK
• Article on implementing InApp purchase LINK.
• How to verify purchase for android app in server side (google play in app billing v3) LINK.
• Another SO answer LINK.
• Another SO answer LINK.
• Code Project Sample LINK.

这篇关于跨会话/设备处理应用内购买/消耗品?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！