Response from /verifyReceipt is not showing updated expires_date entries

Hi,

I'm working on setting up my back end server. However, I'm getting weird results within the Sandbox environment. When I call the verifyReceipt, I get results back, however now matter how long it's been, I always get the same results. The entries I'm looking at are:


status (always returns 0)

pending_renewal_info[0].auto_renew_status (always returns 1)

latest_receipt_info[0].expires_date_ms (always returns the original expires date from when the subscription was first started)
I have an endpoint that accepts the server-to-server notifications, however it doesn't seem to be getting called at all. The workflow that I'm using is:

1. User clicks subscribe and completes entries

2. App receives receipt and sends it to the backend server.

3. BE Server calls verifyReceipt. If receipt is verified it information is written to database and confirmation is sent to the app

4. App calls finish transaction


If endpoint is called...

1. BE Server parses body and pulls out latest_receipt

2. latest_receipt is sent to /verifyReceipt

3. If receipt is verified, information is written to the database


I also have a cron job that checks for expired subscriptions and calls verify on them to make sure a notification wasn't missed somewhere. (Currently, I'm calling it manually but it will run nightly in production)
1. Service queries for subscriptions that are active but expired date is earlier than current date
2. For each entry, gets latest_receipt and calls verifyReceipt
3. If receipt is valid, updates the database with the new entries (I currently only update the latest_receipt, auto_renew_status and the expires_date_ms
4. If subscription is expired, service sends a data message to app to update (app also updates whenever it starts).

Whenever I call the verifyReceipt, I always get the same values back no matter how long it's been since the subscription was started. Is this a sandbox issue or am I doing something wrong?


TIA

Leeland

Accepted Reply

In the old days it was certain - 5 renewals the first time and then no further renewals ever for that test user. You can create additional test users - I don't think you need a 'real' email for a new test user - it just has to look like a 'real' email whatever3@mynonexistantcompany.com


A feature appeared recently in which a single test user got refreshed and generated 5 more renewals after a second purchase. Rumor had it that the test user got refereshed every 24 hours. It is unclear whether that feature actually existed (I never tested it), whether it still exists, and if it does, whether 24 hours is the refresh time.

Replies

>Whenever I call the verifyReceipt, I always get the same values back no matter how long it's been since the subscription was started. Is this a sandbox issue or am I doing something wrong?


What do you mean when you write "call the verifyReceipt"?


With one exceptuion, receipts don't change. Why would you expect them to change?


You did not state that your IAP is an autorenewable subscription. Is it? If so, you would expect to get renewals only 5 times for the first purchase and you would expect to get a single renewal for each new purchase after that. But that will only be in the field labeled 'latest_receipt_info' coming back from the Apple servers. Are you refering to that field?

Hello,


I could have sworn I put in that it was auto-renewing subscription. Sorry about that.


Anyways, yes it's an auto-renewing subscription, and I'm checking the entries within the latest_receipt_info.


You mention that it will only renew 5 times for the first purchase, and then new purchases only renew once. This might actually be the root cause of my confusion. I've been testing this for a while with the same user. The way that I understood it, when you created a new subscription, it would renew 5 times then automatically end. Then if you subscribed again, it would renew 5 times and automatically end. If it only renews once after the initial time, then that explains why the expires_date are not updating.


Is there a way that you know of to reset that so that it will renew 5 times?

To add more information, I just went through another subscription purchase workflow and here's what I got.
Immediately after purchasing the subscription, I got a receipt in the app and sent it to the server. The server sent it to the sandbox server and got back a response that listed the auto_renew_status as 1 and the expires_date as 2020-02-12T14:16:54Z (8:16am local time). It's now 8:58am and I just called the verifyReceipt endpoint and got the auto_renew_status as 1 and the same expires time. Unless I'm missing something, those responses mean that the subscription expired at 8:16am...but it's still going to auto renew.
Am I looking at the wrong properties to determine whether I should stop providing services?

I think I found out what the problem is...but I'd like to get verification that I'm understanding it correctly. I'm adding a trimmed down response from verifyReceipt to show what I'm discussing as well as additional entries that may or may not be useful (I'm not sure).
It looks like the sandbox has the subscription locked in a billing retry period. The below response was queried an hour and a half after the initial start. If I'm reading this correctly, it's still showing as attempting to retry the billing.


So, my question is how could I have gotten it into this state and how do I fix it so I can finish testing????
```

{


"status": 0,

"environment": "Sandbox",

"receipt": {

"receipt_type": "ProductionSandbox",

"receipt_creation_date": "2020-02-12 15:45:41 Etc/GMT", <--------

"original_purchase_date": "2013-08-01 07:00:00 Etc/GMT",

},

"latest_receipt_info": [

{

"purchase_date": "2020-02-12 14:11:54 Etc/GMT",

"original_purchase_date": "2020-02-12 14:11:06 Etc/GMT",

"expires_date": "2020-02-12 14:16:54 Etc/GMT", <---------

"is_trial_period": "false",

"is_in_intro_offer_period": "false"

}

],

"pending_renewal_info": [

{

"auto_renew_product_id": "gold",

"original_transaction_id": "1000000624151780",

"is_in_billing_retry_period": "1", <---------

"product_id": "gold",

"auto_renew_status": "1" <----------

}

]

}

```

In the old days it was certain - 5 renewals the first time and then no further renewals ever for that test user. You can create additional test users - I don't think you need a 'real' email for a new test user - it just has to look like a 'real' email whatever3@mynonexistantcompany.com


A feature appeared recently in which a single test user got refreshed and generated 5 more renewals after a second purchase. Rumor had it that the test user got refereshed every 24 hours. It is unclear whether that feature actually existed (I never tested it), whether it still exists, and if it does, whether 24 hours is the refresh time.

Based on what I'm seeing, I'd say the 24 hour refresh seems about right. The issue I brought up below was consistent for several hours straight then when I attempted it the next morning it cleared out. I also remember yesterday morning that I got more than one S2S notification the first time as well.


Thanks for the heads up. Now I get to start working on the inconsistent data contract that is used when sending notifications 🙂