I'm finding it hard to retrieve a cancellation date (or check if someone's canceled at all) for an auto-renewable IAP subscription.
I'm doing receipt validation, but cancellation_date_ms never seems to be in the receipts response. I've tested this myself by creating a live subscription in production and canceling it myself, still no luck.
I've also tried using Apple's Subscription Status URL webhook, but they don't seem to send anything useful other than when somebody first subscribes or their subscription is renewed.
I'm running out of ideas!
Related
Good day,
Can someone please tell me how can I know track an event in my code/server when someone cancels a auto-renewable subscription from itunes/appleid
Thankyou
To check when someone cancels a renewable subscription, you need to periodically refresh the receipt on your server and check the:
Expiration Date (lets you know if subscription is still active)
Auto-renew status (lets you know if the user "cancelled")
Cancellation Date (tells you why subscription cancelled by support)
Usually developers get 2 and 3 confused. Apple doesn't consider a user opting out of auto-renew a "cancellation" - when in fact that's what most developers would consider a cancellation. For this reason, it's NOT sufficient to listen for CANCEL events with the subscription status notifications.
Here's a good blog post that goes over the details: iOS Subscriptions are Hard
We are trying to use Apple's subscription status url.
We have setup our server to accept the url we provided in the app page and made sure the server is compatible with ATS requirements.
A post test with Postman works. (we see the request and a test json received on our end)
However we are still not receiving any notifications updates from Apple upon renewal (not even initial_buy).
Seen some questions from last year but no valid solution. Does anyone had this problem lately and solved it?
I can't make a comment, and it's hard to see if this is the case here without knowing if you are actually receiving NOTHING at your script, or just receiving no data in $_POST.
If the latter, this should work:
$data = file_get_contents('php://input');
Then you should be able to work with the data by calling json_decode or doing whatever you want with it.
I ran into the same problem. I thought that Apple would call our webhook whenever a new subscription charge is processed (similar to how Paypal, Stripe, Android etc work). But that's a mistake. According to this technical note:
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-SUBSCRIPTIONS-MY_SERVER_PROCESS_RARELY_RECEIVES_RENEWAL_NOTICES_WHEN_THE_AUTO_RENEWING_SUBSCRIPTION_RENEWS_
The App Store attempts to charge the user account 24 hours before an auto-renewing subscription expires. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into the expired state.
So Apple will only notify this endpoint when
a new subscription is created (at least that's the case for us, but we have a trial offer)
the subscription status changes from active to expired, or vice-versa.
So you have to keep track of the subscription receipts when the customer signs up. When the subscription is about to expire/has expired, call Apple's receipt validation endpoint to fetch the new receipt. If the receipt says the subscription expired, your webhook should be notified when the user reactivates it.
I'm working on an iOS app that will use Apple's in-app purchasing framework to let the user create auto-renewing subscriptions.
I want my server to check periodically that none of the subscriptions have expired. Apple's Receipt Validation Programming Guide describes a verifyReceipt web service that appears to validate a single receipt.
However, if I want to bulk-verify my entire database every few days, is there a better way to do that than a storm of individual verifyReceipt calls?
You don't need to need to bulk-verify your entire database. A subscription is valid for a fixed duration. If the user cancels their subscription then this takes effect at the next renewal period, not immediately.
Apple customer service can refund a subscription if a user has a case (wrong product purchase is one example they give) but this would be a pretty low figure - and your app should also check for a valid subscription when it starts.
So you should only need to verify subscriptions that are known to be expiring "today".
To my knowledge there's no way to send multiple receipts in one bulk request to validate them in the iTunes servers... You have to send one by one. (Multiple requests)...
I don't know if how you are planing to solve this is the best approach. Apple has extended documentation on how to handle auto renewal subscriptions, most of the times you check the validity of the subscription in the app itself.
Check the in-app purchase documentation. It's a very good read if you plan to depend on in-app subscriptions for your business model:
https://developer.apple.com/library/ios/technotes/tn2259/_index.html
I have been testing out Apple's In-App Purchases (sandbox mode) which is great for testing what happens when a user subscribes, but how do I tell if the user is still paying? How do I know if the subscription has been canceled? Apple doesn't appear to let me test that out?
I see that there is something about verifying receipts? How can I do this?
When you subscribe a auto-renewable subscription from app, you will get a receipt. Send that receipt to your server and your sever can use that receipt to verify if your purchase is valid from iTune store (check their doc)
You will get a JSON response and some field inside can show you the expired date.
As to user's cancel, sorry, you cannot know that until current period expire (actually you will know that 24 hours before expiration due to apple store's mechanism)
Hope this helps.
[Updated # 2017/11/5]
Now Auto-renewable subscription is allowed to notify your sever when new period begins. Please check latest document.
I am finding that the renewal of an expired auto-renewing subscription is never being delivered while the application is active and running, but rather when the application is woken up from background or on launch.
In other words if you are using the app, and the subscription expires, it won't be delivered to the app (assuming it is auto-renewing and valid etc) while the user continues to use the app.
This behaviour does not seem to be documented by Apple, can anyone else with experience of this confirm or otherwise?
Obviously one can detect that the sub has expired and then offer the user the chance to check their subscription status and restoreCompletedTransactions which will pull in the new subscription - but I'm just wondering if we're doing something wrong, or if this behaviour is normal.
Thanks.
Yes. That's what I experienced as well.
Before I continue, please see the following posts on why you might want to stay away from auto-renewing subscriptions:
Marco Arment's piece on The limited world of auto-renewable subscriptions, and
The Comments on this SO Question: Auto-renewing subscription – Differences to non-renewing subscription
When your app becomes active, that does seem to trigger the App Store to send any new auto-renewing subscription receipts to your app. But you shouldn't rely on that. And, you don't have to restoreCompletedTransactions to get the latest receipts.
You can see another one of my answers for more detail on this subject.
What you should be doing (based on Apple's documentation and some experimentation) is storing receipts on your server. Then when you want to check if a person's subscription has been auto-renewed, follow Apples procedure for verifying one of those receipts with iTunes. Apple will respond with info about that receipt as well as the latest receipt in that subscription. If it's different than the one you sent, then you know an auto-renewal has occured.