Представим ситуацию: вы — аналитик на проекте, и вам нужно проработать реализацию платной подписки в мобильном приложении. Путём нехитрого ресёрча вы находите информацию, что подобная подписка должна реализовываться с помощью In-app purchases (IAP). Вы открываете Хабр в поисках best practicies и… находите множество статей от разработчиков разработчикам про техническую сторону реализации, но не от аналитиков аналитикам про проектирование. Сегодня мы постараемся исправить эту досадную несправедливость!

Всем привет, меня зовут Лиза, я — аналитик Surf. Имею пока что не самый долгий, но уже чрезвычайно насыщенный опыт работы в Fintech, EdTech и MedTech проектах. 

Я поделюсь с вами своим опытом проектирования и подготовки ТЗ для реализации in-app purchases, и для удобства сделаю это в двух частях:

1. In-app purchases — за что и почему? Взгляд аналитика

2. In-app purchases — зачем и как? Взгляд аналитика

В первой статье разберём, что такое in-app purchases и в каких случаях без них можно обойтись, как сторы регулируют IAP и (внезапно) как важны юристы в мобильной разработке.

Что такое in-app purchases и зачем это нужно

Конечно же все знакомы с концепцией приложений-маркетплейсов: это e-commerce приложения, в которых можно покупать разнообразные товары. Они есть у большинства пользователей смартфонов. Для совершения подобных покупок через приложение можно интегрировать SDK, использовать WebView, да хотя бы просто перенаправлять пользователя в web-версию и продолжать флоу оплаты там.

Казалось бы, что покупка тапочек бабушке на дачу, что покупка подписки в Down Dog — разница не велика, но есть одно «но»: 

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

Если попытаетесь это сделать — не пройдёте проверки Google Play и App store. Покупка контента должна быть реализована исключительно с помощью сторов, а если конкретнее — с помощью in-app purchases или IAP. 

Есть вероятность, что в скором времени сторы допустят альтернативные способы реализации in-app purchases. Например, компания Paddle, вдохновившись решением суда по делу Epic vs Apple, анонсировала работу над аналогом App Store IAP.

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

Примеры IAP продуктов

Чтобы было понятнее, какой контент подпадает под IAP, собрала примеры таких продуктов:

• Подписки на приложения с контентом: Down Dog, ArtforIntrovert.

• Подписки на услуги: например, приложения-хранилища данных типа Microsoft OneDrive, редакторы фото вроде Canva:Design, Photo & Video.

• Премиальный контент и возможности: Flo, LinkedIn.

• Всевозможные виды покупок в игровых приложениях: Cut the Rope, Among Us.

• Виртуальная валюта, используемая внутри приложения: Candy Crush Saga, Roblox.

И ещё парочка топов с приложениями IAP: первый и второй. В категорию IAP входят практически все возможные варианты монетизации контента. Однако есть одно исключение.

«Reader» Apps

Если некоторое время провести на форумах, посвящённых IAP, то можно обнаружить, что участники этих форумов почему-то не очень любят Netflix (раз, два, три). 

И дело здесь вовсе не в попсовых сериалах, а в том, что в Review Guidelines от Apple есть одно исключение, для которого не требуется реализация IAP —  это так называемые «Reader» Apps. 

По сути это лазейка для приложений, у которых есть ещё и веб-версии. «Reader» Apps могут не реализовывать покупку контента через приложение вовсе, либо могут переводить пользователя на свой сайт для совершения покупок. 

В Payments policy от Google есть примерно такое же исключение для Consumption-only (reader) apps. Однако наличие веб-версии не является достаточным аргументом для попадания в категорию «Reader» Apps. Существуют чёткие признаки, которым удовлетворяют далеко не все приложения (в отличие от Netflix):

1. Приложение должно специализироваться на следующем контенте: журналы, газеты, книги, аудио, видео.

2. Приложение не должно предоставлять личные услуги (обучающие курсы, тренировки, консультации и так далее).

Комиссия сторов

Я думаю, все догадываются, почему стейкхолдеры завидуют приложениям, попадающим в категорию «Reader» Apps. Конечно же, дело в немаленькой комиссии, которую берут сторы за покупки через IAP. 

Если владелец приложения получил до 1 миллиона долларов в течение 12 месяцев, комиссия составляет 15%. Как только он превышает отметку в 1 миллион, комиссия увеличивается до 30%. 

Чтобы точно рассчитать комиссию с учётом смен подписок, промо-периодов и тому подобного, можно воспользоваться статьёй «How to determine Apple and Google Stores commission rates for in-app purchases».

Типы in-app purchases 

К огромному счастью, типы IAP между платформами не различаются (iOS и Android). Всего их четыре:

1. iOS: Consumable / Android: One-time consumable product — расходуемые и возобновляемые продукты. Например, виртуальная валюта или буст в игре. Пользователь может купить такой продукт, затем потратить его и купить заново.

2. iOS: Non-consumable / Android: One-time non-consumable product — бессрочные продукты. Например, допольнительные фильтры для фото. Такой продукт покупается один раз и доступен всегда.

3. iOS: Auto‑renewable subscriptions / Android: Subscription with auto-renewing base plan — автоматически возобновляемые подписки. Например, подписка на музыку. Оплата будет сниматься до тех пор, пока пользователь не отменит подписку.

4. iOS: Non-renewing subscriptions / Android: Subscription with non-renewing (prepaid) base plan — невозобновляемые подписки. Например, доступ к сезонному контенту. После окончания оплаченного периода подписка автоматически завершится.

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

IAP в РФ сегодня

С марта 2022 года в России начали действовать санкции, касающиеся платёжных систем: Visa и Mastercard приостановили работу в России, российские банки были отключены от Swift. Конечно же эти изменения повлияли на возможности пользователей из РФ оплачивать подписки в приложениях.

В связи с этим Google Play ограничил возможности выпуска и обновления платных приложений в РФ. 

App Store напрямую не запрещал разработчикам выпускать подобные приложения, однако нужно понимать, что, хотя и существуют обходные способы оплаты (раз и два), они не всегда просты и доступны. Проще говоря, пользователям из России нужно постараться, чтобы оплатить контент.

Поэтому, если ваше приложение рассчитано на российский рынок, есть смысл присмотреться к аналогам App Store и Google Play. Например, в RuStore появилась возможность монетизации контента.

Если вы принимаете риски и хотите выпустить приложение с IAP в App Store, то советую ознакомиться со статьёй «Как теперь российскому разработчику с нуля зарегистрироваться в App Store»: там есть пример, как это можно сделать.

Наш опыт реализации IAP

Теперь, когда мы знаем что такое in-app purchases и почему это нужно, — поговорим о нашем опыте внедрения IAP (к слову, это был первый опыт команды). Попутно рассмотрим проблемы, с которыми мы столкнулись, и возможные способы их решения. 

Постановка задачи

Мы реализовывали нативное мобильное приложение (МП) с контентом в виде курсов на зарубежный рынок. У приложения была также и веб-версия (фронт на веб и общий бэк имплементировал другой подрядчик). Заказчик хотел реализовать:

1. Возможность подписки на весь платный контент через веб-версию и через МП. Подписка требовалась авто-возобновляемая с тремя возможными периодами оплаты: месяц, три месяца и год.

2. Возможность покупки отдельных курсов через веб-версию и через МП.

3. В МП должен был остаться и бесплатный контент, доступный пользователям без подписки. 

4. «Hard» paywall при регистрации. Исходное требование звучало так: чтобы пользователь не мог зарегистрироваться без приобретения подписки. Во что оно преобразовалось позже, рассмотрим ниже.

Ну и дежурное и до боли любимое — релиз через два месяца, пацаны, погнали!

Регуляторка IAP

Одна из первых вещей, которая бросается в глаза при поиске информации по IAP: сторы, особенно App Store, очень внимательно ревьюят приложения с такой функциональностью, и почти никому не удаётся пройти ревью с первого раза. 

Конечно же, узнав такие вводные, мы постарались как следует подготовиться. Как оказалось впоследствии, сделать это непросто. Немаловажную роль в частых реджектах играет регуляторка IAP. 

У сторов есть определённые требования к реализации in-app purchases. Если сформулировать их кратко: нельзя вводить пользователей в заблуждение относительно каких-либо услуг, подписки или контента, который вы предлагаете в своем приложении.
Если подробнее — в требованиях для Google Play есть даже примеры как делать НЕ надо, у App Store требования собраны в формате рекомендаций.

Многие требования понятны и легко реализуемы. Я остановлюсь на некоторых, но не буду перечислять все:

1. Сумма, которая будет списываться, должна быть заметнее маркетинговой.
   
   Например, при годовой подписке будет скидка: сумма в месяц будет меньше, чем при месячной подписке. Логично указать эту информацию на экране подписки. НО если пользователь выберет годовую подписку, с него спишется сумма ЗА ГОД, а не за месяц, именно поэтому важно, чтобы реальная сумма списания была очевидна.

   

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

   

3. На экранах с подписками должны быть ссылки на Privacy Policy и Terms of Use.

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

Paywall

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

Что это такое? По сути, это «платёжная стена», блокирующая доступ в приложение, пока пользователь не оплатит подписку. Существую как «Soft» paywall — стены, которые юзер может пропустить и продолжить пользоваться приложением, так и «Hard» paywall — стены, которые пользователь пропустить не может. 

Советую ознакомиться с отличной статьёй по реализации Paywalls.

По исходным требованиям, мы не должны были даже регистрировать пользователя без подписки. Это требование оказалось невыполнимо: подписка должна была производиться в авторизованной зоне. Однако, мы вполне могли не пускать зарегистрированного пользователя дальше платёжной стены.

Осложнялось всё тем, что в нашем приложении была неавторизованная зона, в которой также был доступен определённый бесплатный контент. Но в случае реализации «Hard» paywall, после регистрации пользователь терял бы доступ к этому бесплатному контенту неавторизованной зоны. 

Казалось бы,что такого? Требования заказчика выполняем. Однако в гайдлайнах Google Play мы нашли интересную фразу, что если у юзера есть возможность пользоваться контентом бесплатно, то наши предложения подписки должны это явно показывать. 

Наше же исходное решение не то что не показывало такой возможности — оно не давало уйти с пейволла вовсе. Как мы решили этот кейс, расскажу чуть ниже, а пока можете подумать: как удовлетворить требования заказчика и стора одновременно?

Restore purchases

Другой вопрос, который нас долго мучил: нужна ли в приложении кнопка «Restore purchases»? 

Restore purchases, или восстановление покупок — требование из гайдлайнов App Store. 

Представим ситуацию. Вы купили новый телефон, авторизовались в сторе и заново скачали своё приложение, в котором был куплена подписка. По тапу на эту кнопку метод проходит по вашим платёжным транзакциям и восстанавливает их: как бы проводит заново без необходимости повторной оплаты. Таким образом вы получаете доступ к контенту, за который уже заплатили.

Звучит всё отлично за одним исключением: покупки и так восстановятся без запуска этого метода. Пользователь заходит в новое устройство, логинится в стор со своими кредами — на этом этапе стор уже отображает все его покупки. Затем скачивает приложение и логинится в него — бэк тоже помнит обо всех покупках юзера и со своей стороны возвращает их, как и доступ к контенту. Готово, приложением можно пользоваться. 

Мы долго ломали над этой задачкой голову, перечитывали гайдлайны, форумы. Везде инфа делилась 50/50: где-то было написано, что без этой функции приложение точно реджектнут, где-то,  что если предусмотрены альтернативные способы восстановления, — пропустят. 

Сначала решили не реализовывать эту кнопку вообще, потому что совершенно не видели в ней смысла. Потом всё же нашли пару ооочень граничных кейсов, когда она могла бы сработать, поэтому вопрос оставался открыт.

Ооочень граничный кейс: пользователь запустил транзакцию, но по каким-то причинам не прошла валидация чека. Если пользователь остаётся с тем же устройством, приложение в бэкграунде будет запрашивать повторную валидацию. Если же пользователь меняет устройство, повторная валидация автоматически не запустится: в данном случае как раз кнопка Restore purchases поможет её запустить.

Обращение в поддержку

Собрав несколько таких неоднозначных вопросов мы, как наивные простачки, пошли писать в поддержки сторов. Поддержка iOS с виду обещала быть полезной: два бесплатных обращения от аккаунта разработчика, следующие — по несколько долларов, ответ в течение трёх суток! 

Ответили нам через полторы недели следующим письмом:

Если кратко: присылайте приложение на ревью, там и посмотрим. Мы решили не унывать и написать письмо ещё и в поддержку Android — даже при том, что  Android и iOS позиционируют себя как совершенно разные платформы, через семь дней нам пришёл удивительно похожий ответ:

Таким образом, попытки подстелить соломку оказались тщетны. Нам предлагалось идти сразу в бой.

Наши решения

Кейс с Paywall мы решили достаточно просто: добавили на экран кнопку Log out. Так мы закрыли оба требования:

1. Не дали зарегистрированным пользователям уйти дальше пейволла.

2. Оставили возможность разлогиниться и вернуться к бесплатному контенту.

По Restore purchases мы решили поступить немного иначе: реализовали кнопку, но скрыли её в первой сборке, чтобы проверить, пропустят нас ревьюеры или нет.

Спойлер: сборка iOS прошла ревью почти с первого раза! Что значит «почти»: в первый раз нас развернули за неработающую ссылку на Privacy Policy — досадный баг. Но в остальном замечаний к сборке у ревьюеров не было.

На самом деле нам не до конца известен процесс ревью, так что есть вероятность, что ревьюеры увидели необходимые методы для Restore purchases в коде, и на основании этого пропустили сборку, не обратив внимание, на то, что в UI кнопка скрыта. 

Юридические блокеры

Однако если регуляторка сторов была ожидаемым препятствием на нашем пути, то юридическая тягомотина, с которой нам пришлось столкнуться, — нет.

Google Play

Настройка Payment profile в Google Play Console в общей сложности заняла месяц и три дня. Это был итерационный процесс: стор запрашивал документы, юристы заказчика их отправляли, затем ждали ревью и запроса следующей порции. 

Без этой настройки мы не могли завести продукты в сторе, соответственно, разработка делала всё это время вёрстку и пыталась вслепую отвечать на технические вопросы по флоу.

После того, как мы разблокировались с Payment profile, мы смогли создать продукты в сторе. Но чтобы созданные продукты приходили в приложение, нужен был ещё доступ для релиза тестовых сборок в internal testing. Для этого требовалось внести ещё кучу информации в стор и тоже ждать ревью — это заняло ещё 26 дней.

App Store

Тут вообще интересная ситуация: в общей сложности блочились мы меньше. Но Paid Applications Agreement мы не могли принять не из-за юридических проблем, а из-за бага Apple: кнопка принятия соглашения на экране была задизейблена и мы ждали две недели, пока баг поправят!

Заключение

Какие же выводы можно сделать из первой части нашего невероятного увлекательного и не менее стрессового приключения?

1. Убедитесь в том, что вам действительно нужно реализовывать IAP

   Возможно, вам повезло, и ваше приложение подходит под требования «Reader» apps. Или же оно рассчитано на рынок РФ и монетизация RuStore окажется более подходящим выбором. 

2. Проследите, чтобы дизайнеры ознакомились с гайдлайнами

   К IAP довольно много требований именно с точки зрения интерфейса, поэтому будет здорово, если дизайн будет создаваться сразу с их учётом.  

3. Не рассчитывайте на поддержку сторов

   Ну, тут без комментариев.

4. Приступайте к фиче как можно раньше
   Мало того что она непростая сама по себе, в ней ещё и куча сюрпризов с неожиданных сторон.

5. Запустите юристов в сторы, как только обнаружите блокеры по этой части

   На самом деле я не уверена, что это действительно повсеместная боль. Коллеги с других проектов говорили, что у них не было таких проблем юридического характера. Тут мне достаточно сложно спрогнозировать, возникнут ли проблемы именно на вашем проекте, потому что юридическая работа ведётся заказчиком и команда разработки не особо туда допускается. В любом случае, постарайтесь как можно раньше попасть в сторы и обнаружить блокеры с юридической стороны, чтобы побыстрее их решить.

6. Запросите себе доступы в App Store Connect и Google Play Console

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

В следующей статье разберём сложности в технической реализации IAP.

Больше интересного контента для разработчиков → телеграм-канал Surf BA Team

P. S. Там публикуем кейсы, лучшие практики, новости и вакансии Surf, а также проводим прямые эфиры.