Plugin.InAppBilling InAppBillingPurchase.PurchaseToken иногда нулевой в производстве

Question

Я использую библиотеку Джеймса Монтемагно Plugin.InAppBilling для Xamarin для подписки на приложения для iOS и Android.До сих пор это работало в основном правильно, за исключением того, что время от времени, только на iOS, InAppBillingPurchase.PurchaseToken возвращает ноль от вызовов на PurchaseAsync и GetPurchasesAsync.

Например, в моей логике восстановления покупок, У меня есть код, подобный этому:

var purchases = await CrossInAppBilling.Current.GetPurchasesAsync(ItemType.Subscription);

// Sometimes we receive purchases with no PurchaseToken.
// Can't verify the purchase without a token.
var verifiable = purchases.Where(p => !string.IsNullOrWhiteSpace(p.PurchaseToken));

На данный момент, verifiable иногда имеет другое количество (0), чем purchases (1).

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

Кроме того, я не уверен, что это имеет значениена проблему, но я не использую перегрузки PurchaseAsync и GetPurchasesAsync, которые принимают IInAppBillingVerifyPurchase, потому что я использую только проверку на стороне сервера (без проверки на стороне клиента).Мой рабочий процесс заключается в том, чтобы совершить покупку, добавить полученный объект InAppPurchase в очередь для обработки, а затем отправить его на наш сервер в качестве отдельного шага для проверки и сопоставления с учетной записью пользователя.Однако, если это недопустимый рабочий процесс или , если известно, что иногда данные PurchaseToken будут доступны через IInAppBillingVerifyPurchase.VerifyPurchase, но не будут прикреплены к InAppBillingPurchase объектам, возвращенным вышеописанными методами , я, безусловно, хотел бызнать об этом.(Что бы это ни стоило, я прочитал документацию и не вижу ничего, что подсказывает это.)

Заранее благодарен за любую помощь.

Answer 1

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

Во-первых, я понял, что Apple имеет в виду под "стилем iOS 6" и "iOS 7".стиль "квитанции.Они не относятся к версии iOS, которая создает квитанции.(Мое современное устройство iOS 12 все еще может и генерирует квитанции «стиля iOS 6».) Вместо этого они относятся к двум различным форматам квитанций, которые были введены в соответствующих версиях iOS.

• Квитанции в стиле iOS 6 поступают от SKPaymentTransaction.transactionReceipt и содержат информацию об одной конкретной транзакции.Это поле теперь устарело от Apple.

• Квитанции в стиле iOS 7 поступают из пакета приложения через расположение, указанное в NSBundle.mainBundle.appStoreReceiptUrl.Эти квитанции содержат полный манифест всех покупок, когда-либо сделанных пользователем.Срок действия чеков также не истекает - вы всегда можете отправить их в Apple для проверки (хотя, очевидно, отдельные транзакции, содержащиеся в них, могут отображаться как истекшие в ответе).Это квитанции, которые вы должны предпочесть.

Причина, по которой это важно, заключается в том, что если вы используете библиотеку Plugin.InAppBilling, то объект InAppBillingPurchase вы получаете от вызова чего-то вроде PurchaseAsync содержит устаревшую квитанцию ​​в стиле iOS 6 в своем поле PurchaseToken.

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

Обратите внимание, что при вызове PurchaseAsync, если вы указываете реализацию IInAppBillingVerifyPurchase, ваш метод IInAppBillingVerifyPurchase.VerifyPurchaseполучит более новую квитанцию ​​iOS7 вместо этого.Однако объект InAppBillingPurchase, возвращаемый PurchaseAsync, по-прежнему получает квитанцию ​​в стиле iOS 6 (если вообще что-то получает).

Лично мне нравится сам объект InAppBillingPurchase.Имеет полезную информацию, упакованную в удобную упаковку.Поскольку я хочу сохранить сериализованные объекты InAppBillingPurchase в очереди, чтобы можно было повторить проверку в случае проблем с нашими серверами, связью и т. Д., Я просто немедленно заменю PurchaseTokenсвойство с квитанцией в стиле iOS 7, которую я вручную извлекаю из пакета.

Если вы сделаете это, убедитесь, что ваш код правильно обрабатывает слегка отличающиеся форматы квитанций iOS 6 и iOS 7.(В наших предыдущих попытках были некоторые ошибки, связанные с неправильным пониманием значения этих терминов.)

Надеюсь, это кому-то пригодится.Удачи!