in-app originalPurchase

Hi All,


I'm wondering if there is a way to find out if the purchase is being made for the first time or if its being repurchased (for whatevr reason)


The reason I need t know this is becauseI'm using Fabrics Answers to track in-app purchases. In my case it tags it twice if the user repurchases the same one-time in-app purchase. Of course Apple doesnt recharge them and thats as expected, but I need to check to ensure I only track it if its a first time purchase.


I saw somewhere that there is a flag, something like originalPurchaseDate. Can someone point me in the right direction. Is that flag empty when its the first time or nil? An example of a check against it would be ideal.


Cheers

Ace

You will want to compare the receipt's value for tranaction_id to the transaction.transactionIdentifier that you get in the updatedTransaction method.

Some additional information:

The transaction.transactionIdentifier I log is always new for every transaction including repurchases. The transaction_id from the receipt is always the same (in sandbox).


1. Can we assume that the receipt given in sandbox is just a sample receipt with the orignal purchases.

2. Can we also assume in production environment, always spit out an updated receipt with a new transaction_id upon each purchase/repurchase?

No! The receipt will not change with a repurchase for free. The transaction_id will reflect the earlier transaction when the purchase was made. However the value of transaction.transactionIdwntifier in updatedTransactions will change each time

hmmm that doesnt make sense if the transaction_id of the receipt is always the same even on repurchase for free, why is there another field called original_transaction_id on that very same eceipt? They are always equal in that case.

Why do you care? But if you do, consider an autorenewable subscription - it will be different for them - autorenewable subscriptions may need to refer back to the original order that started a stream of renewal transactions. The transaction_id is a subsquent purchase steming from that original_transaction_id - it will be different. I guess they could have deleted the original_trransaction_id for non-consumables (and non-renewaing subscriptions) but deleting the field might create other issues.


And the transaction_id is always the same because the transaction in question was that transaction back when the purchase of the IAP was made. This repurchase transaction has an id that doesn't make it into the receipt because nothing was purchased - that's the point! The transaction_id only makes it to the transaction object itself as the property transaction.transactionIdentifier.

Well I do care jsut for general understanding and making sure Its all proper. So I incoporated all our discussion and am testing it right now. I have a ONE last question:


1. Can we reset my sandbox purchases? that way I can test transaction.transactionIdentifier == transaction_id


FYI:

The CONSUMABLE transaction_id and original_transaction_id do change on the receipt upon purchasing again (as expected)


I also have updated the validateTransaction() to include a completionHandler. If you want it, just message me and ill post it as a Gist

You asked: "Can we reset my sandbox purchases?" - no , create and use a new test user. Test users do not need a 'real' email address - you can use name26@gmail.com and name27@gmail.com


"CONSUMABLE transaction_id and original_transaction_id do change on the receipt upon purchasing again (as expected)" - actually, what is expected, and what will happen in production (usually) is that the consumable purchase will disappear when the receipt is refreshed by another purchase or a receipt refresh. The receipt is documented to retain, and does retain, non-consumable IAPs and autorenewable IAPs. The receipt is documented to retain, and often but not always does retain, non-renewing subscription IAPs. The receipt is documented to discard, and often but not always does discard, consumable IAPs.

Yea should have phrased it better. The point is, consumable items are replaced within the receipt and their ids updated as expected.


Creating a new sandbox tester confirmed that the purchase is logged on FIRST purchase (as expected)


Though I think there is an anomoly where the purchases are given before the user confirms on that "buy" alert. Not sure if I was mistaken or if that really happend. Needs some more testing.


I marked your answer as the correct one.

in-app originalPurchase
 
 
Q