Уведомление DID_CHANGE_RENEWAL_STATUS для подписки iOS: latest_expired_receipt против latest_receipt - PullRequest
Новая
       11

Уведомление DID_CHANGE_RENEWAL_STATUS для подписки iOS: latest_expired_receipt против latest_receipt

1 голос
/ 07 июня 2019

Я работаю над добавлением подписки в свое приложение для iOS, и я столкнулся с некоторыми досадными несоответствиями:

Мой сервер прослушивает уведомление DID_CHANGE_RENEWAL_STATUS от Apple: 

{
    "auto_renew_status_change_date": "2019-06-05 13:42:43 Etc/GMT",
    "environment": "Sandbox",
    "auto_renew_status": "false",
    "auto_renew_status_change_date_pst": "2019-06-05 06:42:43 America/Los_Angeles",
    "latest_expired_receipt": "ewoJIn...",
    "latest_expired_receipt_info": ⊖{
        "original_transaction_id": "10000001010101010",
        "expires_date_formatted": "2019-06-05 13:43:13 Etc/GMT",
        ...
    },
    "password": "xxxxxxxxx",
    "auto_renew_status_change_date_ms": "1559742163000",
    "auto_renew_product_id": "com.my.product",
    "notification_type": "DID_CHANGE_RENEWAL_STATUS"
}

Во время моих тестов уведомление содержало почти во всех случаях latest_expired_receipt и latest_expired_receipt_info.

НО некоторые сообщения содержали latest_receipt и latest_receipt_info вместо этого. Помимо этого различия структура сообщений была идентичной ("auto_renew_status": "false", auto_renew_status_change_date до expires_date_formatted и т. Д.)

Меняет ли Apple случайную структуру, чтобы сделать реализацию подписки еще более приятной, или есть какая-то логика, когда какая структура используется?

Конечно, я могу просто адаптировать свой серверный код, чтобы проверить, доступен ли latest_receipt ИЛИ latest_expired_receipt, но это было бы быстрое и грязное решение. Я бы предпочел понять, когда ожидать, какой контент / структура ...

...