6

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!!

Community
  • 1
  • 1
Mark
  • 139
  • 1
  • 8
  • Basically, Google will only help you to make the purchase and inform you whether the purchase has been done or not, it will not inform you how many time the purchase has been done or not. Suppose if the user purchases 500 coins then you have to maintain a server which will track the coins of the user and on the purchase, you have to set the users coin in your server to 1000 + 500. When the user spends 200 coins then set the users coin in you serve to 1300. But keep in mind that a purchase has to be consumed in Google' s server and then only the user can purchase the same thing again. – Rahulrr2602 Mar 25 '18 at 12:28

1 Answers1

7

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.

  1. User consumes the Resource.
  2. 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.
Community
  • 1
  • 1
Kishan Vaishnav
  • 2,273
  • 1
  • 17
  • 45
  • Thanks for the answer! The security best practices seems to be centered around validating a purchase, whether it be for consumable or non-consumable, or subscriptions. I'm interested more in how to handle the changes in a player's account/inventory after the validation of a purchase. Would Firebase databases be sufficient for the security best practices, or for storing player inventory? I was thinking that or AWS instead of making a private server. – Mark Mar 24 '18 at 15:23
  • You can use any service provider or technology. Google seems to suggest anything but their Server API. Use Digital Signature to identify the party. – Kishan Vaishnav Mar 25 '18 at 19:45
  • To make consumption secure you must use trustworthy server. I've suggested consuming a product in my answer. The benefit of using server for recording consumption is you can handle and monitor users purchases and restoring consumable product will be easy(I think) – Kishan Vaishnav Mar 25 '18 at 19:52
  • If my answer was satisfactory please mark it as the answer. It will help me get my first points – Kishan Vaishnav Mar 27 '18 at 10:49