Apple deprecates the verifyReceipt API endpoint

[tannakartikey]

We use the /verifyReceipt endpoint which is deprecated by Apple.

The deprecated warning:

Deprecated

The verifyReceipt endpoint is deprecated. To validate receipts on your server, follow the steps in Validating receipts on the device on your server. To validate in-app purchases on your server without using receipts, call the App Store Server API to get Apple-signed transaction and subscription information for your customers, or verify the AppTransaction and Transaction signed data that your app obtains. You can also get the same signed transaction and subscription information from the App Store Server Notifications V2 endpoint.

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.

[jnbt]

@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

1. 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)
2. Unpack the receipt as PKCS #7 (potentially using openssl)
3. Verify chain of trust
4. Check some values

Option B: Use the new AppStore Server API

1. Requires authentication, but credentials can be setup using Apple's Developer portal
2. Pass the transaction id to candy_check
3. Perform server-to-server calls towards GetTransactionHistory
4. 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

[tannakartikey]

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.

[tvandergeer]

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.

[DrakenZA]

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.