Ошибки при проверке внутренних платежей Android-iOS и их решение

Disclaimer. Этот пост написан на основе доклада на SQADays’15. Вы можете также посмотреть видео выступления ^[1] или полистать презентацию ^[2]. Обращаю внимание, что доклад был начального уровня, то есть пост будет интересен в основном менеджерам и начинающим тестировщикам. А также на то, что автор — ненастоящий сварщик и местами делает довольно грубые округления.

Меня зовут Алёна, и я релиз-менеджер. Отдел компании, в котором я работаю, в основном занимается приложениями под iOS и Android. Ещё мы поддерживаем Tizen, Windows Phone, альтернативные сторы, но в данном посте речь пойдёт об Apple iOS Appstore и Google Play.
В обоих маркетах, помимо платных и бесплатных приложений, есть возможность проводить внутренние платежи — ин-аппы (In-App Purchases).

Почему я рассказываю про тестирование ин-аппов? Потому что могу!
Будучи релиз-менеджером, я участвую в проектах обычно в начале разработки и в конце тех итераций, которые заканчиваются выкладкой в сторы. Перед началом проекта выдаю разработчикам ключи и сертификаты, а к концу работы над версией разработчики отдают мне билды для релиза. Но между этими точками есть момент, когда надо завести внутренние платежи — ин-аппы и выдать тестировщикам тестовые аккаунты. И вот на этом этапе иногда случается что-то странное, когда разработчики считают, что у них всё хорошо, а тестировщики — что всё плохо.

Общая информация про тестирование ин-аппов

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

Итак, в том или ином виде в обоих маркетах есть:

• Песочница для тестирования платежей
• Механизм тестовых аккаунтов, чтобы не тратить деньги
• Тестовые билды и тестовые девайсы

Стандартная схема покупки ин-аппов в мобильных сторах:

1. Сначала пользователь жмёт на кнопочку «купить» и вводит пароль. Проходит сама покупка, работают механизмы площадки
2. Информация о покупке передаётся в приложение
3. Потребление купленного ин-аппа (consume)
4. Ин-апп становится доступным для повторного приобретения

Пункты 3 и 4 актуальны только для многоразовых покупок — должны быть, но так происходит не всегда. Подробности будут ниже.

Специфика тестирования Google Play In-App Purchases

Как тестировать и что для этого нужно

Начнём с того, что в случае Google Play мы имеем дело с полупесочницей. Мы будем использовать реальные аккаунты, которые отмечены в девелоперском аккаунте как «тестовые». При этом к аккаунту должна быть привязана банковская карта, но фактически списаний с неё не будет. Ну и благодаря открытости самой платформы, мы имеем полноценные логи и простую установку билдов.
Итак, что нужно:

• Девелоперский аккаунт с объявленными в нём тестовыми аккаунтами
• Тестовый аккаунт с привязанной к нему карточкой и участвующий в бета-тесте
• Опубликованный в бета-тест билд приложения
• Тестовое устройство, залогиненное в тестовый аккаунт. На него скачиваем билд из бета-теста.

Как выглядит, когда всё хорошо:

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

Что может быть, когда всё плохо?

Ошибка -№1 несоответствие версии билда

Тестировать платежи можно только на билде той же версии, что и в админке. Но с тех пор, как введено тестирование не с помощью черновиков билда, а через бета-тест, эта ошибка должна встречаться гораздо реже.
Что делать:

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

Ошибка №2 — плохое соединение:

Если фактически с интернетом всё хорошо, практически всегда лечится переключением с 3g на wi-fi или с wi-fi на другой wi-fi.

Ошибка №3 — купить купленное:

Обещанное отступление. Во многих маркетах есть различие между одноразовыми и многоразовыми ин-аппами. В Google Play оно тоже было, но с февраля 2013 был введён биллинг версии 3 ^[3]. С тех пор ин-аппы бывают “управляемые Google” и “управляемые разработчиком”, а можно ли их купить несколько раз — зависит от того, как разработчик их обрабатывает (консьюмит или нет).

На самом деле пользователь никогда не должен видеть эту ошибку. Если же это происходит, либо разработчик обращается к одноразовым ин-аппам как к многоразовым, либо Google закрутил покупку между Google Checkout и Google Play, надо подождать пару часов и/или перезагрузиться.

Ошибка №4 — [буквы и цифры в квадратных скобках]

Обычно это проблема покупателей из-за неверно настроенного Google Checkout.
Что делать:

• стандартные ритуалы: перезагрузиться и подождать немного
• крайняя мера – очистить данные Google Services

Вроде бы всё хорошо, но ин-апп не начислился

Или Google сказал, что платёж прошёл успешно, а приложение сказало, что нет.
Важно понимать, что в данном случае проблема на стороне приложения. То есть если Google ответил, что платёж прошёл успешно — он всегда однозначно посылает именно такой ответ. Но приложение должно ещё суметь его обработать!

1. Что делать? Подождать, пока программисты починят
2. Это критикал, такие ин-аппы пропадают бесследно!
3. Скорее всего, это серверная ошибка, связанная с подписью

Ещё можно запомнить слова license key ^[4]. Дело в том, что небольшая строка цифр и букв, которая удостоверяет ин-аппы, платные приложения и докачку дополнительного контента, сейчас уникальна для каждого приложения. И если вы по каким-то причинам делаете две версии приложения (на русский и международный рынок, или платную и бесплатную версии, например), есть вероятность, что кто-то где-то забудет поменять эту строчку. Вовремя произнесённые слова “а у нас всё в порядке с лицензионным ключом?” могут сэкономить несколько хлопков одной ладонью по лбу.

Специфика тестирования iOS

Как тестировать

А вот у Apple нас ожидает полноценная песочница. Но значит ли это, что нам будет легче?
Итак, никаких реальных карточек и реальных аккаунтов. При этом тестовый аккаунт привязывается к стору определённой страны, это важно. Ещё не нужно никуда в админку заливать билды, так что за исключением выдачи тестовых аккаунтов эта часть проходит без моего участия.
Но всё не так просто — провижены! Грубо говоря, это списки, в которых перечисляется, какие разработчики имеют право собирать приложение с определённым идентификатором, и на какие девайсы можно ставить получившийся билд.
Ну и две админки — Tunes Connect для промо-материалов, Member Center для разработчиков.

Что нужно для тестирования:

• «Cкелет» приложения в iTunes Connect, только после этого можно завести ин-аппы
• Тестовый аккаунт страны, на которую заведено приложение
• Тестовый девайс, заведённый в Member Center
• Правильно собранный билд, установленный на правильный девайс

Что происходит, когда всё хорошо:

При нажатии на ин-апп появляется окно с подписью [Enviroment: Sandbox].

Что делать, когда что-то не так?

Прежде всего — важная информация о тестовых аккаунтах iOS

Это полностью несуществующий аккаунт, но e-mail должен быть уникальным среди как тестовых, так и реальных акаунтов. У него не нужно вводить информацию о кредитной карте, а дата рождения вводится один раз при создании в админке. Если тестовый аккаунт на устройстве просит ввести что- то, кроме логина и пароля – вы его сломали. Совсем. Надо делать новый.

Ошибка №1 — вам нужно ввести платёжную информацию

Если на такой табличке нажать кнопку “продолжить”, вас попросят ввести информацию о платёжном средстве. Это значит, что вы неправильно привязали тестовый аккаунт. Он может быть привязан к устройству лишь одним способом:

1. Надо отвязать от устройства все настоящие аккаунты
2. Зайти в приложение
3. Тапнуть на ин-апп
4. И ввести логин-пароль

Все остальные способы не сработают и сломают аккаунт, придётся делать новый.

Ошибка №2 — вы не можете совершить эту покупку

Тоже связанная с аккаунтом ошибка. Что это может значить:

1. Заведённое приложение недоступно в стране тестового аккаунта
2. Приложение и тестовый аккаунт принадлежат разным девелоперским аккаунтам
3. Вы используете реальный аккаунт

Ошибка №3 — ограничение на количество покупок

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

Ошибка №4 — да вы же не тестовый пользователь!

Может появиться на устройстве с jailbreak или при крайне плохом соединении с интернетом. Лично не встречала, совет — по возможности не тестируйте на устройствах с jailbreak. Если, конечно, это не часть вашей целевой аудитории.

Доклад был прочитан 18 апреля, с тех пор ситуация изменилась не сильно, за исключением способа выкладки билдов в Google Play для тестирования. Раньше было достаточно просто завести билд как черновик, теперь же надо опубликовать в бета-тест ^[5], что, с одной стороны, увеличивает количество необходимых материалов на этой стадии (надо сразу иметь иконку, скриншоты и описание), но с другой — облегчает обновление билда тем, кто является заинтересованной стороной в разработке, но при этом не углубляется в тестирование. Например, ПМ или дизайнеры, они просто получают пуш «новая версия» как от обычного приложения.

Если вы встречали какие-то иные ошибки самого стора при осуществлении внутренних платежей — будет интересно прочитать о них в комментариях.

Автор: besteto

Источник ^[6]