restoring in app purchase

Solar2D Monetization (in-app purchases, ads, etc.)
#1

Hi All,

I am just curious if my assumptions are correct around restoring in app purchases.

A user purchases a non-consumable inapp.

  1. I will store the event.transaction.receipt during the transaction callback if all is well

  2. unlock / download the purchased inapp based on the product identifier

A user uninstalls my app (foolish I know, it is a really fun app)

A user re-installs my app and hits restore purchases (they realize how much fun they were having)

  1. I will receive each product from my product list in a callback

  2. I will compare the receipt I stored from the original purchase with the receipt in the restore callback

  3. if the receipt matches this is a valid restore and unlock / download inapp

  4. if the receipt doesn’t match this is a hacker trying to bypass the purchase and I ignore it

My real concerns are steps 3 / 4…is this the correct way to go?

As an aside, I have seen an issue in the forum with restore purchases being hit when no purchases have ever been made and no callback ever occurs…so we get a hang-o-rama…is this a remaining issue?

Thanks,

Rick

#2

Hi Rick,

Which platform are you developing for? Or both? Restoring purchases varies slightly on iOS versus Android, in regards to how the transaction listener recognizes them.

This is detailed to some degree in the updated IAP guide:

http://docs.coronalabs.com/guide/monetization/IAP/index.html#api

Hope this helps,

Brent

#3

Thanks Brent for the response…the write up is much better and helps. I am developing for iOS initially then I will move to android…

I have all my inapp working I am just wrestling with the following…

In the example code Corona supplies for inapp it says in the “restored” callback state:

“-- Reminder: your app must store this information somewhere”

indicating the following parameters:

event.transaction.originalTransactionIdentifier
event.transaction.originalDate

I am trying to understand why I need to store it…is this stored on my own server and verified to prevent inapp purchases being being pirated?

Any insight would be appreciated…

Thanks,

Rick

#4

Hi Rick.  “Must” is a harsh word in this case that I would rephrase “Seriously want to do”.  If you call store.restore() and you get a bunch of purchases back and they’ve been compromised, then you are potentially giving away features of your program to the pirates.   I don’t know your app or how important it is to you to protect against thieves.   I think we would highly recommend that you do.

Obviously you can’t store this in your app’s sandbox space.  Some with a jailbroken/rooted device would have access to yoru files but more importantly if someone deletes your app, they would loose access to these receipts.  You would need to store them in your own database service somewhere and be able to validate your restore receipts against the saved receipts.

Corona Labs gives you the tools to access on line services, but you would be on your own to create your own service or look up and see if there are IAP receipt services available for you.

#5

Hi Rick,

Which platform are you developing for? Or both? Restoring purchases varies slightly on iOS versus Android, in regards to how the transaction listener recognizes them.

This is detailed to some degree in the updated IAP guide:

http://docs.coronalabs.com/guide/monetization/IAP/index.html#api

Hope this helps,

Brent

#6

Thanks Brent for the response…the write up is much better and helps. I am developing for iOS initially then I will move to android…

I have all my inapp working I am just wrestling with the following…

In the example code Corona supplies for inapp it says in the “restored” callback state:

“-- Reminder: your app must store this information somewhere”

indicating the following parameters:

event.transaction.originalTransactionIdentifier
event.transaction.originalDate

I am trying to understand why I need to store it…is this stored on my own server and verified to prevent inapp purchases being being pirated?

Any insight would be appreciated…

Thanks,

Rick

#7

Hi Rick.  “Must” is a harsh word in this case that I would rephrase “Seriously want to do”.  If you call store.restore() and you get a bunch of purchases back and they’ve been compromised, then you are potentially giving away features of your program to the pirates.   I don’t know your app or how important it is to you to protect against thieves.   I think we would highly recommend that you do.

Obviously you can’t store this in your app’s sandbox space.  Some with a jailbroken/rooted device would have access to yoru files but more importantly if someone deletes your app, they would loose access to these receipts.  You would need to store them in your own database service somewhere and be able to validate your restore receipts against the saved receipts.

Corona Labs gives you the tools to access on line services, but you would be on your own to create your own service or look up and see if there are IAP receipt services available for you.

#8

Sorry to resurrect this thread but I’m having a conceptual dilemma with restoring purchases. I have my own server that I will call to validate receipts and will store them if they are valid.

The problem I have is this:

  1. If someone is making a new purchase, but the receipt already exists, then I  know someone is trying to re-use a previous purchase.
  2. If someone is restoring, then their receipt should match one in my database. But what’s to stop someone from making a valid purchase once, and then distributing that valid receipt with some sort of IAP cracker? They would just have to restore purchases to trick my server into sending back a valid response.

How do I prevent that?

#9

Update:

I did some testing (on Android) to see if google sends back a unique identifier regardless if you’re restoring or purchasing new. They do not send back a new unique identifier. It’s the same every time. In fact, the entire receipt is identical (same date, token, signature, etc.).

So now I’m really not sure what to do…

#10

Have you researched on the Google forums on how to deal with this?  This isn’t a Corona SDK specific issue.

Rob

#11

Sorry to resurrect this thread but I’m having a conceptual dilemma with restoring purchases. I have my own server that I will call to validate receipts and will store them if they are valid.

The problem I have is this:

  1. If someone is making a new purchase, but the receipt already exists, then I  know someone is trying to re-use a previous purchase.
  2. If someone is restoring, then their receipt should match one in my database. But what’s to stop someone from making a valid purchase once, and then distributing that valid receipt with some sort of IAP cracker? They would just have to restore purchases to trick my server into sending back a valid response.

How do I prevent that?

#12

Update:

I did some testing (on Android) to see if google sends back a unique identifier regardless if you’re restoring or purchasing new. They do not send back a new unique identifier. It’s the same every time. In fact, the entire receipt is identical (same date, token, signature, etc.).

So now I’m really not sure what to do…

#13

Have you researched on the Google forums on how to deal with this?  This isn’t a Corona SDK specific issue.

Rob