0

I've been setting up in app billing the last couple of days and been trying to go the right way about it. The guides recommend using a secure back-end server to store the purchase token rather than storing the data locally. The documentation on verifying the purchases on a server is very thin and I'm not sure whether am going the right way about it.

I am using cloud fire store to store the purchase information mentioned in the title. I have a couple of questions:

Should I be reading my product id from a server rather than having it hard-coded in the apk?

How often should I/Do I need to read the device id in this case and search on the DB to make sure the user has a valid purchase? Just the once when making the purchase or intermittently?

If I am to do this, what happens when the buyer changes their phone? The device ID will be different and I wont have a record of their new device making a successful purchase. Or here do I query a skupurchase and it returns the item is already owned, write these new details to the DB?

and finally should I store a successful purchase flag in shared preferences or something so I am not constantly reading the DB and the user can use the device offline?

I was going to go down the route of getting users email using this answer here but there is a lot of comments saying this is very intrusive and I only need it for a simple thing. So I went the device ID route.

BTW I only have one product that unlocks full features and is non-consumable.

What is the correct way to go about this?

COYG
  • 1,538
  • 1
  • 16
  • 31

1 Answers1

0

This was my approach to the same problems. It may not be relevant to your scenario. Hope it helps.

Should I be reading my product id from a server rather than having it hard-coded in the apk?

You should store productIDs in the code as they will be used to provide features coded into the app.

How often should I/Do I need to read the device id?

You should not rely on the device id as you have raised the concern about the user changing the phone. You would want to implement the login system and make user login into the app before purchasing the product. This will make your subscription device independent.

The process should be:

  1. User tries to use the locked feature.
  2. App asks for login. Make user register and log in.
  3. User clicks on the buy button again and completes the purchase.
  4. Your server stores the user login information with the purchase information.
  5. User changes the device.
  6. User tries to use the locked feature.
  7. App asks for login. User logs in.
  8. The server returns purchase details with user info.
  9. The app unlocks the feature.

How often should I check purchase details from the server?

You should check for purchase details intermittently.

Why? The user may ask for a refund after some time or the payment gateway would void the purchase for some reason.

IMO, there should be two types of sync methods silent and forced. In my approach, silent sync would check for internet every 9 days. If the internet is not available, it would not do anything. While the forced sync would check for internet every 25 days from the last sync. If the internet is not available it would ask the user to turn it on otherwise, the user wouldn't be able to use the app.

I was using the subscription period of one month but as you have a non-consumable product you can afford 2-4 months forced sync period.

Should I store a successful purchase flag in shared preferences or something so I am not constantly reading the DB and the user can use the device offline?

The syncing process and the login would solve this problem.

I think you might be reluctant to implement a login system for such a small thing and think it would make fewer users buy your product. But by implementing Google authentication it would be fast and users would be less frustrated by it.

Implementing this approach involves a lot of server-side logic.

Kishan Vaishnav
  • 2,273
  • 1
  • 17
  • 45