Разработка системы приема платежей в приложениях операторов
Рассказываем, как с нуля создали продукт для монетизации приложений. Благодаря ему нашему заказчику и его партнерам — операторам большой тройки, удалось заработать.
Коротко о проекте
Клиент: сервис монетизации мобильных приложений
Бизнес-задачи:
— запустить продукт, который позволит работать с крупными мобильными операторами
— получить дополнительный способ монетизации своих продуктов
Решение: разработать систему приема платежей в приложениях операторов
Результаты:— справились с согласованием документации и алгоритма работы с техническими специалистами операторов
— интегрировали систему заказчика с системами биллинга операторов
— Запустили систему приема платежей в срок. На разработку ушел год
500+ мобильных приложений в экосистеме
AppClick — экосистема монетизации мобильных приложений из России. Она зарабатывает на комиссии с продаж в приложениях, например с оплаты подписки, отключения рекламы, валюты для игр. В экосистеме зарегистрировано больше 30 разработчиков и больше 500 приложений.
Проблема: у заказчика есть идея нового продукта, но нет ресурсов на разработку
AppClick пришла идея нового продукта — это система приема платежей, которая встроена в приложение и в которой для оплаты можно использовать счет пользователя у мобильного оператора.
По оценке сервиса, такая система будет пользоваться спросом у мобильных операторов благодаря дополнительному источнику дохода, у пользователей — за счет удобной оплаты. При этом сам AppClick сможет заработать на комиссии с переводов.
Будущие партнеры оценили идею системы, но не сразу согласились на сотрудничество. На 2016 год, когда AppClick запускал систему, такой алгоритм оплаты был еще новым. Поэтому партнеры сначала хотели убедиться, что деньги спишутся как надо и данные пользователей останутся в безопасности, чтобы не было никакого риска для всех участников цепочки.
AppClick проанализировал свои возможности и понял, что ресурсов на разработку и согласование с техническим блоком партнеров не хватает. Либо компания рискует сроками и деньгами, либо подключает внешнего разработчика и тогда гарантированно получает готовую систему.
Еще одна сложность будущего партнерства — договориться с техническими специалистами операторов. Как минимум предстояло обсудить и согласовать документацию, алгоритм и особенности биллинга, выполнить требования безопасности, разобраться с протоколами и другими задачами.
Решение: делегировать разработку подрядчику
AppClick проанализировал ситуацию и пришел к выводу, что выгоднее отдать разработку платежной системы на аутсорс. Компания обратилась к команде Orbitsoft, с которой уже сотрудничала по другим проектам.
Мы закрыли своими ресурсами все задачи для запуска продукта: проектирование, разработку, тестирование и так далее. Еще заказчик избавился от бюрократии и рутины с документами. Наши специалисты разобрались с протоколами и другими требованиями юристов и службы безопасности операторов.
Анализ и согласование с юристами и службой безопасности
Прежде чем приступить к разработке, наша команда обсудила с AppClick и оператором технические и юридические особенности проекта. Мы сразу договорились по ключевым вопросам, например как будем:
- списывать деньги;
- идентифицировать пользователя;
- подтверждать согласие о покупке.
По итогам обсуждения составили документ с описанием набора функций, финансово-юридической схемы и архитектуры системы. Этот документ еще раз финально согласовали с заказчиком, юристами и службой безопасности оператора и передали готовый материал заказчику и его партнерам.
Проектирование и разработка
Чтобы AppClick не тратил ресурсы на административную работу, технические вопросы мы решали напрямую с оператором.
Для начала выбрали программное обеспечение и обсудили с оператором варианты тарифной сетки: разовая покупка или подписка. Потом мы приступили к разработке.
В рамках разработки мы сделали:
- изучили опыт других SDK для оплаты и на их основе разработали шаблоны для интеграции;
- написали набор библиотек для разработчиков, панель управления и модуль работы с биллингом оператора;
- сделали три части в модели управления: для разработчика приложений, мобильного оператора и колл-центра — на случай конфликтных ситуаций;
- для мобильных разработчиков собрали единую версию системы;
- оператору сделали брендированный поддомен.
Тестирование
Перед запуском системы мы убедились, что она корректно работает на стороне заказчика и операторов, а пользователь не столкнется с багами. Для этого мы провели функциональное и нагрузочное тестирование. Потом совместно с оператором протестировали каждое звено отдельно и систему целиком.
По итогам обнаружили ошибки, но перед запуском все устранили. Среди ошибок были такие:
- платеж прошел, а в биллинге деньги не списались;
- данные не попали в статистику;
- пользователь подписался, а подписка не сработала;
- пользователю не пришло подтверждение о списании оплаты.
Запуск
После успешных тестов мы запустили систему и отслеживали результаты. Сбоев не было. Чтобы лучше представить, как работает система, показываем алгоритмы и сценарии услуги.
Алгоритм работы
— Запрос с мобильного телефона пользователя к нам
— Запрос от нас на наш же сервер в контуре оператора
— Взаимодействие сервера с биллингом оператора, чтобы списать деньги с абонента
Алгоритм работы всей системы
—Разработчик публикует приложение с интегрированным платежным SDK AppClick на платформу
— Система AppClick совместно с оператором идентифицирует пользователя и принимает от него платежи
— Оператор сотовой связи совместно с AppClick информирует всех участников о фактических списаниях
Сценарий услуги
Пользователь запускает приложение
Выбирает платную опцию
Нажимает «Оплатить»
AppClick SDK создает лендинг с формой оплаты
Пользователь оплачивает
Если платеж прошел: лендинг с формой оплаты закрывается → пользователь автоматически возвращается на главный экран
Если платеж не прошел: AppClick SDK создает с лендинг с уведомлением → пользователь автоматически на него переходит → на лендинге — подтверждение, что оплата и не прошла, и перечень возможных причин
Результаты: согласовали технические и юридические детали с операторами и запустили систему для монетизации услуг заказчика
На переговоры, создание и согласование технической документации и разработку ушло 18 месяцев. Система запустилась во втором квартале 2016 года.
Разработка не составила особого труда, у нас уже был подобный опыт. Основная сложность — выполнить технические и юридические условия операторов так, чтобы не сорвать сроки всего проекта:
- каждый этап надо было согласовывать сразу с несколькими подразделениями. Чтобы проект не задерживался, мы подключили продакт-менеджера: так разработчики не отвлекались и задачи не простаивали;
- для получения доступа к серверам часть нашей команды оформили на неполную занятость в штат оператора.
Подобных условий было много, и они занимали время. Мы понимали, что это часть работы с крупным бизнесом, поэтому просто заложили в проект больше часов и вкючили в команду специалистов с опытом сотрудничества с корпорациями.
Технический блок проекта
PHP 5.6
CodeIgniter PHP Framework
Zend — PHP Framework/library
Redis
Memcache
Cassandra
WURFL — Mobile Device Database