Test User - How to Test a Cancel Event

I have now set up my server to accept Notifications from Apple to get events for my subscription service such as Cancel, Renewal, Initial_Buy, etc. I know that I am successfully recieving the Initial_Buy event and updating my database appropriately. I know that for subscriptions, I should recieve something like 5 Renewals in an hour that I can listen for. But what about a Cancel event? How can I Cancel my test user's subscription and recieve a Cancel Notification from Apple so that I can be confident that I am recieving it and updating my database appropriately??


Thanks for any insight

Replies

I'm really not comfortable with my testing here. I have created a new user several times. I have a Status Notification Updates listener written in PHP. I am getting an INITIAL_BUY returned when a new user signs up. I went to bed last night and got one RENEWAL all night. But I need to test a CANCEL to feel really comfortable that I have everything set up correctly. How can I get a CANCEL? Is there a way to force any of these events???

There is no way to test.


Lot's of folks worry about users who will cancel. But it's rare. If the cost of providing a subscription is large then that concern is legit. You can store a receipt on your server and use that receipt to routinely test the user's subscription status with Apple's servers.


But if your cost of providing an extra subscription is small (or zero - it usually is zero) why do you care? Most users who cancel are not going to give you any money even if you manage to stop the subscription the moment Apple agrees to cancel. 100-X-Y times out of 100 they don't want your subscription and won't use it. X times out of 100 they do want it but won't pay for it and they will continue using it without paying for it. Y time out of 100 they would have paid but they are thrilled they are getting away with stealing it from you. The X is not lost income, it's living among thieves; ignore it. Y is the only lost revenue. I suspect Y is very small.

I was kind of afraid you were going to say that. Thanks for your help PBK, I really appreciate the insights. It is really sad to me that we pay 30% for such a service, and we don't have a reliable and thorough testing platform. I pay only 4% to another service that I will not mention because I think it is inappropriate to do so, and they leave no stone unturned and don't make you hassle with such a receipt process. Everything is done simply and securely with a thorough API, and I get notifications for everything that happens. I don't have to use polling to monitor when a subscription is actually cancelled, I just get a simple clear notification and update my database. Really disappointed.

Do you think it is better to take ALL of your Apple receipts and verify them with Apple's servers every day to test for expirations, or have you found that Apple's notification system is reliable enough to only verify the ones that are past the last reported expiration date??

>take ALL of your Apple receipts and verify them with Apple's servers every day


Could be counter-productive...how many is 'all'?


I'd let the system do it's work, instead.

Read my post above regarding ignoring cancellation events. [Important - cancellation is different from ending 'autorenew'. If you don't understand that then figure it out before proceeding.] If you are ignoring cancellation events then there is no need to test a receipt until the date when that subscription would have expired. Usually you will have already received a new subscription. If you have not received a new subscription then, and only then, do you need to test anything.


The best way (IMHO) to handle the subscriptions is using the app and its updatedTransactions method. Let the app push to your server any renewal events it gets.


You will find that Apple's system is superior to your other system and handles a load far greater than your other system. Apple has two problems - it is an attractive target for hackers and it is an attractive target for people who like to complain.