Биллинговые системы что это
Что такое биллинг?
Работа телекоммуникационных операторов невозможна без особой бухгалтерской системы, позволяющей быстро, корректно и в автоматическом режиме пересчитывать и обновлять информацию о состоянии абонентских счетов.
Биллинговая система (БС) – это специальное программное и аппаратное обеспечение, хранящее информацию о каждом клиенте и тарифах, рассчитывающее стоимость услуг для абонентов и производящее операции по взаиморасчетам с агентами, предоставляющими услуги самому оператору.
Совокупность всех цикличных операций, продуцируемых программой, называется биллингом. Подобный «софт» используется не только операторами сотовой связи. С его помощью интернет-провайдеры выставляют счета и ведут учет объемов трафика. Благодаря биллинговой системе можно провести анализ показателей в стационарной телефонии, например, направление и продолжительность звонков. Представители операторов IP-телефонии также являются пользователями биллингового ПО.
Биллинговые системы создаются на основе многофункциональных систем управления базами данных. Наиболее часто используемыми СУБД являются Oracle, Informix и Sybase. Последние две рассчитаны на работу с большими объемами информации и могут быть взяты за основу для БС для транснациональных операторов мобильной связи. Среди телекоммуникационных операторов наиболее популярны БС CBOSS, BIS, Bill-2000-prepaid, Flagship и Arbor.
Сущность и качества БС, востребованных среди операторов сотовой связи
Биллинговые системы часто носят другие названия, полностью отражающие их суть:
Независимо от используемой аббревиатуры БС должна обладать рядом ключевых качеств, обеспечивающих слаженную бесперебойную работу оператора связи и взаимодействие со всеми абонентами в режиме реального времени.
Настраиваемость
Возможность внедрения дополнительных настроек дает возможность расширить возможности системы и обеспечить решение большего количества задач.
Гибкость
Пластичность и гибкость используемой биллинговой системы позволяет ей быстро подстраиваться под потребности оператора в конкретный период времени, обеспечивая осуществление сиюминутных запросов телекоммуникационного поставщика услуг.
Открытость
Исходный код программного продукта должен быть доступен оператору. Подобная открытость дает возможность пользователю самостоятельно обслуживать систему, модернизировать ее, подстраивая под свои нужды, и не зависеть от разработчика.
Модульность построения системы
Использование модулей, специализированных независимых друг от друга подсистем, позволяет упростить тестирование программы и строго разделить задачи, решением которых будет заниматься БС. Функционирование каждого блока программы будет максимально автономным. Так, например, частью биллинговой системы могут быть подсистема оповещения абонентов или предварительной обработки данных, модуль оперативного управления биллингом.
Масштабируемость
Рост абонентской базы, увеличение спектра предоставляемых услуг не должны повлечь за собой потребность в доработке программной части биллинговой системы. Расширение ее возможностей должно осуществляться за счет модернизации аппаратной части БС. При этом сама СУБД должна интегрироваться с различными платформами для многопроцессорного и бесперебойного режима работы.
Надежность
Одно из ведущих качеств БС, как и любых других «софт»-продуктов. Его уровень определяется надежностью технологий и СУБД, а также соблюдением стандартов, которые использовались при разработке системы.
Мультиязычность и мультивалютность
Возможность устанавливать различные языки и работать с несколькими валютами дает возможность взаимодействовать с операторами других стран, работая на мультинациональном уровне.
Оптимизация биллинга
Самостоятельное улучшение БС оператором – важное качество, позволяющее расширить потенциал системы и увеличить число решаемых задач. Оптимизация неотрывно связана с открытостью и невозможна без прозрачности действий разработчика. К дополнительным полезным качествам биллинговой системы относятся отложенный и горячий биллинг. В первом случае расчеты производятся после завершения состоявшихся звонков, во втором – непосредственно в процессе разговора, а новый соответствующий реальной действительности баланс счета становится доступным сразу после окончания звонка. Постинг биллинга как дополнительная особенность бухгалтерской системы для оператора сотовой связи позволяет фиксировать результаты расчета и делать их доступными для абонентов, например, благодаря рассылке.
Возможности современных БС для операторов связи
Одной из ведущих задач биллинговой системы является автоматизация корректных расчетов с клиентами от момента заключения договора до выписки со счетов. Но на этом функционал АСР не завершает свое многообразие. Современные БС не ограничивают абонентов в самообслуживании благодаря подсистемам автоматического сбора данных и автоматизации услуг. Благодаря им может быть произведено подключение или оплата услуги через Интернет.
Отображение обновленного баланса после совершения звонка, использование кредитной системы или предоставление услуг по предоплате, постоянный подсчет остатка на счету абонента и уведомление пользователя о необходимости внести средства являются ведущими возможностями БС. Однако случаются и технические неполадки внутри БС. Чаще всего они отображаются в несправедливом списании незначительных сумм денежных средств со счета абонента либо в предоставлении устаревшей информации по балансу клиента.
Биллинговые системы: функции и структура АСР
Организация биллинговых процессов достаточно проста, если не учитывать поддержку некоторых сложных операций, например, роуминга. Коммутатор записывает и обрабатывает данные о соединениях абонента, передавая их в расчетную систему, которая оперирует тарифами и нормативами. Расчетная система формирует абонентский счет, опираясь и на дополнительную информацию:
Обеспечение контроля и автоматизации оплаты гарантирует и база данных с историей платежей клиента. Благодаря сведениям из этого самостоятельного модуля осуществляется активация и деактивация абонентов. Функции служат своеобразной защитой, ведь услугами могут пользоваться лишь те клиенты, которые за них платят.
Спектр функциональных возможностей БС позволяет разделить их на три категории:
Разработчики БС ориентируются на потребности определенного оператора, при ее создании учитывается бизнес-процесс конкретного предприятия с его оборудованием, технологическим циклом предоставления услуг связи. При этом любая биллинговая система сохраняет и унифицированный функционал, присущий любой АСР для телекоммуникационных операторов всех категорий.
Предварительный анализ и обработка базовой информации
К подобным операциям можно отнести любые запросы к коммутатору: получение данных о соединениях и предоставленных услугах.
Управление сетевым оборудованием
Указанные операции включают активацию или блокировку абонентов, изменение условий тарификации и подписки пользователей, находящихся в СУБД оператора.
Базовые функции СУБД:
Гибкость и модульность системы телекоммуникационного оператора обеспечивают бесперебойную работу каждого конкретного звена в технологической цепи обслуживания абонентов. Биллинг включает в себя три ключевые подсистемы.
Модуль предварительной обработки данных
В этом приложении происходит сбор и анализ информации о соединениях абонента, определяется тип услуги и параметры используемого трафика: источник и направление звонков, условия роуминга, взаиморасчеты с дилерами услуг связи. Ключом модуля является декодер исходной информации о соединениях. Наиболее сложной среди всех выполняемых операций в этом модуле является роуминг. Это связано с необходимостью конвертации записей всех форматов от разных коммутаторов из БС в формат, используемый в конкретной биллинговой системе. При этом должны быть учтены все стандарты передачи данных.
Для этого создаются служебные таблицы, материалом для которых служат тарифицированные записи о соединениях между задействованными операторами. После остальные модули используют собранную и систематизированную в таблицах информацию для произведения расчетов с абонентами, формирования отчетов и проведения взаиморасчетов с другими телекоммуникационными операторами. Применение своеобразных «интеллектуальных систем» внутри БС дает возможность обрабатывать разные виды услуг, выставляя счет в удобном и для абонента, и для оператора формате.
Модуль оперативного управления биллингом
Подключение или блокировка конкретной услуги в автоматическом режиме или при помощи обращения к оператору происходят именно благодаря этой подсистеме. Коммутатор изменяет подписку абонента по запросу клиента или при необходимости оператора. Так, например, осуществляется активация дополнительных услуг голосовой почты после заявки клиента.
Модуль оповещения абонентов
Голосовые, текстовые и другие сообщения от оператора его абонентам – важная составляющая биллинга. Основой для формирования оповещения также является информация из СУБД. Подобное деление БС на функциональные модули является классическим примером АСР, но не считается единственным возможным для всех биллинговых систем.
Биллинг и история формирования его мировых стандартов
Необходимость осуществления взаимодействия между разными операторами мобильной связи послужила началом для выработки определенных стандартов биллинга. Формирование общих норм нужно, например, при поддержке роуминга.
Стандарты биллинга делятся на три международные группы. Так, в 1998 году американским институтом стандартов ANSI был разработан и утвержден стандарт ANSI 124. Его дальнейшее развитие и усовершенствование для новых потребностей операторов и их абонентов полностью зависит от ассоциации TIA. Компания CIBERNET также занялась уточнением и делением бизнес-процессов, происходящих при передаче сообщений внутри этого стандарта. Рабочей группой компании была сформулирована новая категория стандартов NSDP-B&S. Спецификации этого класса подразумевают полное соответствие всех процессов, осуществляемых операторами, и информации, которая передается во время операций по обмену данными между коммутаторами по стандарту ANSI 124.
С 1998 года и по настоящее время CIBERNET совместно со своим комитетом CAC-IS поддерживает биллинговый стандарт CIBER, который является первым североамериканским стандартом биллинга. Под эгидой CAC-IS объединены разработчики БС и телекоммуникационные операторы, благодаря чему обеспечено продуктивное взаимодействие создателей и непосредственных пользователей биллинговых систем. CIBER применяется в сотовых сетях стандарта AMPS. В Европе же был сформирован стандарт ТАР, который используется с 1992 года. Курирование норматива осуществляется рабочей группой TADIG. Действующие телекоммуникационные европейские операторы используют вторую спецификацию стандарта ТАР2, хотя уже сформулирована и утверждена и третья версия. Спецификация TD.27, известная и как NAGTAP2, является модификацией ТАР2 и применяется на территории США с 1995 года.
Биллинг в большом проекте
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в 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 и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.
Биллинг простыми словами
Биллинговая система. Что это?
Расчетные операции
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Информационное обслуживание
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Финансовое обслуживание
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
Это основные функции, которые должна уметь выполнять автоматизированная система расчетов.
Однако сейчас появляется все больше операторов связи, которые хотят обеспечить своим сотрудникам удобную работу с биллингом, взаимодействие разных отделов через единую систему, прозрачные расчеты с другими операторами связи, а своим абонентам не только качественную связь, но и дополнительные услуги, удобный личный кабинет, доступные варианты оплаты, индивидуальный подход и легкую коммуникацию с операторами.
Все эти требования, а также многие другие пожелания, легко обеспечиваются автоматизированной системой расчетов (АСР) Platex® — универсальной масштабируемой системой высшего функционального уровня. Она обеспечивает единое управление всеми бизнес-процессами между абонентами и операторами, независимо от типа услуг, технологии их предоставления, схемы тарификации, методов оплаты. Линейка продуктов, разработанная нашей компанией, дает возможность приобрести биллинговую систему и расширить ее функциональность, в случае необходимости, дополнительными модулями АСР Platex®. Кроме того, многофункциональная система комплексной автоматизации бизнес-процессов оператора связи, построенная на основе ядра программных продуктов линейки Platex®, позволит решить задачи, выходящие за рамки функциональности обычных биллинговых систем.
АСР Platex® совместима с продуктами компании «1С», интегрируется с различными платежными системами, соответствует всем требованиям государственных регулирующих органов, сертифицирована для применения в сетях электросвязи емкостью до 2,5 млн. абонентов.