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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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