Repository navigation
Apple deprecates the verifyReceipt API endpoint #85
Description
Activity
@tannakartikey You're totally right. Last week I was actually also hit by this warning.
According to your linked answer from Apple support, the API will continue to work until further notice:
[...]
It will continue to function until an end of life date is announced.The end of life date is currently yet to be determined and developer will get a notification in advance prior to end of life.
I would like to discuss the options we have. As far as I understood with the new process, there are two ways the verification can happen, according to Apple:
Option A: Implement the "Client-side validation" steps on the server
Refs: https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device
- Pass the receipt (as currently) to candy_check, also pass additional information of the app (either information required to build the SHA-1 hash, or the actual SHA-1 hash)
- Unpack the receipt as PKCS Add CLI support for subscriptions #7 (potentially using openssl)
- Verify chain of trust
- Check some values
Option B: Use the new AppStore Server API
- Requires authentication, but credentials can be setup using Apple's Developer portal
- Pass the transaction id to candy_check
- Perform server-to-server calls towards GetTransactionHistory
- Verify JWS and decode payload (potentially using ruby-jwt
The question is, which of these ways is more appropriate for candy_check.
My currently feelings are:
- Option A: has the benefit that it doesn't rely on sever-to-server calls and doesn't need credentials, but is harder to implement
- Option B: the opposite
Thanks for the write-up @jnbt
The project I am working on, and probably for all those using this gem, it will be easier to adapt to Option A. I am going to look into it how to implement it. Do you have any suggestions on the starting point?
We can think about implementing both options too.
Check this code from Apple for option A: https://github.com/apple/app-store-server-library-node/blob/main/receipt_utility.ts#L17
It's from their official NodeJS package, but it comes with a warning:
* Extracts a transaction id from an encoded App Receipt. Throws if the receipt does not match the expected format. * *NO validation* is performed on the receipt, and any data returned should only be used to call the App Store Server API.My current approach is taking the transaction_id coming from the App for an Apple Device, getting data from Apple API for the transactions with gettrans end point. You can get the 'original_trans_id' which can be stored and used to reference back to the sub on other end points like get sub status endpoint, which will return if the sub is alive,revoked,expired etc much like their webhooks.
Any update on this? I prefer option A (already have it manually written in my code) but it would be nice to use one library for iOS and Android.
@jameswilliamiii Do you have some code to share? Do you pass the device UUID (
identifierForVendor) to your server in order to calculate the SHA-1 hash?@jnbt check out this library (https://github.com/got2be/app-store-server-library-ruby). He has a gem released for it (https://rubygems.org/gems/app-store-server-library). My code is very similar, and i have been debating whether to pull in his library or roll my own. It would be awesome to have this as part of your gem so I could rely on one library for both iOS and Android.
Hi! I'm trying to migrate to Storekit2 and App Store Server API is mandatory.
@jameswilliamiii Do you still use https://github.com/got2be/app-store-server-library-ruby ? It seems to be unmaintained, and the lack of documentation isn't helping…
I found https://github.com/mnyify/app_store_server_api which seems fine? Anyone already tried it?
@Freddy03h I ended up using the
app_store_server_apigem by the time we launched the project. It worked well for what we needed.Reacted by Freddy Harris
We use the
/verifyReceiptendpoint which is deprecated by Apple.The deprecated warning:
A question on the forum answered by Apple support: When will the verifyReceipt api be deprecated?
Just wanted to start a discussion and help in any way with the next steps.