Что такое ошибка биллинга

Биллинг и проблемы

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

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

Последний недостаток заключается в постоянном учете трафика абонентов БС в базе данных биллинга, как это было в старых версиях UTM5. Это позволяет индексировать трафик клиентов сети и при следственном запросе предоставлять нужную информацию гораздо быстрее. Однако вся эта информация скапливается в базе данных, объем которой будет постепенно наполнятся. Для примера можно привести созданный файл flow-статистики вес которого равен 52 Мб, при этом пропускная способность аплинка составляет 2200 Мбит в секунду.

Такая скорость пропускного потока за месяц может генерировать около 132 Гб flow-статистики, при том что по закону операторы должны сохранять такую статистику на протяжении трех лет а в некоторых случаях и на больший срок. Точно рассчитать размер базы данных с таким потоком поступающей информации достаточно проблематично.

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

Источник

Ошибка биллинга Xbox

Вы можете приобрести все виды контента онлайн с вашим Xbox, такие как фильмы, игры и DLC. К сожалению, при покупке мультимедийного контента в Интернете могут возникать определенные ошибки, и на консоли может появиться ошибка биллинга Xbox. Ошибки при выставлении счетов могут помешать вам покупать контент в Интернете, но есть несколько способов исправить эти типы ошибок.

Ошибка биллинга Xbox, как это исправить?

Исправлено – ошибка выставления счетов Xbox

Решение 1. Изменить платежную информацию

Если вы получили ошибку выставления счетов на Xbox, вы можете попытаться изменить свою платежную информацию. Вы можете легко сделать это, используя свой веб-браузер или напрямую из своего Xbox One или Xbox 360. Чтобы изменить платежную информацию в своем веб-браузере, выполните следующие действия:

Чтобы изменить платежную информацию в Xbox One, выполните следующие действия.

Вы также можете изменить свою платежную информацию на Xbox 360, выполнив следующие действия:

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

Решение 2. Проверьте состояние служб Xbox Live

Xbox Live использует определенные службы для правильной работы, и если одна из этих служб не работает, вы можете столкнуться со всевозможными ошибками выставления счетов. Чтобы проверить состояние служб Xbox Live, просто посетите веб-сайт Xbox. Если служба Покупка и использование контента запущена, вы сможете совершать покупки через Интернет. Если эта служба не работает, вам придется подождать, пока Microsoft исправит проблему.

Решение 3. Убедитесь, что у вас нет остатка на счету

Ошибки выставления счета, такие как 80153021, могут появиться, если у вас есть баланс на счету. Если это так, вы не сможете совершать покупки до тех пор, пока не произведете оплату. Для этого выполните следующие действия:

После урегулирования баланса необходимо проверить, устранена ли ошибка.

Решение 4. Проверьте, соответствует ли ваша страна или регион вашей стране или региону PayPal

Если вы недавно переехали в другое место или страну, у вас могут возникнуть ошибки при выставлении счетов на консоли, пока вы не измените настройки своего региона. Изменить свой регион на Xbox One очень просто, и вы можете сделать это, выполнив следующие действия:

Чтобы изменить свой регион на Xbox 360, выполните следующие действия:

Как видите, изменить свой регион или локаль просто, но есть определенные ограничения, о которых вы должны знать. Во-первых, вы можете менять свой регион только раз в три месяца, так что имейте это в виду. Кроме того, вы не сможете изменить свой регион, если ваша учетная запись в настоящее время приостановлена ​​или если у вас есть остаток средств на вашей подписке Xbox Live.Вы также должны знать, что деньги с вашей учетной записи Microsoft не будут перемещены, если вы решите изменить свой регион, поэтому обязательно потратьте их. Наконец, некоторые службы могут быть недоступны в некоторых регионах, так что имейте это в виду.

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

Решение 6. Попробуйте совершить покупку в другое время

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

Решение 7. Используйте подарочную карту Xbox

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

Решение 8. Добавьте новый способ оплаты

Если у вас есть проблемы с ошибками платежной информации, вы можете рассмотреть возможность использования PayPal для покупки контента в Интернете. Чтобы добавить новый способ оплаты на Xbox One, выполните следующие действия:

Чтобы добавить новый способ оплаты на Xbox 360, выполните следующие действия.

Ошибка при выставлении счета может возникнуть, если информация о вашей кредитной карте неверна или срок действия вашей кредитной карты истек. Чтобы обновить способ оплаты в Xbox One, выполните следующие действия.

Чтобы сделать это на Xbox 360, выполните следующие действия:

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

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

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

Чтобы проверить ваше соединение на Xbox 360, сделайте следующее:

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

Чтобы добавить учетную запись на Xbox One, сделайте следующее:

Чтобы удалить учетную запись Xbox на Xbox 360, выполните следующие действия.

Чтобы загрузить свой профиль Xbox Live на Xbox 360, выполните следующие действия.

После удаления и повторной загрузки вашего профиля проверьте, появляется ли ошибка при выставлении счета.

Решение 13 – очистите кеш

Вы можете исправить некоторые ошибки биллинга, просто очистив кеш. Чтобы сделать это на Xbox 360, выполните следующие действия:

На Xbox One эта процедура немного отличается, но вы можете сделать это, выполнив следующие действия:

После очистки кэша проверьте, устранена ли ошибка биллинга.

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

Источник

Времена дешевой связи закончились

Как известно, в России мобильная связь является одной из самых дешевых в мире. Последние 10 лет стоимость мобильной связи неуклонно снижалась. Однако за последний год тенденция изменилась. В том числе из-за дополнительных расходов, которые государство переложило на операторов связи. Например, из-за закона Яровой о хранении пользовательского трафика.

Есть мнение, что государство негласно разрешило операторам повысить цены и увеличить выручку любым доступным способом. Одним из таких способов являются подписки на контент-сервисы и «ошибки в биллинге». История с подписками знакома многим — методы защиты и противодействия известны. А вот как бороться с откровенным воровством денег за неоказанные услуги, мы разберем сегодня.

Мошеннические схемы операторов связи?

В качестве примера будет не абстрактная ситуация, а вполне реальный случай, произошедший с абонентом МТС с почти 20-ти летним стажем пользования. Читатель отправил свою историю в редакцию Telecom Times. Поскольку оператор связи МТС не отреагировал должным образом на данную ситуацию, считаем правильным публично описать отношение оператора и предупредить других абонентов МТС о возможных подобных манипуляциях в отношении них.

Все помнят историю с «умными» воротами, которые подписывались на платные сервисы через сим-карту МТС. Сегодня, оказывается, SIM-карты МТС могут еще и перемещаться во времени и пространстве. Просто машина времени какая-то.

Исходящие звонки с выключенного телефона

В один из дней абонент МТС зашел в детализацию расходов и обнаружил три платных исходящих звонка. Сим-карта всегда лежит в одном месте в выключенном телефоне, все звонки абонента переадресуют на другой номер телефона. Безусловная переадресация подразумевает списание минут из пакета за каждый переадресованный вызов. Однако в детализации было четко видно, что имели место три платных исходящих звонка. Якобы абонент куда-то звонил.

Диалог с представителем колл-центра МТС можно представить следующим кратким образом. Абонент является клиентом категории VIP.

— Добрый день, у меня три платных звонка в детализации, которых не должно быть. Возможно, это ошибка. Верните списанные деньги.
— Добрый день. Да, видим три платных звонка. Вы находились за пределами домашнего региона.
— Как такое возможно? SIM-карта находится в выключенном телефоне, все звонки идут в режиме переадресации. Платных звонков не может быть в принципе.
— Ничего не знаю. Возврат денег невозможен.
— Возможно, в вашем биллинге была ошибка. Составьте обращение, пусть ваши специалисты проверят, извинятся, исправят ошибку и вернут деньги.
— Я ничего составлять не буду. Идите в офис обслуживания, там пишите заявление.
— Нет, вы обязаны составить обращение по запросу абонента. (Далее идет тирада о том, что данный оператор нарушает, — абонент долгое время работает в сфере телекоммуникаций).

Девушка вынуждена была капитулировать под напором четких нарушений с ее стороны и составить обращение. Всегда просите продиктовать номер обращения. Поскольку ситуация вышла за пределы стандартного обращения, абонент потребовал предоставить официальный ответ по данной проблеме на email. В том числе потребовал проверить корректность работы оператора колл-центра за отказ в составлении обращения.

Поскольку компания МТС запрещает вести запись разговора со своими операторами (при общении с номером 0890 вы не можете подключить третью линию в режиме конференц-связи для записи), точная запись диалога есть у компании МТС.

Обработка претензии

Далее в течение нескольких дней происходит возврат незаконно списанных денежных средств. Еще через 20 дней приходит официальный ответ от компании МТС. В нем извиняются за некорректное поведение оператора колл-центра, признают факт в нарушении работы биллинга, якобы передали проблему техническим специалистам. В качестве компенсации делают зачисление около 30 руб на лицевой счет абонента. Смешная сумма при количестве потраченных абонентом временных ресурсов для выяснения.

Сбой системы или «ручной» биллинг?

Но давайте попробуем копнуть дальше. По факту, МТС признал сбой в работе биллинга. После обращения клиента. О том, что такое биллинг, стоит сказать пару слов. Это сертифицированный программный комплекс, который в автоматическом режиме ведет учет оказанных услуг и их стоимости. Сертифицированный и автоматизированный. Ручное вмешательство должно быть исключено — все расчеты ведут автоматически.

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

Либо в МТС есть режим «ручного» управления биллингом, когда 20-30 рублей как бы нечаянно списываются с абонентского счета. Это мошенничество МТС? И есть вероятность того, что они останутся незаметными в общей большой массе расходов абонентов на связь. Если умножить данную сумму в размере абонентской базы (несколько десятков миллионов абонентов), сумма получается немаленькая.

Мошенничество МТС?

Как можно квалифицировать действия оператора? Есть ощущение, что это может попадать под статью 159 УК РФ. Мошенничество. Оператор связи в данном случае злоупотребил доверием абонента. Денежные средства были списаны без ведома абонента за якобы оказанные услуги связи, которые, по факту, не были оказаны. И должно последовать наказание в соответствии со ст. 159. ч. 1.: «мошенничество, то есть хищение чужого имущества или приобретение права на чужое имущество путем обмана или злоупотребления доверием,
— наказывается штрафом в размере до ста двадцати тысяч рублей или в размере заработной платы или иного дохода осужденного за период до одного года, либо обязательными работами на срок до трехсот шестидесяти часов, либо исправительными работами на срок до одного года, либо ограничением свободы на срок до двух лет, либо принудительными работами на срок до двух лет, либо арестом на срок до четырех месяцев, либо лишением свободы на срок до двух лет».

Какие выводы можно сделать

— Оператор связи МТС злоупотребляет доверием своих абонентов даже с таким огромным стажем и статусом VIP. Или это даже мошенничество МТС? Даже сертифицированный биллинг якобы имеет ошибки. Это вопрос, который будет адресован надзорным органам в лице Роскомнадзора и Роспотребнадзора, которые должны следить за корректностью функционирования систем в составе узла связи (биллинг относится к одному из таких узлов).

— Если оператор связи отказывается принимать обращение по телефону — это нарушение правил оказания услуг электросвязи. Настаивайте — телефонный канал общения при валидации абонента является таким же официальным обращением, как и визит в офис.

— Контролируйте свои расходы хотя бы раз в месяц. Любые подозрительные операции трактуйте в свою пользу. Это оператор обязан доказать и подтвердить законность списаний денежных средств. Каждая финансовая операция должна иметь обоснование — оператор связи обязан предоставлять детализацию услуг.

— по факту незаконных списаний вы можете писать заявление в полицию о возбуждении уголовного дела по ст. 159 ч. 1 «Мошенничество». Читатель Telecom Times так и описал проблему: «Мошенничество МТС?» Только так операторы будут понимать, что контроль идет не только со стороны абонентов, но и государства. Ведь именно государство является гарантом законности всего, что с нами происходит.

Мнение редакции может не совпадать с мнением автора.

Источник

Как не потерять деньги в черном ящике: методы тестирования биллинга

Проверка платных сервисов — один из ключевых инженерных вопросов в тестировании Badoo. Наше приложение интегрировано с 70 платёжными провайдерами в 250 странах мира, и баг хотя бы в одном из них может привести к непредсказуемым последствиям.

В этой статье я расскажу о методах тестирования, которые мы используем в Badoo, и о границах применимости этих методов — этапах тестирования, на которых они максимально эффективны.

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

Меня зовут Владимир Солодов, я Billing QA Engineer в Badoo: занимаюсь проверкой тестовых интеграций и процессинга платежей. В подготовке текста мне помогал мой коллега Виктор Короневич: вместе с ним мы делали доклад на конференции Heisenbug (видео). В статье мы расширили область описания на все интеграции с платёжными провайдерами, которые используются в Badoo, подробнее классифицировали и описали практики удаления внешних зависимостей.

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

Вторая часть статьи, в которой мы рассказываем подробнее об автоматизации тестирования платных сервисов в iOS-приложениях — здесь.

Специфика тестирования биллинга

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

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

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

1. Баги в биллинге критичны для бизнеса.

Первая проблема — репутационная. Пользователь, заплативший деньги за сервис, становится более чувствительным (и менее терпимым) к багам в приложении. Любой отзыв в публичном пространстве, будь то обзор приложения в блоге или комментарий в App Store или Google Play, от пользователя, столкнувшегося с багом в платном сервисе, будет более эмоциональным — это фактор, который приводит к репутационным потерям.

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

Компании теряют деньги тремя путями.

Путь первый — рефанды (refunds). Предположим, пользователь обнаружил, что вы продали ему сервис, который не совсем соответствует его ожиданиям. В этом случае он обращается в вашу службу поддержки. Её сотрудники проводят расследование и выясняют, что ожидания пользователя действительно не оправдались из-за бага в приложении. Вы инициируете возврат денег. В этом случае имеет место рефанд: в результате компания сталкивается с недополученной прибылью, и это самый безобидный способ потери денег.

Путь второй — чарджбеки (chargebacks). Предположим, произошла та же ситуация, только пользователь обратился не в вашу службу поддержки, а в банк, который выдал ему карту, или к платёжному провайдеру. Банк/провайдер инициирует возврат денег. В этом случае мы имеем дело с чарджбеком. Опасность для бизнеса здесь не только в недополученной прибыли. После определённого количества чарджбеков компания получает штраф, а также снижается её рисковый рейтинг. Снижение рейтинга, в свою очередь, приводит к удорожанию стоимости услуг провайдеров платежей.

Путь третий — судебные иски (claims). В самых запущенных случаях могут иметь место судебные иски (в том числе и коллективные), приводящие к самым серьёзным последствиям. Так, в 2015 году после судебного иска регулятора Ofgem компания British Gas вынуждена была выплатить многомиллионную компенсацию пользователям, с которых взимала повышенную плату вследствие ошибки в системе начисления оплаты. Подробнее об этом можно прочитать здесь.

2. Для тестирования интеграций нужны знания и экспертиза.

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

Это может привести к непредсказуемым последствиям — от упущенной прибыли до недовольных пользователей.

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

Рисунок 1. Возможные кейсы биллинга

Есть три основных кейса: ошибка, успешный платёж и возврат денег пользователю. Но у каждого кейса есть детали, каждый случай ваша система должна обрабатывать по-разному.

Ошибки могут быть критичными и некритичными. К некритичным можно отнести ошибку нотификации — когда платёжный провайдер информирует о недостатке средств на счёте пользователя, а к критичным — блокировку платёжного метода пользователя. И если в первом случае вы можете попробовать произвести оплату позже, то во втором — неплохо бы разобраться, почему метод заблокирован. Возможно, пользователь был замечен в мошенничестве и вам стоит более внимательно относиться к его транзакциям.

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

Успешный платёж может быть одноразовым, а может быть подпиской.

Одноразовые платежи (one-off payments) могут быть расходуемыми (consumable) и нерасходуемыми (non-consumable). Пример расходуемого платежа мы рассмотрели в самом начале статьи — это кредиты в Badoo. Пример нерасходуемого платежа можно привести из игр. Предположим, у вас есть персонаж, которым вы играете. Вы хотите купить для него суперспособности, которые действуют в течение некоторого времени. В этом случае покупка относится к классу нерасходуемых платежей.

Подписки (subscriptions). Здесь самое большое разнообразие кейсов. Помимо первичной покупки подписки, у вас может быть:

Рисунок 2. Кейсы биллинга, которые в первую очередь реализуют в системах

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

Итак, с одной стороны, баги в процессинге платежей должны быть найдены до релиза, потому что они могут приводить к самым негативным последствиям. Если сделать это не удалось, то важно максимально быстро понять, что баг попал в релизную версию приложения, исправить его и — самое важное, о чём многие забывают, — «успокоить» пользователей, которые столкнулись с этим багом.

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

Технические проблемы в процессе тестирования биллинга

Рассмотрим их на примере интеграции Badoo c App Store.

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

Мы специально выбрали именно эту интеграцию, поскольку она наиболее сложная и содержит всё многообразие кейсов, которые можно встретить в процессе интеграции сервиса с другими платёжными провайдерами.

Для начала обратимся к одноразовой расходуемой покупке.

Рисунок 3. Процесс осуществления одноразового расходуемого платежа

На шаге 1 пользователь делает запрос на покупку сервиса. Приложение решает, что должна быть произведена оплата, и на шаге 2 управление передаётся платёжному провайдеру (App Store). Шаг 3: пользователю предоставляется форма для совершения платежа. Шаг 4: пользователь предоставляет данные для оплаты. Шаг 5: провайдер выполняет транзакцию и сообщает о результате приложению, возвращая чек (receipt), содержащий полную информацию о покупке (дата, сервис, статус и прочее). Шаг 6: чек, дополненный данными о пользователе, отправляется на сервер для обработки. Сервер обрабатывает данные чека и формирует пуш-уведомление для приложения на седьмом шаге. На восьмом шаге уведомление показывается пользователю.

Проблема в том, что шаги 3, 4 и 5 выполняются на стороне платёжного провайдера, практически не контролируются нами и могут иметь различные вариации. Таким образом, процесс имеет на самом деле не линейную структуру, как показано на рисунке 2, а ветвящуюся (см. рис. 4), и каждая ветка должна быть обработана приложением по-разному.

Рисунок 4. Ветвление схемы состояний одноразового платежа

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

Рисунок 5. Состояния управляемой внешне подписки

Напомню, что подписка Apple, которую мы рассматриваем в качестве примера, является управляемой внешне. Это означает, что пользователь после покупки может управлять ею асинхронно: закрыть, изменить срок действия, запросить возврат средств. Мы видим это на шаге 9. Поскольку действие происходит вне нашей системы, на рисунке я обозначил его пунктиром.

На шаге 10 App Store может изменить статус подписки: продлить, закрыть, ввести в окно грейс-периода.

Чтобы мы могли узнать, в каком состоянии находится подписка, есть шаг 11, который специфичен для таких агрегаторов, как App Store и Google Wallet. На этом шаге система отправляет токен, в качестве которого используется чек (receipt), полученный в самом начале при покупке подписки или после её предыдущего продления.

Шаг 12 — это ответ провайдера. Мы получаем чек с актуальным состоянием подписки. Результат на этом шаге зависит от асинхронных шагов 9 и 10.

Осенью 2018 года Apple для всех реализовала механизм межсерверных (server-to-server) нотификаций, который позволяет уведомлять об изменениях, произошедших с подпиской. Получение такой нотификации отображено на шаге 13. Для большинства других провайдеров механизм нотификаций server-to-server является единственным, поэтому можно утверждать, что пример с Apple покрывает всё многообразие кейсов. В случае с другими провайдерами шаг 13 позволяет исключить из схемы шаги 11 и 12.

На шаге 14 сервер формирует реакцию для приложения на изменение состояния подписки.

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

Рисунок 6. Полный процесс изменения состояний платежей (на примере управляемой внешне подписки)

Оранжевым цветом окрашены части, которые мы не контролируем в нашей системе, и они являются черными ящиками для нас.

Методы тестирования биллинга

Итак, основной технической проблемой при тестировании платных сервисов является наличие «чёрных ящиков», состояния которых мы очень слабо контролируем. Это определяет набор методов, которыми можно покрыть всё многообразие кейсов.

Этих методов не так много, и мы разделили их на три категории: реальные платежи, песочницы и устранение внешних зависимостей от «чёрных ящиков».

Реальные платежи

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

В остальном реальные платежи плохи. Во-первых, это дорого: очевидно, что для того чтобы совершить реальный платёж, нужно потратить реальные деньги. Вы ошибаетесь, если думаете, что в конечном итоге вся сумма вернётся в компанию: во-первых, провайдеры берут комиссию с каждой транзакции, размер которой, как было описано выше, зависит от рискового рейтинга организации и может достигать 40% (и даже больше); во-вторых, вы можете потерять деньги при тестировании платежей в других странах из-за валютного спреда — разницы между курсами покупки и продажи валюты (покупку вы будете делать по курсу банка на продажу валюты, а возврат придёт по курсу покупки).

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

Песочницы

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

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

Таблица 1. Соотношение сроков действия реальной подписки и подписки в песочнице Apple

Срок действия подписок в песочнице Google Wallet, принятый по умолчанию, приведён в таблице 2, и он может настраиваться в консоли продавца.

Таблица 2. Настройка срока действия подписки в песочнице Google

В отличие от песочницы Apple, в песочнице Google можно также проверить триал, грейс-период и т. д., используя соотношение из таблицы 3.

Таблица 3. Срок действия дополнительных функций подписки в песочнице Google

Закрытие подписки тоже может быть реализовано по-разному: в песочнице App Store закрытие выполняется после пятого продления, а в Google Wallet оно выполняется из консоли продавца или на девайсе из Play Store.

Проблема песочниц в том, что провайдеры по-разному относятся к их качеству. Наш опыт показывает, что из более чем 70 платёжных провайдеров, которые интегрированы в Badoo, только две песочницы могут похвастаться полной функциональностью и стабильной работой. Это песочницы Adyen и PayPal. Остальные провайдеры имеют либо стабильные, но урезанные в плане функциональности песочницы (как Google Wallet), либо нестабильные и сильно урезанные в функциональности (как App Store и Fortumo). А есть провайдеры, которые вообще не имеют и не собираются иметь песочницу.

Рисунок 7. Классификация песочниц по стабильности и функциональности

Устранение внешних зависимостей

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

Моки в биллинге — это формирование реакций вашей системы на запросы с заранее определёнными параметрами без реального обращения к платёжному провайдеру (см. рис. 8). Например, запрос к провайдеру СМС-платежей на номер +7111-111-11-11 перехватывается на этапе отправки запроса к провайдеру и формирует реакцию системы в виде успешного платежа. Запрос на номер +7111-111-11-12 также перехватывается, но приводит к реакции на ошибку с кодом «Не хватает средств для проведения транзакции».

Рисунок 8. Схема мока

Фейки в биллинге — это подделки нотификаций (как будто они приходят от реального провайдера) (см. рис. 9). Интеграция с каждым провайдером предполагает ограниченный набор реакций системы на ограниченный набор типов нотификаций или реситов. На основе этой информации для каждого отдельного платежа можно сформировать набор нотификаций (с подписями и прочими фейковыми атрибутами безопасности), которые наша система будет считать реальными нотификациями от платёжного провайдера.

Рисунок 9. Схема фейка

Стабы в биллинге — это редирект на страницу со списком возможных реакций системы вместо отправки и обработки запроса (см. рис. 10), когда мы предоставляем все возможные реакции платёжного провайдера для текущего состояния платежа и вызываем эту реакцию вместо отправки запроса к реальному провайдеру или песочнице.

Рисунок 10. Схема стаба

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

Вернёмся к процессу осуществления одноразового платежа. Шаги 3, 4, 5 являются ключевыми для интеграции: передача управления платёжному провайдеру, отправка запроса провайдеру и получение ответа. При использовании каждого из рассматриваемых способов устранения внешних зависимостей фокус направлен на какие-то из этих шагов: при использовании мока мы моделируем передачу управления и отправку запроса, при использовании стаба — только передачу управления, при использовании фейка — получение ответа. Остальные шаги при этом «выносятся за скобки».

Рисунок 11. Моделирование взаимодействия приложения с провайдером при разных методах устранения внешней зависимости (на примере одноразовой покупки в App Store)

С одной стороны, такое устранение шагов приводит к рискам (например, можно пропустить баг в нетестируемых шагах). С другой — моделирование каждого шага делает метод дороже, поскольку требует изменений в системе. Поэтому на практике мы используем комбинации методов. Например, моки и фейки, когда при отправке запроса на определённый номер не формируется реакция системы, а отправляется фейковая нотификация на точку входа для нотификаций на нашем сервере. Или стабы и фейки, когда при выборе реакции из стаба также отправляется фейковая нотификация. Естественно, подобные реализации должны быть ограничены окружениями для разработчиков и не должны попадать на прод.

Ограничения методов тестирования биллинга

Все описанные методы не являются панацеей. Как же понять, в какой момент лучше использовать тот или иной из них? Для этого предлагаем оценить их по следующим критериям:

Таблица 4. Сравнительная характеристика методов тестирования биллинга

Реальный платёж. Довольно ограниченное количество кейсов. Годовую подписку нужно тестировать год. Но зато это единственный метод, который позволяет тестировать весь процесс интеграции. Он довольно дорогой: мы постоянно тратим реальные деньги, оплачивая транзакции провайдерам.

Песочница. Песочницы, например, у Apple и Google, отличаются. Поэтому ими можно покрыть разное количество кейсов (и точно не все). Песочница не предоставляет возможности полноценного end-to-end тестирования: даже код в самой песочнице может отличаться от кода на проде. Однако это, пожалуй, самый дешёвый метод.

Фейки, моки, стабы — самый гибкий метод. Мы можем покрыть весь набор кейсов. В силу специфики этого метода мы не тестируем весь процесс платежа целиком. Метод недёшев: нужно писать код и поддерживать его в актуальном состоянии.

Выбор метода тестирования

Для того чтобы определить, какой из методов на каком этапе использовать, обратимся к классической пирамиде тестирования.

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

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

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

Рисунок 12. Соотношение этапов и методов тестирования на пирамиде тестирования

Антипаттерны при выборе метода

Информацию о том, что бывает, если нарушается соотношение тестов в пирамиде тестирования, можно найти в большом количестве статей, например в этой.

Давайте рассмотрим примеры трёх антипаттернов тестирования, не соответствующих соотношению на рисунке 12, с которыми мы столкнулись в Badoo.

Реальные платежи внизу пирамиды

Для тестирования с использованием реальных платежей была заведена специальная карта. Она была доступна только узкому кругу лиц. Но однажды один QA-инженер из нашей команды узнал её данные. Имея благие намерения, он решил реализовать автотесты. Естественно, в какой-то момент банк увидел, что в течение очень короткого промежутка времени ему поступают запросы на несколько тысяч платежей, и заблокировал карту. Причём заблокировал так, что мы не могли разблокировать её примерно две недели.

Вывод такой: не нужно использовать реальные платежи везде.

Песочницы внизу и наверху пирамиды

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

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

Последствия использования песочниц внизу пирамиды — появление различных инфраструктурных проблем: при использовании одного и того же аккаунта в песочнице для большого количества платежей размер передаваемого ресита или нотификации может возрастать, потому что Apple накапливает историю покупок. Для одного из пользователей ресит достиг 1 Гб — естественно, тестовый стенд просто не выдержал передачи такого объёма данных.

Устранение внешних зависимостей наверху пирамиды

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

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

Выводы

Спасибо за внимание! Всем большой прибыли и меньше багов!

Источник