специалист по биллингу что это
Как там биллинг делается: когда заказчик и разработчик говорят на разных языках
Биллинг — не просто калькулятор
Биллинговые системы давно не просто ведут баланс клиента и выставляют счета. Они глубоко интегрированы в бизнес: обеспечивают контроль трафика, управляют процедурой предоставления доступа к услугам, предоставляют клиенту отчет о расходах в разных разрезах — за месяц, за год, с момента последнего платежа. Плюс биллинговая система, как правило, должна поддерживать множество балансов пользователя: монетарный и несколько вещественных (бонусы, минуты разговора, гигабайты трафика и т.д.). Не говоря уже о партнерских программах и прочих вариантах кросс-продаж. То, что называется современный конвергентный биллинг. Реализуется он за счет интеграции тарификатора с другими модулями и подсистемами: CRM, PRM, BPM и т.д. Для разработчиков это не “сокровенное” знание. Как говорится, разделяй функции и властвуй. Но для пользователей биллинга, даже технически грамотных, мысль, что с “калькулятором” сложновато общаться напрямую, порой оказывается новой.
Пример из нашей практики. Клиент — небольшая, но перспективная компания. У них не хватало бюджета на биллинговый комплекс целиком, они попросили убрать модуль BPM (business process management). Нужно отдать должное, там работали достаточно продвинутые в техническом смысле ребята. Сказали, возьмут open source решение, настроят, интегрируют с системой. Мы согласились. А через четыре месяца “утонули” в их обращениях в техподдержку по поводу некорректных данных.
BPM — система, которая, помимо прочего, при подключении абонента занимается валидацией данных, и не пропускает тебя на следующий шаг, пока ты не заполнишь все необходимые параметры — технические и персональные. А они от BPM отказались, и нарисовали просто интерфейс для ввода данных. Люди, которые принимают заявки на подключение — не высокооплачиваемые специалисты, там большая текучка, малое время обучения персонала. Естественно они постоянно делали ошибки при внесении данных. Итог — в конце месяца компания выставляет счета, а тарификатору не хватает параметров. Он “ругается”, выдает сообщения об ошибках. Клиент звонит в поддержку. В конце концов, мы приняли решение подарить им BPM в дефолтных настройках. У них все стало сходиться, а у нашей техподдержки стало меньше головной боли. Теперь мы вообще не продаем биллинг без BPM, кроме случаев если он уже внедрен и есть варианты интеграции с ним. Если у клиента не хватает денег на минимально необходимый комплект, предлагаем аренду или аренду с возможностью выкупа через пять лет. Или, если это какой-то стартап, но видно, что люди серьезно относятся к делу и у них есть перспективы, предлагаем схему ревенью. В любом случае это бережет нервные клетки и нам, и руководству компании-клиента.
Гибкость — понятие растяжимое
Непродуманная архитектура биллинговой системы оборачивается не только техническими сбоями. По нашему опыту, в 70% случаев необходимость замены биллинга возникает из-за недостаточной ее маркетинговой гибкости. Телеком-рынок сейчас перенасыщен, и заполучить себе новых клиентов компании могут, только отбив их у конкурентов. Даже крупные провайдеры, осваивая новые ниши и расширяя территорию присутствия, начинают демпинговать, а уж новым игрокам на рынке “сам бог велел” привлекать к себе внимание уникальными предложениями. Разворачивается настоящая война тарифов. И тут уже маркетологи хватаются за голову: “Мы сможем вывести в продажи ваш новый инновационный тариф “Супер-Новогодний” только к июлю”, — приходит сообщение от IT-отдела.
В чем проблема. В очень небольшом числе биллинговых систем есть, например, отдельный модуль продакт-каталог, который позволяет легко комбинировать услуги в пакеты и настраивать акции. Параметры которыми он оперирует могут быть как услуги так и отдельные параметры такие как минуты разговора, пакеты трафика или услуги предлагаемые партнерами(так называемые услуги третьих лиц), например билеты в кино или поездки на такси. Есть мнение, что продакт-каталог — это вообще элемент CRM-системы, а не биллинга. Но да будь оно даже так, не во всех компаниях есть отдельная CRM. Многие обслуживание абонентов ведут прямо в биллинговой системе. А это значит, любая новая услуга, новый тариф, новая акция — и “айтишникам” нужно не собрать ее в конструкторе, а добавлять поля и писать строчки кода. Вот уже и июль не за горами.
Между централизацией и автономией
С подобными проблемами в плане маркетинга и продаж сталкиваются и крупные компании, разросшиеся за счет поглощения региональных операторов. Разные биллинговые системы в филиалах не позволяют, например, запускать масштабные акции сразу по всей стране. Страдает отчетность и аналитика: собрать данные по подключениям и пользованию услугами со всех этих разрозненных систем просто невозможно. Частичное решение проблемы — зонтичная CRM, в которой есть продакт-каталог. Некоторые компании так и поступают — торгуют из CRM, а тарифицируют в биллинге. Для этого в компании должен быть действительно продвинутый IT-отдел. Интегрировать написанные на разных языках и по разным принципам биллинговые системы с единой CRM — непростая задача.
Но есть одно извечная проблема, которую распределенные системы решить не в силах — это банальный фрод на местах. У нас было несколько таких примеров. В частности на Украине, где мы внедряли централизованный биллинг, перенося данные из недавно приобретенных региональных филиалов. Когда мы мигрируем данные, мы делаем ряд проверок и сравнений, все несоответствия попадают в соответствующие отчеты, и после этого обычно начинает шевелиться служба безопасности компании-заказчика. Чего там только не находится. Абоненты, подключенные мимо учетных систем, “нулевые” тарифные планы и т.д… Было и откровенное мошенничество: компанию продали, а квитанции абонентам еще какое-то время выставляли на левые реквизиты.
Организация единого расчетного центра делает все такие ситуации прозрачными, в регионах остается только функция абонентского информационного обслуживания поэтому возможности для фрода практически не остается. Плюс большая клиентская база, сведенная в единую систему, позволяет на совершенно ином уровне анализировать и прогнозировать поведение клиентов. Мы постепенно начинаем применять к таким большим данным наши системы аналитики построенные на машинном обучении. Например, можем выделить в клиентской базе “группы риска” — тех, кто в ближайшее время может отказаться от услуг компании. Это выявляется по тому, как люди платят, как они пользуются сервисами, личным кабинетом, как общаются с колл-центром, сколько и по каким причинам у них блокировой.
Правда, централизация биллинга приносит с собой другие проблемы. Нужно, чтобы региональные филиалы сохраняли долю технической независимости. Иначе, если вдруг центральный расчетный центр окажется “вне зоны доступа”, обслуживание абонентов в регионе может пострадать. Мы ее решаем за счет “выносов” на периферию: серверов авторизации, элементов сбора и обработки трафика, элементов сервис-провижининга. В частности для мобильных операторов наша препейдная платформа(Forward Fusion) может тарифицировать услуги автономно и ждать, когда восстановится связь, чтобы синхронизировать данные с биллинговым центром. Региональные абоненты при этом могут заметить, что стал недоступен личный кабинет, но деградации предоставляемого сервиса при этом не происходит.
Сервер, который поставил Джек: где хранятся данные?
Есть много вариантов, как и где разместить биллинговую систему. Часто компании переживают за сохранность данных клиентов, сами покупают сервера и ставят в своем дата-центре. Но не все могут потянуть их качественное обслуживание. Иногда у клиента что-то сломалось, а он даже не понимает, что это на его стороне. Звонит нам в техподдержку, и уже наши админы ему рассказывают, где поломка, какой сервер не отвечает. У нас система настроена так, что она постоянно “мониторит” по многим параметрам обслуживаемые системы, и поднимает тревогу, если что-то не так. Так что мы заранее можем сообщить, что кончается память или скорость какого либо важного процесса снизилась ниже нормы. Но это к сожалению не отменяет форс-мажоров.
Другой вариант — когда клиент размещаться хочет у себя, а мы поставляем программно-аппаратный комплекс, это делается когда клиент хочет чтобы мы програрантировали ему определенную производительность по критическим для него сервисам. В таком случае в стоимость “железа” сразу закладывается стоимость его трехлетней поддержки от производителя. Тогда оно держат запасные комплектующие и если что-то ломается, то их специалисты выезжают на место с запчастями в течение суток и ликвидируют поломку.
Бываю ситуации когда наоборот, привозят свои сервера и ставят в наш сертифицированный по Tier III дата-центр.
Еще один распространенный вариант — у нас арендуют вообще все. Тогда мы полностью отвечаем и за “железо” — и за обслуживание, и за то, чтобы вовремя увеличивать необходимые мощности. По этой причине в определенный момент мы стали использовать частные облака. Если у нас выросла нагрузка, мы меняем настройки, и нам выделяются дополнительные вычислительные мощности. Не нужно бесконечно заниматься непрофильным для нас “апгрейдом” оборудования. Российские компании, которые сегодня предлагают услуги публичного облака, к большому нашему сожалению пока не могут предоставить тот уровень гарантированной производительности, которого требует биллинговая система. У них можно хостить сайты, можно разворачивать интернет-магазины или поставить 1С. Поэтому нам пока приходится активно участвовать оптимизации и тестировании решения для различных частных облаков, например недавно начали использовать OpenStack.
Базы данных: важно не только где, но и как
Важность выбора базы данных для биллинга сложно переоценить. Высокой производительности тут можно добиться, только оптимизировав биллинговую систему под конкретный продукт. Forward Billing оптимизирован под работу с двумя СУБД: Oracle Database и PostgreSQL). В прошлом году Forward Billing был включен в реестр российского ПО, разрешенного для использования в государственных компаниях. И вот недавно пришла новость, что через полгода из реестра начнут исключать разработки на базе иностранных СУБД. С точки зрения государства, это понятно. В условиях, когда чуть не каждый день под санкции попадают все новые российские компании, им хочется обеспечить полную независимость российского ПО. Но для вендоров это грозит приличными дополнительными затратами. Думаю в этом вопросе мы как и весь остальной рынок ждем от законодателей более четких разъяснений на этот счет и после этого будем корректировать свою стратегию.
SLA: определитесь с приоритетами
Где-то в идеальном мире уровень техподдержки от поставщика определяет четко прописанное SLA — Service Level Agreement, оно же Соглашение об уровне оказания услуг. Чем SLA отличается от просто договора, где фиксируются положенные клиенту часы поддержки? В нем прописаны конкретные требования к сервисному обслуживанию: скорость приема заявки, время решения проблемы — и система штрафов, которые накладываются на поставщика, если требования не соблюдены.
Как показывает практика, чтобы SLA стал эффективным инструментом регулирования отношений между заказчиком и поставщиком, заказчику придется провести некоторую аналитическую работу. Нужно понять, как инциденты будут критическими для конкретного бизнеса, а какие не стоят того, чтоб паниковать. Большинство наших клиентов так или иначе используют наши базовые SLA многократно проверенные и на наш взгляд являющимися оптимальными.
Часть сталкиваемся с тем, что небольшие компании, которые приобретают готовые “коробочные” решения для биллинга в случае возникновения проблем оказываются 376-ми в очереди на техподдержку. Часто для таких компаний более оперативной оказывается помощь сообщества пользователей этого продукта на интернет-форуме.
Случаются, правда, и другие крайности. Один потенциальный заказчик, небольшой виртуальный мобильный оператор, пришел к нам как раз после того, как сильно “обжегся” с поддержкой биллинговой системы. В результате этот клиент предложил нам “сумасшедший” SLA, умножив наши стандартные требования по срокам реагирования и штрафам чуть ли ни в сто раз. Нам к сожалению не удалось его переубедить и он продолжает обслуживать своих абонентов на свой страх и риск.
От стажёра до сеньора в компании-разработчике биллинга
У управленца компании-разработчика биллинга есть два пути построения команды. Первый – набрать уже готовых «сеньоров» и непрерывно создавать такие условия работы, чтобы они использовали навыки и опыт по максимуму, развивались и при этом не передрались. Второй – создать команду из микса новичков, «мидов» и профи, чтобы те общались, влияли друг на друга, учились и росли внутри компании. Я против замкнутого круга а-ля «нет опыта – нет работы – нет опыта» и не вижу проблемы в найме начинающего разраба. В Forward Telecom давно действует стажерская программа, которая стала трамплином карьеры для многих работающих сотрудников.
Сейчас расскажу, как я вижу путь развития разработчика биллинга, и в какой последовательности нужно осваивать профессиональные навыки.
1. Изучить язык программирования
Для начала – любой. В приоритете Java, Python и JavaScript, но для получения базовых знаний подойдут Ruby, Go, С, С++. Как учить? Проходить платные и бесплатные курсы, могу посоветовать обучение от Golang. Если уровень английского позволяет, смотреть зарубежные видео – это неплохой дополнительный скилл.
2. Понять концепции ОС
В основе операционных систем семь составляющих, которые нужно знать и уметь объяснять принцип действия:
3. Привыкнуть к терминалу
По аналогии с фобией чистого листа есть фобия пустого черного экрана с мигающим курсором. Придется ее преодолеть, чтобы научиться писать хорошие команды в командной строке.
Обязательно знать:
4. Сеть и безопасность
Биллинг тесно связан с сетью и требованиями защиты данных. Нельзя писать онлайн-сервисы, не понимая, как работает сеть, поэтому нужно выучить основные понятия и протоколы: DNS, модель OSI, HTTP, HTTPS, FTP, SSL, TLS. Тогда при встрече с ошибкой Connection Refused вы будете знать, что делать.
5. Серверы
После изучения принципов передачи информации в сети можно приступить к основам работы серверов. Начните с веб-серверов: IIS, Apache, Nginx, Caddy и Tomcat.
6. Изучить инфраструктуру как код
Считаю, что этот этап – один из самых важных. Придется разобраться в трех обширных темах:
7. Изучить CI / CD
Еще один полезный навык для разработчика биллинга – уметь настраивать конвейер для непрерывной интеграции и доставки. В области CI / CD есть инструменты Jenkins, TeamCity, Drone, Circle CI и другие. Спойлер: изучения широко используемого Jenkins на первых порах будет достаточно.
8. Контроль ПО и инфраструктуры
Ключевая цель — разобраться в основах мониторинга приложений. Инструменты в этой области делятся на три группы:
9. Облачные сервисы
В недалеком будущем каждое приложение или ПО будет иметь облачный аналог. Рано или поздно разработчики сталкиваются с облаками, так что почитайте о популярных облачных провайдерах (AWS, Google Cloud и Azure) и основах технологии.
10. Работа с БД
Все текущие проекты используют базы данных, и опыт взаимодействия с СУБД и SQL облегчит начало работы. Научитесь писать SQL запросы, использовать explain и изучите принципы работы index. Самый простой путь – пройти курс. А еще можно попрактиковать навыки по документации Postgres, поиграться с репликацией.
11. Прокачать софтскиллз
Неожиданно выбивающийся из общей канвы пункт, но не менее важный. Для начала – запаситесь терпением. К ситуациям типа «почини утюг, тыжпрограммист» привыкаешь быстро, а вот к срокам запуска новых проектов нужно быть морально готовым. Если в программировании вы от нуля до года и считаетесь Junior, готовьтесь к критике и учитесь принимать ее, ревью кода наставником – процесс зачастую болезненный. Но одновременно обязательный скилл – умение отстаивать свою точку зрения и конструктивно спорить, иногда в споре рождается истина. Разработчики никогда не перестают обучаться, потолка в профессии практически не существует, так что обучаемость и ЖЕЛАНИЕ узнавать новое – основа вашего развития.
Меня часто спрашивают, когда новичок достигает уровня middle, а когда уже можно гордо именоваться «сеньором». Я считаю, что момент перехода от уровня к уровню определяет не количество отработанных лет, хотя практические навыки и являются ключевым критерием. Как раз-таки софтскиллз зачастую определяют скорость роста разработчика: обучаемый и трудолюбивый новичок уже через несколько месяцев может писать качественный код на нескольких языках и уметь работать в команде. А разработчик с опытом 10 лет может оказаться неспособным к решению нестандартных задач, управлению командой и иметь однобокие навыки.
Так я вижу путь развития разработчика биллинга, так мы растим квалифицированных спецов в нашей команде Forward Telecom. Кажется, ничего не упустил, но я всегда благодарен за полезные дополнения по существу.
Биллинг – что это такое простыми словами
Что такое биллинг в современном понимании?
Английское слово «биллинг» — означает выставление счета за оказанные услуги. В наши дни оно имеет несколько понятий.
Термин применяется в различных отраслях народного хозяйства: медицине, торговле, ЖКХ и т. д. Большое количество людей сегодня сталкивается с данным понятием, как с определением, касающимся оплаты оказанных работ. Определение широко используется в сотовой связи или при обеспечении доступа к интернету.
Основной функцией биллинга является перевод денег потребителя на лицевой счет компании за оказанные услуги. Биллинговая система справляется с задачей и защищает пользователя от мошенников.
Биллинг в этом смысле представляет собой ряд последовательных операций, которые требуют программного и аппаратного обслуживания с юридическим и банковским обеспечением всех этапов зачисления платежа.
Биллинговые системы
Только крупные предприятия могут позволить себе организацию собственной биллинговой системы. А более мелкие фирмы и частные лица используют поддержку специализированных биллинговых компаний. Основной процесс выставления счетов заключается в определении количества предоставленных услуг.
Если это доступ к интернету или телефонная связь, программное сопровождение фиксирует время звонка или часы, проведенные пользователем в глобальных сетях. Далее, программа производит расчет в соответствии с тарифами, указанными в программном обеспечении компании.
Затем в автоматическом режиме, по заранее заданному графику приложение направляет информацию пользователю о стоимостях полученных услуг, а поставщику информацию о поступлении оплаты и возможности вывода денежных средств с вычетом согласованного платежа за эксплуатацию этой системы. Многие виды бизнеса используют циклический биллинг.
Циклический биллинг
Циклический биллинг — это стратегия выставления счетов, которая включает ежедневное создание и обновление непогашенных остатков на счетах клиентов. Это позволяет подготовить единый счет-фактуру, охватывающий весь период, а не выставлять счета покупателям в каждом отдельном случае.
Существуют преимущества, связанные с моделью выставления счетов за циклы, которые применяются как к поставщику, так и к заказчику. Коммунальные предприятия регулярно обновляют учетные записи в зависимости от объема использования за определенный период.
Как правило, расчетный период составляет тридцать дней или один календарный месяц.
В течение этого времени учетная запись абонента время от времени обновляется, отражая использование предоставленного обслуживания. В конце текущего цикла счет за все тридцать дней завершается и направляется пользователю для оплаты.
Сферы использования циклического биллинга
Различные телекоммуникационные услуги также используют циклический биллинг. Например, бюро телеконференций часто рассчитывает стоимость каждого звонка, проводимого данным абонентом, и добавляет расходы и подробности к счету, подготовленному специально для этого периода.
Предполагая, что потребитель проводит еженедельную телефонную конференцию, расчет за цикл будет содержать информацию, связанную с каждым из этих вызовов, которые обычно располагаются в хронологическом порядке. Использование цикличности выставления счетов имеет ряд преимуществ для всех участников.
Для поставщика использование этой модели вместо выдачи отдельных счетов-фактур по каждому заказу или событию означает, что на подготовку, проверку, печать и отправку счета расходуется меньше времени. Поскольку все операции для одного периода отображаются в одном счете, поставщик также экономит время и ресурсы, когда платежи получены, и их необходимо разместить в бухгалтерских записях.
Для клиентов периодичность выставления счетов позволяет управлять только одним счетом в течение месяца. Не затрачивая времени на поток отдельных счетов, которые должны быть оплачены индивидуально. Пользователь также экономит время и, возможно, деньги, если оплата каждого счета сопряжена с какими-либо расходами. Такими, как почтовые расходы или плата за прием онлайн-платежей.
Циклический биллинг обычно используется, когда отношения регулируются договором или носят регулярный характер. Для клиента не является чем-то необычным пройти проверку кредитоспособности до того, как поставщик заключит этот тип соглашения с потенциальным потребителем. Модель хорошо работает для счетов кредитных карт, коммунальных услуг и даже для вкладок в местных клубах или магазинах.
В современном компьютеризированном обществе растет число предпринимателей, оценивших удобство применения электронных платежных систем при получении оплаты за предоставленные услуги. Этим объясняется растущий интерес к биллинговым компаниям, осуществляющим вышеописанные технические мероприятия этого процесса.
Биллинг в большом проекте
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в Badoo и что можно встретить на рынке платежных шлюзов. Сразу предупреждаем, что в статье вы не найдете конкретных цифр по обороту средств компании, но все остальное будет не менее интересно.
Что такое «биллинг»
Для нас биллинг ― это всё, что связано с получением денег от пользователей: конфигурация цен, страница приема платежей, непосредственно прием и обработка платежей, оказание оплаченных услуг, различные промоакции и, конечно же, мониторинг всего вышеописанного.
Изначально, как и во всех стартапах, у нас не было платных услуг. Первые серьезные шаги в сторону монетизации начались в далеком 2008 году, при том что официально сайт был запущен в 2006-м. Для экспериментов была выбрана Франция, а оплата принималась только через SMS. Сам прием платежей был организован на файлах. Каждый запрос записывался в отдельный файл, который затем перекладывался bash-скриптами из одной папки в другую, что означало смену статусов обработки. База данных использовалась только для учета успешно обработанных транзакций. Такая схема успешно проработала чуть больше года, после чего ее стало сложно поддерживать, и мы решили отказаться от файлов и переписать всё с использованием БД.
Разработка новой версии прошла достаточно быстро, так как стран, где были доступны платные услуги, было не много. Но она была рассчитана только на прием платежей через SMS, из-за этого у нас даже до сих пор сохранилось несколько забавных артефактов, например, поля MSISDN (номер телефона) и short code (короткий номер, на который отсылают платную SMS) в таблице обработанных платежей.
Сейчас мы принимаем платежи почти во всём мире. Каждую секунду пользователи пытаются что-то оплатить на сайте или в приложениях для всех популярных мобильных платформ. А если наложить это на карту, то получится картина «Вид на Землю из космоса ночью»:
У нас доступно около 50-ти способов оплаты, предоставляемых разными партнерами. Самые популярные ― это банковские карты, SMS & Direct billing и покупки в мобильных приложениях.
Среди них есть и экзотические, например, прямое списание со счета интернет-провайдера или оплата через городской телефон. А однажды нам поступил платеж через обычную почту!
Банковские платежи
Все платежные системы позволяют принимать платежи от своих пользователей. Такие прямые интеграции удобно делать, пока их не очень много и вы подключаете известные системы с отлаженными процессами. Но когда нужно выйти на локальные рынки, то начинают появляться проблемы. Поддерживать «зоопарк» разных API становится всё сложнее, отличаются требования регуляторов, популярная локальная платежная система может вообще отказаться работать с иностранными клиентами при низких оборотах, или подписание контракта и улаживание юридических проблем может затянуться на долгое время. Несмотря на такие сложности, локальные платежные системы могут вас приятно удивить своей конверсией. Например, Голландия, которую мы считали не очень перспективной, после подключения популярного в этой стране способа оплаты iDeal стала приносить на 30-40% больше денег.
Если есть спрос, будет и предложение. На рынке много компаний-агрегаторов, или, по-другому, платежных шлюзов (англ. payment gateway), целью которых является объединение всех популярных платежных систем, в том числе локальных, под единым API. Сделав одну такую интеграцию, мы получаем возможность принимать платежи через десятки платежных систем по всему миру. Можно даже не делать страницу оплаты на своем сайте, а воспользоваться уже готовой, предоставленной агрегатором, и подогнать под себя только дизайн. Особо продвинутые компании дают возможность загружать свои CSS- и JS-файлы, менять картинки, тексты переводов и даже зарегистрировать получившуюся страницу на вашем поддомене, например, payments.example.com. Это дает очень богатые возможности по «кастомизации», и у пользователя складывается ощущение, что он не покидает ваш сайт. У себя мы этой возможностью не пользуемся, так как одновременно работаем с несколькими агрегаторами, но для кого-то это может быть очень удобным решением.
Какой способ использовать ― прямую интеграцию или через агрегатора ― зависит в первую очередь от размера комиссии. Чем больше ваших клиентов пользуется платежной системой, тем выгоднее может оказаться сэкономить на комиссии и подключиться к ней напрямую. Второй важный фактор ― это качество API, удобство работы и стабильность. Здесь агрегаторы позволяют сгладить шероховатости, а иногда и предоставить более стабильный сервис, чем прямое подключение.
SMS-платежи
Особняком стоят платежи через SMS и прямые списания с баланса мобильного телефона. Они находятся под очень жестким контролем во многих странах, особенно в Европе. Локальные регуляторы или само государство могут предъявлять особые требования к тому, как должна выглядеть страница оплаты или каким должен быть текст отсылаемых SMS-сообщений. За изменениями подобных требований нужно следить и вовремя вносить изменения у себя на сайте. Так, например, в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне, а рядом с ним должна быть указана его стоимость.
Технические детали
Badoo работает на связке PHP + MySQL, поэтому для обработки платежей мы используем те же технологии. Код выполняется на отдельной группе серверов, выделенной из общего пула. Внутри мы ее разделили еще на несколько логических подгрупп: cерверы для обработки входящих запросов, серверы для фоновых операций и сбора статистики, серверы баз данных, серверы для обработки платежей по банковским картам. Последние выделены в отдельную группу, потому что они должны соответствовать стандарту безопасности PCI DSS, разработанному при участии Visa, MasterCard, American Express, JCB и Discover для организаций, работающих или хранящих данные держателей банковских карт.
Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного (на время его обслуживания, для запросов от системы мониторинга или сбора статистики).
После реализации API наступает этап тестирования. На Хабре уже были статьи о том, как выглядит наш процесс разработки и автоматизации. Но для биллинга есть некоторые особенности, связанные в основном с тем, что приходится тестировать не просто наш код, но и взаимодействие с агрегаторами. Очень удобно, если у них есть для этого тестовое окружение, которое полностью эмулирует реальный прием платежей. Если же его нет, мы делаем «заглушки», эмулирующие поведение агрегатора. Это упрощает нам ручное тестирование и позволяет писать автотесты, проверяющие весь процесс оплаты. Вот пример того, как выглядит одна из заглушек.
После тестового окружения нужно проверить, как всё будет работать в жизни, провести реальную оплату. Но для SMS-платежей часто приходится получать одобрение от регуляторов или операторов, а это может длиться несколько месяцев. Чтобы не выкладывать полуготовый код на продакшн-серверы, мы придумали такую вещь, как External Shot. Это наш обычный Shot, который представляет из себя директорию с веткой задачи и предназначен для ее тестирования на продакшн-серверах, но кроме локального домена он имеет дополнительный внешний адрес, по которому любой желающий может зайти и посмотреть сделанные изменения. Для безопасности такие «шоты» создаются не для каждой задачи, а только в тех случаях, когда действительно необходимо. Ссылки на них мы даем нашим партнерам, и они в любое время дня и ночи могут проверить сделанные изменения. Особенно это актуально для стран, расположенных в другом полушарии, с которым разница во времени может достигать 12 часов.
Поддержка и эксплуатация
После того как новая интеграция выкладывается на продакшн-серверы, наступает этап ее эксплуатации и поддержки. Техническая поддержка занимает примерно 60-70% нашего времени.
Сюда входит, во-первых, разбор жалоб от пользователей. Все простые ситуации решаются командой первой линии поддержки, она же переводит для нас жалобы с разных языков на английский. Поэтому к нам попадают только самые сложные случаи, действительно требующие внимания разработчиков.
Вторая составляющая технической поддержки ― это исправление ошибок или внесение изменений в существующие интеграции. Ошибки возникают по разным причинам. Например, из-за невнимательного чтения документации или пробелов в ней. Однажды вместо нее нам даже пришлось использовать логи чата с разработчиком агрегатора, потому что документация для их новой системы была еще не готова. Были случаи, когда агрегатор без уведомления менял протокол взаимодействия или его параметры. В другой раз банк-эквайер отключил наш шлюз, и пришлось в срочном порядке перенаправлять трафик в другое место. Как потом выяснилось, это был древний сервер из 80-х, который, по данным банка, вообще ничего не должен был обрабатывать. В общем, скучать не приходится, особенно если учитывать, что каждая минута простоя ― это недополученная прибыль.
Для решения подобных проблем мы пишем подробные логи работы приложения. Туда попадают не только ошибки, но и всё взаимодействие с системами агрегаторов или просто важные события, происходящие во время выполнения запросов. Каждый запрос имеет свой уникальный идентификатор, по которому можно найти все связанные с ним записи и восстановить ход его обработки. Это бывает особенно полезно, когда приходится разбираться с ошибками, с момента которых уже прошло несколько недель или месяцев.
Вот так организован биллинг в Badoo. Конечно, осталось еще много интересных тем, о которых мы планируем рассказать будущем, например мониторинг, сертификация PCI DSS и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.