Несоответствия с документацией в ответ от конечной точки Apple verifyReceipt

Question

Я нахожусь в процессе настройки проверки квитанции для автоматически возобновляемых подписок Apple на нашем сервере и заметил некоторые несоответствия с официальной документацией . При проверке квитанции «песочницы» с помощью конечной точки «песочница verifyReceipt» ответ выглядит следующим образом:

{  
  "auto_renew_status": 1,  
  "status": 0,  
  "auto_renew_product_id": "app.xxx",  
  "receipt": {  
    "original_purchase_date_pst": "2020-03-18 01:11:45 America/Los_Angeles",  
    "quantity": "1",  
    "unique_vendor_identifier": "6D2xxx194",  
    "bvrs": "2",  
    "expires_date_formatted": "2020-03-20 12:27:07 Etc/GMT",  
    "is_in_intro_offer_period": "false",  
    "purchase_date_ms": "1584703627636",  
    "expires_date_formatted_pst": "2020-03-20 05:27:07 America/Los_Angeles",  
    "is_trial_period": "false",  
    "item_id": "15xxx27",  
    "unique_identifier": "cd5xxx424",  
    "original_transaction_id": "100xxx735",  
    "subscription_group_identifier": "20xxx02",  
    "transaction_id": "100xxx439",  
    "web_order_line_item_id": "100xxx419",  
    "version_external_identifier": "0",  
    "purchase_date": "2020-03-20 11:27:07 Etc/GMT",  
    "product_id": "app.xxx",  
    "expires_date": "1584707227636",  
    "original_purchase_date": "2020-03-18 08:11:45 Etc/GMT",  
    "purchase_date_pst": "2020-03-20 04:27:07 America/Los_Angeles",  
    "bid": "app.xxx",  
    "original_purchase_date_ms": "1584519105000"  
  },  
  "latest_receipt_info": {  
    "original_purchase_date_pst": "2020-03-18 01:11:45 America/Los_Angeles",  
    "quantity": "1",  
    "unique_vendor_identifier": "6D2xxx194",  
    "bvrs": "2",  
    "expires_date_formatted": "2020-03-20 12:27:07 Etc/GMT",  
    "is_in_intro_offer_period": "false",  
    "purchase_date_ms": "1584703627000",  
    "expires_date_formatted_pst": "2020-03-20 05:27:07 America/Los_Angeles",  
    "is_trial_period": "false",  
    "item_id": "15xxx27",  
    "unique_identifier": "cd5xxx424",  
    "original_transaction_id": "100xxx735",  
    "subscription_group_identifier": "20xxx02",  
    "transaction_id": "100xxx439",  
    "bid": "app.xxx",  
    "web_order_line_item_id": "100xxx419",  
    "purchase_date": "2020-03-20 11:27:07 Etc/GMT",  
    "product_id": "app.xxx",  
    "expires_date": "1584707227000",  
    "original_purchase_date": "2020-03-18 08:11:45 Etc/GMT",  
    "purchase_date_pst": "2020-03-20 04:27:07 America/Los_Angeles",  
    "original_purchase_date_ms": "1584519105000"  
  },  
  "latest_receipt": "xxx"  
} 

Я особенно хочу указать следующие поля этого ответа:

{  
    ...  
  "latest_receipt_info": {  
      ...  
    "expires_date": "1584707227000",  
    "expires_date_formatted": "2020-03-20 12:27:07 Etc/GMT",  
    "expires_date_formatted_pst": "2020-03-20 05:27:07 America/Los_Angeles",  
    "subscription_group_identifier": "20xxx02",  
    "bid": "app.xxx",  
      ...  
  },  
  "receipt": {  
      ...  
    "expires_date": "1584707227636",  
    "expires_date_formatted": "2020-03-20 12:27:07 Etc/GMT",  
    "expires_date_formatted_pst": "2020-03-20 05:27:07 America/Los_Angeles",  
    "subscription_group_identifier": "20xxx02",  
    "bid": "app.xxx",  
      ...  
  },  
    ...  
} 

Несоответствия с официальной документацией являются:

1. latest_receipt_info - это , задокументированный как массив, однако, это один json объект.
2. В latest_receipt_info, expires_date не в «формате даты-времени, подобном ISO 8601», как говорится в документации , но выглядит как в миллисекундах с начала эпохи (что должно быть expires_date_ms). Однако мы можем найти ключ expires_date_formatted в формате даты-времени.
3. Те же поля, что и в (2), также можно найти в квитанции, однако документация указывает только ключ expiration_date (аналог expires_date в latest_receipt_info в формате даты и времени) и expiration_date_ms (в миллисекундах с начала эпохи).
4. Документированный ключ bundle_id ( здесь и здесь ) нет, но есть ключ bid, содержащий идентификатор пакета.
5. Ключ subscription_group_identifer не содержит точную строку введен в AppStoreConnect в качестве идентификатора группы подписки, как задокументировано ( здесь и здесь ), но содержит некоторое целочисленное значение.

Таким образом, согласно документации, Для меня ответ должен выглядеть следующим образом:

{  
    ...  
  "latest_receipt_info": [  
    {  
        ...  
      "expires_date": "2020-03-20 12:27:07 Etc/GMT",  
      "expires_date_ms": "1584707227000",  
      "expires_date_pst": "2020-03-20 05:27:07 America/Los_Angeles",  
      "subscription_group_identifier": "MY_SUBSCRIPTION_GROUP_ID",  
      "bundle_id": "app.xxx",  
        ...  
    }  
  ],  
  "receipt": {  
      ...  
    "expiration_date": "2020-03-20 12:27:07 Etc/GMT",  
    "expiration_date_ms": "1584707227636",  
    "expiration_date_pst": "2020-03-20 05:27:07 America/Los_Angeles",  
    "subscription_group_identifier": "MY_SUBSCRIPTION_GROUP_ID",  
    "bundle_id": "app.xxx",  
      ...  
  },  
    ...  
}  

• Я не уверен, как справиться с этой ситуацией, это ошибка в API или просто неправильная документация?
• Могу ли я ожидать те же несоответствия для конечной точки производства (может ли кто-то поделиться примером Respo nse, пожалуйста)?
• Как насчет уведомлений в уведомлениях от сервера к серверу , есть ли несоответствия?

Заранее спасибо!

Answer 1

Для всех, кто сталкивается с той же проблемой: мы отправили неверные данные квитанции в наш бэкэнд, поскольку мы запросили квитанцию ​​через устаревшую транзакциюReceipt , а не через appStoreReceiptURL .

Answer 2

Где вы взяли этот пример получения? Вот правильный пример квитанции от verifyReceipt endoint: https://gist.github.com/ren6/3da2d14ea629ab9add489c0e6df1917c

Также я могу рекомендовать вам прочитать статью из нашего блога: https://blog.apphud.com/receipt-validation/

Что касается уведомлений от сервера к серверу Apple, они теперь объединены, т.е. данные возвращаются в той же структуре, что и конечная точка verifyReceipt.