Сохранение/восстановление автопродления чеков без дубликатов

Я разрабатываю приложение с автоматически обновляемыми квитанциями и сохраняю их на сервере, и все работает отлично, пока пользователь не восстановит свои покупки - это вызывает дублирование.

Поле transaction_id отличается для одной и той же квитанции при каждом восстановлении, а поле original_transaction_id, очевидно, одинаково для каждого запуска обновлений, поэтому я не могу его использовать. Поле unique_identifier тоже самое (не понимаю, чем оно уникально). Я использовал поле web_order_line_item_id, и это выглядело нормально, но я только что проверил это с совершенно новой учетной записью и получил дубликат, так что это тоже бесполезно.

Я действительно что-то упускаю здесь? Должно быть поле, уникальное для каждой квитанции, но не меняющееся при каждом восстановлении?


ios in-app-purchase save receipt
person Malcolm Christie    schedule 11.07.2013    source источник
comment
Поскольку вы сохраняете квитанцию ​​на своем сервере, почему бы вам просто не получить квитанцию ​​с сервера?   -  person rocky    schedule 12.07.2013
comment
Я делаю это для большинства сценариев использования, но мне нужно разрешить пользователям восстанавливать покупки на новом или восстановленном устройстве.   -  person Malcolm Christie    schedule 12.07.2013
comment
Я предполагаю, что у вас есть какой-то логин, связанный с вашей подпиской с автоматическим продлением. И я также предполагаю, что вы связываете логин с квитанцией, которую вы сохраняете на своем сервере. Имея это в виду, не имеет значения, является ли устройство новым или восстановленным. Всякий раз, когда пользователь входит в систему, вы можете запросить на своем сервере квитанцию ​​​​и вернуть ее. Мои предположения ошибочны?   -  person rocky    schedule 12.07.2013
comment
Нет, пользователям не нужно входить в мое приложение; у них должна быть возможность просто восстановить квитанции и идентифицировать их по ним без необходимости регистрироваться и запоминать свой пароль и т. д. Он думает, что возможно использование как original_transaction_id, так и даты покупки, но это кажется немного запутанным: /   -  person Malcolm Christie    schedule 12.07.2013
comment
Удачи найти ответ?   -  person Kirill Zaitsev    schedule 04.06.2014
comment
Какие дубликаты у вас есть? Какие поля вызывают дублирование? transaction_id отличается для каждой квитанции, поэтому у вас не может быть дубликатов, если вы используете его в качестве первичного ключа.   -  person gabuh    schedule 06.06.2014
comment
the transaction_id is different for every receipt, so you can't have duplicates if you use that as the primary key На самом деле это означает, что если вы используете transaction_id в качестве PK, вы, возможно, получите две записи в своей базе данных, соответствующие одной покупке. Непонятно — как можно избежать этой ситуации.   -  person Kirill Zaitsev    schedule 08.06.2014

Ответы (1)


arrow_upward
3
arrow_downward

Судя по всему, original_transaction_id и purchase_date — единственные два уникальных значения, которые не изменятся после восстановления покупок. Вы также можете положиться на latest_receipt_info -> web_order_line_item_id, так как он не меняется между восстановлениями (в отличие от latest_receipt_info -> transaction_id). Проверив latest_receipt_info, вы можете узнать expiration_date подписки, которой, по-видимому, Apple считает достаточно для вас.

person avdyushin    schedule 11.06.2014