Google In-app-purchase: как проверить, ожидает ли статус покупки расходный продукт? - PullRequest
6 голосов
/ 04 апреля 2019

У меня есть встроенная покупка Android в приложении для Android. Я переопределил метод onPurchaseUpdated, чтобы получить ответ о покупке.

@Override
public void onPurchasesUpdated(int responseCode, @Nullable List<Purchase> purchases) {
    if (responseCode == BillingResponse.OK) {
        //handling purchase logic here
    }
}

Теперь я заметил, что пользователь пытается купить расходный продукт в приложении и, пока его статус покупки находится в состоянии ожидания, через некоторое время он отменяет покупку. Он повторяет этот процесс снова и снова.

Итак, если статус покупки находится в состоянии ожидания, возвращает ли Google BillingResponse.OK в качестве кода ответа? Если нет, то как проверить, находится ли статус покупки в состоянии ожидания или что происходит, когда покупка находится в состоянии ожидания?

Я посмотрел код ответа в справочном документе по биллингу Google Play, но не нашел информации о предстоящей покупке.

Вот ссылка: https://developer.android.com/google/play/billing/billing_reference.html

1 Ответ

0 голосов
/ 12 апреля 2019

Я не смог найти точное решение, но есть обходной путь (довольно надежный), использующий уведомление разработчика в реальном времени для обработки статуса, связанного с подпиской:

Вам следует начать со следующего руководства: https://developer.android.com/google/play/billing/billing_subscriptions#Handle-states

, а затем следуйте руководству по добавлению уведомлений разработчика в режиме реального времени: https://developer.android.com/google/play/billing/realtime_developer_notifications

Таким образом, в основном, оно уведомляет вас, когда изменяется состояние любой подписки, управляемой игрой, и вы получаете флаги типа SUBSCRIPTION_RENEWED, SUBSCRIPTION_PURCHASED, SUBSCRIPTION_CANCELED и т. Д. В этом push-уведомлении.

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

Например: Пользователь A обновил подписку, но подтверждение платежа может занять 24 часа, поэтому у вас есть эта запись в ожидании (по умолчанию), и между ними пользователь решает отменить эту подписку, чтобы вы моглиполучить флаг SUBSCRIPTION_CANCELED, и пользователь снова решает отозвать эту учетную запись, чтобы вы могли получить флаг SUBSCRIPTION_REVOKED; вы можете обновить свою запись, поскольку пользователь повторяет этот процесс снова и снова.

Это может показатьсянемного сбивает с толку, но чтение документов может расчистить путь.

Надеюсь, это поможет, дайте мне знать результат.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...