Каково ожидаемое поведение для синхронизации автоматически обновляемых подписок Google Play/Apple Store с внутренней учетной записью?

В настоящее время мы внедряем автоматическое продление подписки для Google (мы начали с непродления для Apple и уже реализовали процесс дедупликации и проверки на стороне сервера), и главный вопрос сейчас заключается в следующем:

  1. У пользователя есть учетная запись Google A в Google Play и внутренняя учетная запись A в приложении.
  2. Пользователь покупает автопродлеваемые подписки. (Теперь он привязан к внутренней учетной записи А)
  3. Он выходит из внутреннего A и входит в внутренний B.

Таким образом, вопрос заключается в том, каким должно быть ожидаемое состояние для Internal B? По сути, в play market (следовательно, Google BillingClient) будет информация о подписке, потому что она привязана к учетной записи Google, но мы ожидаем, что подписка будет действовать только для 1 внутренней учетной записи (и в любом случае это будет из-за процесса дедупликации). Но в этом случае у пользователя возникает странная ситуация, когда подписка уже куплена ранее (когда он входил в систему с Аккаунтом А), но не действует и поэтому он не может купить для Внутреннего Аккаунта Б.

Я пытался найти ответ по следующей ссылке, но похоже, что у них нет хорошего описания таких случаев: https://developer.android.com/google/play/billing/billing_subscriptions

Мне кажется, что мы должны просто предоставить какой-то UX для этой ситуации, что-то вроде: «Похоже, у вас есть подписка, но вы находитесь не в том аккаунте». Но был бы признателен, если бы кто-нибудь мог ответить на вопрос о том, чего ожидает группа проверки Google/Apple в этом случае.


ios android google-play in-app-subscription
person Peregreen    schedule 14.03.2019    source источник
comment
Уточняю Уже купил, но не действует. Куплены на какой счет? Предполагать А, но быть ясным всегда хорошо.   -  person Mobile Ben    schedule 15.03.2019
comment
@MobileBen да, уже куплен внутренней учетной записью A. Я отредактирую, чтобы включить эту.   -  person Peregreen    schedule 15.03.2019

Ответы (2)


arrow_upward
4
arrow_downward

Если вы посмотрите на другие крупные подписные приложения, такие как Netflix или Spotify, вы можете получить некоторые идеи пользовательского интерфейса о том, как они управляют этим. Если внутренняя учетная запись А подписывается на iOS, а затем входит в систему на Android, вы можете показать в пользовательском интерфейсе, что подписка оплачивается и управляется через iTunes.

В описанной вами ситуации, если внутренняя учетная запись B входит в систему, ожидаемый пользовательский интерфейс будет находиться в состоянии «без подписки». Есть пара крайних случаев, о которых стоит подумать:

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

  2. Убедитесь, что внутренняя учетная запись B не может восстановить покупки по чеку, который был куплен внутренней учетной записью A.

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

Что касается политики. Единственная официальная политика заключается в том, что пользователям нужен способ восстановить ранее приобретенную подписку. Если они могут выполнить восстановление, просто войдя в внутреннюю учетную запись, этого достаточно. Как вы хотите обрабатывать случай «совместного использования учетной записи магазина приложений», зависит от вас. Как и большинство вещей с мобильными подписками, это компромисс между сложностью разработки по сравнению с риском.

person enc_life    schedule 19.03.2019
comment
спасибо за быстрый ответ. Да, мы рассмотрели опыт других популярных приложений с подпиской и внедрили этот UX с оплатой через другую платформу. Плюс также реализована дедупликация чеков, как это описано в документации для Apple Store и Google Play. Этот крайний случай не должен вызывать серьезных проблем, потому что восстановление не будет работать для Internal Account B, я просто был удивлен, что действительно смог найти информацию о политике обработки этого случая. Я считаю, что вы, ребята, достаточно поработали с этим в RevenueCat, поэтому я приму ваш ответ. Спасибо за Ваш ответ! - person Peregreen; 22.03.2019

arrow_upward
0
arrow_downward

Я не верю, что у Apple есть реальная «политика» в отношении надлежащего поведения при подписке. Я бы не ожидал, что они подведут вас, если вы не сделали что-то довольно вопиющее в отношении подписки.

В какой-то степени это понятно из-за различных нюансов, реализация становится зависимой от приложения и от того, как они хотят справляться с вещами.

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

person Mobile Ben    schedule 19.03.2019