Подписки iOS IAP / уведомления с сервера App Store на сервер. Замена API verifyReceipt на unified_receipt

#ios #in-app-purchase

#iOS #покупка в приложении

Вопрос:

Я нахожусь в процессе обновления существующей системы подписки iOS IAP, которая уже использует уведомления сервера App Store. Мое существующее решение использует устаревшие latest_receipt поля , latest_receipt_info , latest_expired_receipt и latest_expired_receipt_info . Согласно Apple, все эти поля теперь заменены одним unified_receipt полем.

После просмотра всех необходимых видеороликов WWDC и просмотра небольшой доступной документации у меня все еще осталось несколько вопросов без ответов.

latest_receipt_info Поле задокументировано как:

Массив, содержащий последние 100 транзакций покупки в приложении с декодированным значением в latest_receipt.

Это означает, что этот массив будет содержать всю историю транзакций клиента. Это будет включать не только соответствующую подписку, но и любые транзакционные продукты, которые мог приобрести клиент.

Мой вопрос здесь в том, как я могу найти соответствующую транзакцию в этом массиве? Соответствующей транзакцией в этом случае будет та, которая вызвала событие (например CANCEL ). Мне нужна эта транзакция, чтобы обновить нашу серверную базу данных, чтобы отразить текущий статус подписки. Например, для обновления даты окончания подписки cancellation_date на CANCEL событие .

У меня аналогичный вопрос относительно pending_renewal_info массива. Из существующей документации мне неясно, все ли клиенты с активным (или, может быть, даже истекшим?) подписка всегда будет содержать запись в этом массиве.

Массив элементов, который ссылается на автоматически возобновляемые продления подписки, которые были открыты или завершались неудачно в прошлом.

Мне также нужно найти соответствующую транзакцию в этом поле, чтобы выполнять такие действия, как переключение статуса подписки на DID_CHANGE_RENEWAL_STATUS событие или обновление статуса выставления счетов на DID_FAIL_TO_RENEW событие. Из документов не похоже, что в одном достаточно информации pending_renewal_info для вычисления текущего статуса продления подписки.

В целом мой вопрос действительно сводится к:

Могу ли я быть уверен, что в обоих будет запись unified_receipt.latest_receipt_info unified_receipt.pending_renewal_info , соответствующая событию верхнего уровня auto_renew_product_id ? И если да, то как мне найти соответствующий объект в соответствующем массиве? Будет ли только одна запись для каждого auto_renew_product_id или я должен выполнить поиск в массиве и извлечь первое совпадение?

Ответ №1:

Я обнаружил, что транзакции внутри unified_receipt.latest_receipt_info массива упорядочены по дате покупки от последней до самой старой. И убедитесь, что вы можете узнать событие верхнего уровня auto_renew_product_id .

Однако для обновления статуса подписки или статуса выставления счетов я использую возвращаемое значение from /verifyRecipt , которое вы можете получить, запросив на сервере Apple verifyReceipt данные квитанции и пароль (https://developer.apple.com/documentation/appstorereceipts/verifyreceipt ). Отмечено, что входные данные квитанции unified_receipt.latest_receipt , а ответы имеют ту же структуру, unified_receipt что и .