verifyReceipt request timed out about once in 10 times

Hi,


My service call `POST https://buy.itunes.apple.com/verifyReceipt` API about 1000 times every day to verify receipts of Auto-Renewable Subscription.

From February 10, the API call timed out about once in 10 times.


I call the API like bellow (ruby), and got Net::ReadTimeout exception about once in 10 times.

def verify_receipt
  https = Net::HTTP.new('buy.itunes.apple.com', 443)
  https.use_ssl = true
  https.post('/verifyReceipt', {
    :'receipt-data' => 'BASE64 encoded receipt',
    password: 'APPSTORE SECRET'
  }.to_json)
end

(0..30).each do |i|
  p i
  verify_receipt
  # sleep 3 # Timeout occured even if sleep 3 seconds.
end


The API call was fully successful before February 10.


Is there something Apple's system change?

Should I limit the frequency of calls?


Regards.

Replies

Why do you verify autorenewable subscriptions that have not expired?

If everyone did on a daily basis that it would be an unbearable load on the Apple servers.

Is it really that important to identify anyone who might have canceled their subscription?

PBK


Thanks for your reply. 😍


> Why do you verify autorenewable subscriptions that have not expired?


Because of upgrading of subscriptions.

When user do "Upgrade" the subscription, our service should detect and update the user's information as soon as possible.

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html


For example, suppose our service has Silver Plan and Gold Plan as auto-renewable subscriptions.

And suppose a user purchased Silver Plan.

We should update the user's information when the user purchase Gold Plan within the period (Upgrade).


So, we run verifyReceipt process daily on server side.


But that daily process may be wrong way.

Using the iOS application as the starting point of processing may be the right way, now I feel.


Any advices are welcome.

Thanks.

Sure.

There is no need to verify everyone's receipt every day. When a user makes a purchase (or any upgarde) that generates a call to updatedTransactions with a state of purchased. When your app receives thta call it can either 1) process the purchase based on the transaction or on the new receipt or 2) trigger your system to verify that user's receipt.

It can also be done with server notifications. I believe "INTERACTIVE_RENEWAL" would be the right one for this.


That said, I'd like to know if a user has cancelled (in the sense of not renewing at next renewal date).

"auto_renew_status" (available from the verifyReceipt JSON) would be used for this. But, there's no notification for that one. Meaning, we'd have to resort to polling.

Is polling the only way here?

I would not use the word "cancel" in this context - it can be, and often is, misunderstood.

If you want to rely on notficiations you can use the "DID_CHANGE_RENEWAL_PREF" to detect a user who has shut off the automatic renewal.

But the simplest procedure is to record the users expiration date and do nothing until after that date. Then, and only then, poll the Apple website with any receipt and look at the latest_receipt_info field. This is a 99% complete solution. Add the "Cancel" notification and it is 100% complete.

Thanks PBK.

I had missed the "DID_CHANGE_RENEWAL_PREF" notification.

We currently poll only at the end, so we can keep doing it that way.


I understand what you mean regarding the two different cancellations leading to confusion.

Why do you verify autorenewable subscriptions that have not expired?

If everyone did on a daily basis that it would be an unbearable load on the Apple servers.

Is it really that important to identify anyone who might have canceled their subscription?


I verify autorenewable subscription receipts on a daily basis to know if a user has received a refund from Apple. If I don't do this, a user could use premium features until the end of the subscription period (possibly a year) without paying. If a user receives a refund from Apple for an in-app purchase, the updatedTransactions method is not called in the app.

>I verify autorenewable subscription receipts on a daily basis to know if a user has received a refund from Apple.


Please tell us - how many refunds have you detected and how have you turned that detection into anything of value to you?

> Please tell us - how many refunds have you detected and how have you turned that detection into anything of value to you?


This is a technical issue. I'm not seeking comments on a business case. Thank you.

Post not yet marked as solved Up vote reply of Theo Down vote reply of Theo