We make an in-app purchase with server validation, but we don't know what the maximum length of receipt string is? We need to know this because client communicate with C++ server, and receipt string is stored in array of char in a struct which is sent to server.
Where can we find information about the maximum length of receipt string ?
I just checked with the StoreKit engineering team on this question - "We don't have a limit on the length, so in theory it can grow unbounded." You can check the length of the receipt to determine how much storage to malloc.
rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI
I just checked with the StoreKit engineering team on this question - "We don't have a limit on the length, so in theory it can grow unbounded." You can check the length of the receipt to determine how much storage to malloc.
rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI
One issue is that the receipt contains every purchase of a non-renewing subscription and every renewal of an autorenewable subscription.
(I realize that this is kind of an old thread... It is definitely on the topic I need to get answers on... Hopefully, I can still be heard?)
I am working on a new implementation that will use in-app purchases with server validation and an auto renewing subscription.
I am planning to store the receipt I get back for future reference. My original thinking was that it would go into a database field for the associated billing record -- but I am having difficulty determining how big that field should be...
I need to know how long the first receipt that is returned to me from such a process will be, please. (Also, do I need to store subsequent -- progressively longer -- receipts? Or can I re-use the first one to go back and check on the subscription status?)
Thank you,
Julie Williams
There are many dimensions to your question. It is more routine to rely on the device to update its receipt and provide a path to verification only when its receipt appears to have expired. This is done using the receipt that is issued to each device when it receives a call to updatedTransactions. All devices that purchase an autorenewable (or that restoreCompletedTransactions) will get regular calls to their updatedTransactions method with a new receipt just before their last receipt expires. They can either decode that receipt on board or they can send that receipt to your server for verification. No need to store anything. If a device has an expired receipt it issues a warning to its user that it needs to update its receipt and it does a receipt refresh. Very clean.
But.....if you must check your users by storing their receipts on your server and continually verifying their subscription status (e.g. you provide an ongoing service to the subscribed user outside of your app) you can do that one of two ways:
1) You can ask the device for its latest receipt, collect that latest receipt and send it to the Apple servers whenerver you want. The latest receipt can get bigger and bigger with each renewal. This method is clearly documented. If a user's receipt has expired, require that they run teh app and update the subscription.
2) Another method is to rely on the 'latest_receipt_info' field being returned for all receipts and store only the original receipt. This method is undocumented and therefore (IMHO) should not be relied upon; but well respected Apple folks (i.e. Rich Kubota) insist it will always work. Also, the size of this receipt will not change. (I verify on the device so I do not know how big it is.)
