如何检测并验证自动续订订阅的续订?

时间:2023-01-12 21:34:35

So I have setup an auto-renewable subscription for my app with a period of 1 month, which equals 5 minutes or so in the sandbox. In the client app I subscribe, send the receipt to my server, it gets verified and I put a record in my database that this user has a subscription.

所以我为我的应用设置了一个可自动更新的订阅,期限为1个月,相当于沙盒中的5分钟左右。在我订阅的客户端应用程序中,将收据发送到我的服务器,它得到验证,我在我的数据库中记录了该用户订阅的记录。

My question is how do I check if this subscription has been renewed? I have read the docs and can't figure out what should I do.

我的问题是如何检查此订阅是否已续订?我已阅读文档,无法弄清楚我应该怎么做。

Here is where I am so far:

这是我到目前为止的地方:

  1. The initial receipt that gets sent to my server is verified with a status 0, great. I also get latest_receipt, which I replace in my database with the oldest receipt.
  2. 发送到我的服务器的初始收据已通过状态0验证,非常好。我也得到latest_receipt,我用我最早的收据替换了我的数据库。
  3. After 6 minutes when I try to verify the latest_receipt, I get status 21006 (expired receipt) and this:
  4. 6分钟后,当我尝试验证latest_receipt时,我得到状态21006(已过期的收据),并且:
   { receipt: 
       { original_purchase_date_pst: '2013-08-06 11:58:04 America/Los_Angeles',
         unique_identifier: '------------',
         original_transaction_id: '----------',
         expires_date: '1376129825000',
         transaction_id: '------------',
         quantity: '1',
         product_id: 'subscription',
         item_id: '--------',
         bid: 'com.--------',
         unique_vendor_identifier: '---------',
         web_order_line_item_id: '---------',
         bvrs: '2.0',
         expires_date_formatted: '2013-08-10 10:17:05 Etc/GMT',
         purchase_date: '2013-08-10 10:12:05 Etc/GMT',
         purchase_date_ms: '1376129525000',
         expires_date_formatted_pst: '2013-08-10 03:17:05 America/Los_Angeles',
         purchase_date_pst: '2013-08-10 03:12:05 America/Los_Angeles',
         original_purchase_date: '2013-08-06 18:58:04 Etc/GMT',
         original_purchase_date_ms: '1375815484000' },
      latest_expired_receipt_info: 
       { original_purchase_date_pst: '2013-08-06 11:58:04 America/Los_Angeles',
         unique_identifier: '-------',
         original_transaction_id: '-',
         expires_date: '1376129825000',
         transaction_id: '-',
         quantity: '1',
         product_id: 'subscription',
         item_id: '-',
         bid: 'com.-',
         unique_vendor_identifier: '--',
         web_order_line_item_id: '-',
         bvrs: '2.0',
         expires_date_formatted: '2013-08-10 10:17:05 Etc/GMT',
         purchase_date: '2013-08-10 10:12:05 Etc/GMT',
         purchase_date_ms: '1376129525000',
         expires_date_formatted_pst: '2013-08-10 03:17:05 America/Los_Angeles',
         purchase_date_pst: '2013-08-10 03:12:05 America/Los_Angeles',
         original_purchase_date: '2013-08-06 18:58:04 Etc/GMT',
         original_purchase_date_ms: '1375815484000' },
      status: 21006 }

The second element in the array used to be latest_receipt_info, but now it's latest_EXPIRED_receipt_info. Here is what the docs say:

数组中的第二个元素曾经是latest_receipt_info,但现在是latest_EXPIRED_receipt_info。以下是文档的说法:

In addition to the receipt_data field, the response may also include two new fields. If the user’s subscription is active and was renewed by a transaction that took place after the receipt your server sent to the App Store, the latest_receipt field includes a base-64 encoded receipt for the last renewal for this subscription. The decoded data for this new receipt is also provided in the latest_expired_receipt_info field. Your server can use this new receipt to maintain a record of the most recent renewal.

除了receipt_data字段之外,响应还可以包括两个新字段。如果用户的订阅处于活动状态并且在收到服务器发送到App Store后发生的事务进行续订,则latest_receipt字段包含用于此订阅的上次续订的base-64编码收据。此新收据的解码数据也在latest_expired_receipt_info字段中提供。您的服务器可以使用此新收据来维护最近续订的记录。

So if the sub has been renewed since my server last checked, the decoded receipt for the renewal should be in latest_expired_receipt_info. In that object the expires_date is the same as the original receipt's expires_date.

因此,如果自我的服务器上次检查后更新了子服务器,则更新的解码收据应该在latest_expired_receipt_info中。在该对象中,expires_date与原始收据的expires_date相同。

What the hell? I just want to check if the sub is active. Can anyone explain in simple words how do I do that?

我勒个去?我只想检查子是否有效。任何人都可以用简单的词语解释我该怎么做?

Thank you!

谢谢!

1 个解决方案

#1


28  

My experience. Let's assume, we always send initial receipt to Apple's server.

我的经验。我们假设,我们总是向Apple的服务器发送初始收据。

In any case, you'll get JSON with at least two fields: status (no comments) and receipt (information about receipt that you've send).

在任何情况下,您将获得至少包含两个字段的JSON:状态(无评论)和收据(有关您已发送的收据的信息)。

Additionally to that:

除此之外:

1) If the subscription is still active, you'll additionally get latest_receipt (base64-encoded string) and latest_receipt_info (information about that receipt).

1)如果订阅仍处于活动状态,您还将获得latest_receipt(base64编码的字符串)和latest_receipt_info(有关该收据的信息)。

2) If the subscription is already expired, you'll additionally get latest_expired_receipt_info (information about last renewing receipt). Yes, you get only information about it, no base64-encoded string.

2)如果订阅已经过期,您还将获得latest_expired_receipt_info(有关上次续订收据的信息)。是的,您只获得有关它的信息,没有base64编码的字符串。

And yes, AFAIK, that's not documented anywhere. Hope that helps.

是的,AFAIK,在任何地方都没有记录。希望有所帮助。

#1


28  

My experience. Let's assume, we always send initial receipt to Apple's server.

我的经验。我们假设,我们总是向Apple的服务器发送初始收据。

In any case, you'll get JSON with at least two fields: status (no comments) and receipt (information about receipt that you've send).

在任何情况下,您将获得至少包含两个字段的JSON:状态(无评论)和收据(有关您已发送的收据的信息)。

Additionally to that:

除此之外:

1) If the subscription is still active, you'll additionally get latest_receipt (base64-encoded string) and latest_receipt_info (information about that receipt).

1)如果订阅仍处于活动状态,您还将获得latest_receipt(base64编码的字符串)和latest_receipt_info(有关该收据的信息)。

2) If the subscription is already expired, you'll additionally get latest_expired_receipt_info (information about last renewing receipt). Yes, you get only information about it, no base64-encoded string.

2)如果订阅已经过期,您还将获得latest_expired_receipt_info(有关上次续订收据的信息)。是的,您只获得有关它的信息,没有base64编码的字符串。

And yes, AFAIK, that's not documented anywhere. Hope that helps.

是的,AFAIK,在任何地方都没有记录。希望有所帮助。