Як тестувати in-app subscriptions у мобільних застосунках

Привіт. Мене звати Ірина Ольховик, я Head of QA team у компанії SUITSME, що входить до екосистеми бізнесів Genesis. Ми розробляємо мобільну фешн-гру, де кожен може відчути себе стилістом, взяти участь у модних челенджах і проявити креативність у створенні образів для свого аватара.

У статті розповім про тестування in-app purchases (покупки в застосунку), їх види, ключові поняття, докладно розкрию тему підписок у мобільних застосунках і на власному досвіді покажу, які бувають проблеми в роботі підписок.

Матеріал буде корисним передусім QA Engineers, які працюють з мобільними застосунками на платформах Apple та Google та мають in-app purchases.

Види in-app purchases

Іn-app purchases — це те, що користувач купує в програмі на мобільному пристрої. І це один зі способів монетизації застосунку. Від того, наскільки продумано ви вбудуєте сервіс, і кількості помилок на ньому залежатиме прибуток гри й, звичайно, довіра користувачів. Якщо ця функція працюватиме неправильно, Apple та Google review teams вчасно не пропустять застосунок у магазин, а нам важливо дотримуватися дедлайнів.

Тож наведемо головні визначення і розглянемо, які бувають in-app purchases. Їх є три види:

  1. Consumable — модель, за якої користувач купує товар одноразово й отримує внутрішню валюту (у нашому випадку), яку може витрачати на челенджі.
  2. Non-consumable, або lifetime — після одноразової оплати користувач отримує назавжди преміумконтент у застосунку.
  3. Subscriptions — це надання преміумконтенту на певний час (на час дії підписки).

Підготовка тестового середовища для підписок

Для тестування логіки підписок насамперед варто звернутися до гайдлайнів Apple та Google. Компанії надають усе більше можливостей для того, щоб перевірити підписки, не тестуючи їх прямо на продакшені.

З’ясуймо, як працює тестове середовище, та налаштуймо його. У таблиці я спробувала описати деякі моменти, які можуть трапитися вам під час перевірки.

iOS

Android

Тестові акаунти

Для тестування на iOS треба створити sandbox — електронну пошту, через яку ви проводитимете підписки.
Знайти цю інформацію можна за посиланням.
Для створення скриньки потрібно заповнити форму в App Store Connect, розділ Sandbox.

Android дає змогу використовувати власну пошту, щоб робити тестові підписки. Її треба додати в Google Play Console у розділ «Ліцензійні тестери», а також ввійти з неї в Google Play на пристрої.

Тривалість тестових підписок

Звичайно, щоб перевірити тижневу тривалість дії підписки, вам не обов’язково чекати цей період. У тесті вона скорочується до кількох хвилин. Ви можете переглянути її для iOS та Android у вищенаведених скринах.

Закінчення терміну дії підписки

Підписка продовжується 12 разів і на 13-й закінчується автоматично.

Підписка оновлюється п’ять циклів і закінчується автоматично на шостий.

У звичайному акаунті підписка закінчується, якщо її скасовує користувач або якщо він не вніс оплату, а в тестовому підписка не безлімітно продовжується. Вона має певну кількість циклічних оновлень.

Розшифровка рецептів

Під час відкриття застосунку з клієнта відсилається рецепт на валідацію на Apple server. Після цього надходить відповідь, чи є в користувача активна підписка. Зазвичай це набір цифр і літер, і при отриманні неочікуваних результатів (наприклад, я успішно оплатила підписку, а преміумконтент не надали; підписка мала закінчитися, але я й далі користуюся розширеними можливостями застосунку) треба цей файл розшифрувати, щоб локалізувати помилку. Можна скористатися цим сайтом. Треба підставити у перший рядок рецепт, а у нижній — пароль для розшифрування рецепта.

Shared Secret, ви можете запитати у команди розробників або самостійно знайти в App Store Connect в розділі підписок

З розшифрованого рецепта ми можемо дізнатися, де відбувалася підписка, яка версія збірки, час підписки, дата її закінчення тощо.
Усі ці значення ми маємо звірити з тим, що виводимо в базі даних, а також отримуємо в застосунку.

На електронну скриньку, коли ви оформили підписку, надходить інформація про неї, а також Order_id. Він має такий вигляд:

GPA.0000-0000-0000-00000..03, де цифри після двох крапок — це кількість разів продовження підписки.
Якщо зробити пошук за цим Order_id в Google Play Console, ви побачите детальну інформацію щодо підписки, її терміну, кількості оновлень, ціни тощо.

Payment statuses.
При оформленні підписки в базу даних записується її номер, ціна, валюта, тривалість, а також статус

Статуси Apple можна переглянути тут. Що ми дізнаємося за ними?
DID_RENEW — оновлення відбулося успішно.
REFUND — користувач зробив повернення коштів за підписку (на жаль, перевірити тестово цей статус не можна).

Server to Server notifications — Web Hooks

Щоб отримувати інформацію щодо змін у підписці вчасно, ми на проєкті додали Web Hooks — це сповіщення, яке надходять від Apple/Google-серверу до нашого серверу, про статус підписки, що змінився.

Коли це працює? Зазвичай всю оновлену інформацію ми отримуємо, коли користувач відкриває застосунок. На старті ми вивіряємо підписку і в разі змін оновлюємо запис у базі даних і вирішуємо, чи варто показувати користувачу преміумконтент.

Проте трапляється, що користувач довгий час не відкриває застосунок, тому і без Web Hooks ми не знатимемо, що сталося з підпискою. А ще може не пройти оплата. Іноді причина в тому, що користувач через налаштування скасував підписку, поставив її на паузу чи зробив запит на повернення коштів. Це передусім впливає на наші аналітичні дані, прогнози та інші показники.

Логіка роботи підписок на проєкті SUITSME

Щоб більш докладно пояснити, як проводити тестування і які ситуації варто враховувати,
розповім, як працює система підписки на нашому проєкті.

У нас процес такий:

Логіка роботи підписок на проєкті SUITSME

Якщо натиснути на підписку в застосунку, SUITSME (далі — клієнт) відсилає інформацію про підписку до Apple server (1). Apple server вивіряє дані, визначає, чи є product_id, перевіряє метод оплати й відправляє інформацію про успішну підписку з рецептом на клієнта (2). Клієнт надсилає цю інформацію на перевірку серверу (3) і хоче з’ясувати, чи може він отримати преміумконтент. Сервер, своєю чергою, перевіряє рецепт в Apple server (4), щоб упевнитись, що рецепт не зламаний і валідний. Якщо все правильно, Apple server повертає відповідь про успішну купівлю на наш сервер (5). Після цього сервер робить запис у базі даних (БД) і надсилає відповідь клієнту, що можна надавати користувачу преміумконтент (6).

Високорівневий чекліст для тестування підписок

Ми вже ознайомилися з основними поняттями тестування підписок, тож перейдемо до перевірок. Пропоную розглянути високорівневий чекліст, що варто протестувати в логіці підписок.

Вид

Очікуваний результат

Деталі

Підписка

Валідна підписка

Преміумконтент надається користувачу (в нашому випадку ми отримуємо подвійні бонуси в грі); відбувається запис у БД (перевіряємо статус купівлі, час закінчення до наступного оновлення, правильність запису валюти, ціни тощо).

Повторна підписка, поки валідна перша (якщо підписки належать до однієї групи)

Має з’явитися повідомлення, що підписка вже є у клієнта і вона відновиться.

Щоб викликати екран підписки, можна скористатися будь-яким перехоплювачем трафіку, щоб підмінити дані, що надійдуть на клієнта про статус підписки.
Або ж змінити дані в БД про користувача.

Повторна підписка, коли закінчилася перша

Преміумконтент має бути надано користувачу знову.

Варто впевнитися, що користувач має змогу повторно отримати доступ до преміального контенту, якщо хоча б раз його мав.

Підписка з використанням подарункового коду

В App Store на пристрої потрібно ввести код і відкрити застосунок, щоб перевірити, чи преміумконтент доступний.

Такі коди необхідно створювати в App Store Connect.

Зміна тривалості підписки

Даунгрейд

Підписка з меншою тривалістю (наприклад, з місячної користувач переходить на тижневу)

Активна підписка закінчує свою дію, а наступний цикл оновлення відбувається вже з новою тривалістю та за новими умовами.

Робиться запис у БД про новий період підписки.

Апгрейд

Апгрейд чи даунгрейд через налаштування пристрою

Коли ми відкриємо sandbox (тестову пошту для купівлі) на iPhone, то побачимо, що всі підписки, створені в одній групі, доступні користувачеві для переходу.
Він може обрати собі підписку з іншою тривалістю та ціною.

Скасування

Скасування підписки через налаштування пристрою

Підписка змінює статус у БД на Cancelled, і преміумконтент закривається в кінці встановленого періоду.
У БД записується Purchase status — Cancelled, а також дата скасування підписки.

Оскільки з версії iOS 12 ми можемо тестово скасувати підписку, то варто перевірити цей кейс.
Як знайти скасування: Settings (на iPhone) → App Store (гортаємо донизу і натискаємо на sandbox) → серед підписок бачимо нашу активну і натискаємо «Скасувати».

Тимчасова зупинка

Тимчасово зупинити на два періоди оновлень

1. Коли призупинилася підписка, ми маємо пересвідчитися, що преміумконтент недоступний користувачеві.

2. Перевірити в БД, що статус оновився на «ПАУЗА».

Відновлення після призупинення

1. Преміумконтент знову доступний користувачеві.

2. У БД показано, що підписка продовжує оновлюватися.

Відновлення

Відновлення (restore) підписки в налаштуваннях, коли вона ще активна

Тому при натисканні на рестор відправляється запит з інформацією про підписку на Apple та Google і перевіряється валідність рецепта та підписки в ньому. Варто врахувати, що при відновленні підписки не має бути додаткових записів у БД. Або вони мають бути позначені як «рестор», щоб їх помилково не вважали за списання оплати й не враховували в дохід.

На вимогу Apple та Google у налаштуваннях ми маємо показати кнопку відновлення підписки, якщо з певних причин цього не відбулося автоматично.

Відновлення підписки після перевстановлення застосунку

Відновлення підписки на іншому пристрої, проте з одним і тим самим AppleID

Преміумконтент надано користувачу.

Згідно з правилами Apple, користувачі з однаковим AppleID повинні мати змогу відновити підписку на іншому пристрої.

Відновлення, коли підписки в користувача ніколи не було

Преміумконтент заблоковано.

Відновлення, коли підписка вже закінчилася

Преміумконтент заблоковано.

Помилки із сервера

Ніколи не дозволяти робити підписку

Застосунок не крашиться і користувач бачить помилку, що неможливо виконати підписку.

Один з прикладів — це зімітувати таку поведінку через Apple та Google.

Apple: треба зайти в розділ Sandbox users в Apple Store Connect і при створенні sandbox чи її редагуванні поставити чекбокс.

Google: відкрити застосунок і натиснути на підписку, а тоді обрати метод купівлі, щоб вона була успішна чи щоб показалася помилка.

Невалідні дані, що відсилаються на сервер

Підписка не має бути відновленою і преміумконтент не має бути наданий.

Усе залежить від специфіки вбудовування підписок на проєкті. Як приклад — зміна даних, що відсилаються на сервер (підміна рецепта, дат тощо).

Додаткові перевірки

Перевірка UI

Ціна, валюта, відсоток знижки, тривалість — усе вказано правильно, так, як у специфікації.

Перевірка локалізації

Усі тексти коректно показано.
Немає тексту, що виходить за межі чи налазить на інший текст.
Варто перевірити й види валют, адже залежно від суми в доларах зображення ціни в мексиканських доларах чи аргентинських песо може суттєво погіршити зовнішній вигляд підписки.

Перевірка тексту, чи відповідає він нормам офіційної документації (однозначний текст, який не заплутує користувача)

Усі розміри тексту та виділення вказані коректно. Apple має жорсткі вимоги до пропорцій тексту.
Користувач розуміє, скільки триває підписка, яка її ціна, чи є тріальний період, скільки часу він може діяти, знає, як скасувати підписку.

Неодноразово за невідповідність офіційній документації ми отримували відмову від Apple через те, що заплутуємо користувача.
Apple, до речі, має багато скринів-прикладів, яким має бути опис підписки.
Ось тут можете з ним ознайомитися.

Приклади з життя, де знаходили прогалини в роботі підписок

Наостанок розповім про кілька ситуацій з минулих проєктів, де ми мали баги в підписках. Хочу показати, де можна шукати проблему, якщо щось йде не за планом.

1. Будьте готові до того, що App Store може не одразу затвердити новостворені підписки.

Раніше на затвердження йшла доба чи навіть більше, нині це займає менше часу, проте все одно доведеться чекати. Одного разу в нас підписка на тестовому середовищі й Testflight валідувалася коректно, а на продівському білді була недоступна, вискакувала помилка. Як виявилося, проблема полягала в тому, що підписку не затвердив App Store. Це варто перевіряти перед тим, як робити її доступною на продакшені.

2. Перевіряйте унікальні дані пристрою, які відсилаються при виконанні підписки.

На одному з попередніх проєктів була така логіка підписок: якщо в користувачів однаковий IDFA, або Identifier for Advertisers, і в когось з них є підписка, то інший отримає преміумконтент. Однаковий номер легко отримати, вимкнувши рекламний трекінг у налаштуваннях пристрою. Тоді в користувача замість унікального номеру були нулі.

App Store може відхилити підписку, якщо вона занадто дорога для застосунку. Можна отримати таку відповідь з коментарем: «Вміст вашого застосунку не вартує такої суми».

Узагальнимо, що зробить тестування підписок успішним:

  • Треба знати, які є види підписок і як вони працюють.
  • Чітко розуміти, як вони вбудовані у проєкт. Це дасть змогу додавати кейси, які навряд чи ви знайдете у вільному доступі.
  • Варто постійно стежити за документацією Apple та Google.
  • Не бійтеся викликів і помилок — вони нас вчать не повторювати схожого в майбутньому.

Якщо залишилися запитання, з радістю відповім на них у коментарях.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини.

👍ПодобаєтьсяСподобалось18
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дуже корисно та інформативно, дякую!

...цікава стаття, деякий час назад, робив на RN підписки. Маленька ремарка, зверніть увагу, що на Андроіді(PlayMarket) не має нон-консюмебл покупок, тому всі підписки треба зберігати на беку або через АПІ дивитись історію покупок.

дякую за інформацію

дякую за статтю з бойовим досвідом. Бо в доках такого не знайдеш, а тут ще і порівнння з двома платформами одразу!

дуже рада, що інформація є корисною

Підписатись на коментарі