код биллинга что это
Биллинг простыми словами
Биллинговая система. Что это?
Расчетные операции
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Информационное обслуживание
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Финансовое обслуживание
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
Это основные функции, которые должна уметь выполнять автоматизированная система расчетов.
Однако сейчас появляется все больше операторов связи, которые хотят обеспечить своим сотрудникам удобную работу с биллингом, взаимодействие разных отделов через единую систему, прозрачные расчеты с другими операторами связи, а своим абонентам не только качественную связь, но и дополнительные услуги, удобный личный кабинет, доступные варианты оплаты, индивидуальный подход и легкую коммуникацию с операторами.
Все эти требования, а также многие другие пожелания, легко обеспечиваются автоматизированной системой расчетов (АСР) Platex® — универсальной масштабируемой системой высшего функционального уровня. Она обеспечивает единое управление всеми бизнес-процессами между абонентами и операторами, независимо от типа услуг, технологии их предоставления, схемы тарификации, методов оплаты. Линейка продуктов, разработанная нашей компанией, дает возможность приобрести биллинговую систему и расширить ее функциональность, в случае необходимости, дополнительными модулями АСР Platex®. Кроме того, многофункциональная система комплексной автоматизации бизнес-процессов оператора связи, построенная на основе ядра программных продуктов линейки Platex®, позволит решить задачи, выходящие за рамки функциональности обычных биллинговых систем.
АСР Platex® совместима с продуктами компании «1С», интегрируется с различными платежными системами, соответствует всем требованиям государственных регулирующих органов, сертифицирована для применения в сетях электросвязи емкостью до 2,5 млн. абонентов.
Биллинг в большом проекте
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в 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 и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.
Чему я научился, разрабатывая биллинговую систему
Полгода назад я устроился в финтех-стартап, имеющий примерно 15 тысяч клиентов. Моя задача заключалась в развитии биллинговой инфраструктуры. Когда я пришёл в компанию, меня немного беспокоила узость задач моей новой должности и нового отдела. Я думал: ну какая глубина может быть в биллинге? Разве у нас не закончатся задачи спустя 3-4 месяца? Клиент регистрируется, ежемесячно оплачивает подписку, вот и всё, правда ведь?
Вообще да, но на самом деле нет. Это только самый простой сценарий, а кроме него существует множество пограничных случаев и тонкостей.
Поиск всех этих пограничных случаев один за другим был не самым приятным процессом. Было бы здорово, если бы кто-то составил краткое руководство о том, что мне нужно знать. Поэтому вот и оно, моё руководство! Если вы размышляете о создании (или даже об использовании) системы биллинга, то читайте внимательно.
Деньги не всегда десятичны
И те, и другие иногда ошибаются. Да, конечно, в США и большей части Европы деньги десятичны.
Но с Японией другая ситуация — вы не можете взять оплату в 2500,50 японских йен. Впрочем, можно и не трогать Японию — в Исландии тоже нет дробных значений валюты. И наоборот — иракский динар имеет в дроби три десятичных знака.
Строго говоря, можно возразить, что целые числа тоже являются десятичными, но они могут разрушить вашу систему неожиданным образом. Поэтому при создании биллинговой системы нужно сделать её достаточно гибкой, чтобы она могла обрабатывать события в этих странах, даже если пока они не входят в сферу ваших интересов.
Храните деньги с записью наименьшего возможного деления.
Например, в большинстве ситуаций:
| Код | Номер | Д | Валюта | Регионы, в которых используется эта валюта |
|---|---|---|---|---|
| BIF | 108 | 0 | Бурундийский франк | Бурунди |
| CLP | 152 | 0 | Чилийский песо | Чили |
| DJF | 262 | 0 | Франк Джибути | Джибути |
| GNF | 324 | 0 | Гвинейский франк | Гвинея |
| ISK | 352 | 0 | Исландская крона | Исландия |
| JPY | 392 | 0 | Японская йена | Япония |
| KMF | 174 | 0 | Франк Комор | Коморы |
| KRW | 410 | 0 | Южнокорейская вона | Южная Корея |
| PYG | 600 | 0 | Парагвайский гуарани | Парагвай |
| RWF | 646 | 0 | Руандийский франк | Руанда |
| UGX | 800 | 0 | Угандийский шиллинг | Уганда |
| VND | 704 | 0 | Вьетнамский донг | Вьетнам |
Полный список валют с их делением можно найти в стандарте ISO 4217, часть которого есть в Википедии.
Нельзя отменять или аннулировать уже созданные счета
По крайней мере, в большей части Европы. В США аннулирование неоплаченных счетов является распространнёной практикой. Однако это незаконно в большинстве стран ЕС. Если вы сделаете ошибку, это создаст большую головную боль!
Это «стандартная бухгалтерская практика», однако иногда больно узнавать о ней, потому что ошибки случаются. После создания счёта для его отмены можно сделать только одно: создать возвратную накладную на полную сумму.
Что такое «возвратная накладная»? Можно рассматривать её как счёт в обратную сторону. Возвратные накладные — это отдельный уникальный тип коммерческого документа. Как и счета, они имеют собственный номер.
То есть возвратная накладная — это документ, позволяющий отметить исходный счёт как «оплаченный», даже несмотря на то, что деньги не передавались между сторонами.
Возвратные накладные также полезны для взимания общей суммы, которую должен заплатить клиент. Допустим, вы составили счёт клиенту за 20 пользователей по 10 фунтов, но пять из этих пользователей были неактивны и должны быть отменены. На исходный счёт в 200 фунтов можно оформить возврат на 50 фунтов (5 × 10), то есть клиенту нужно будет заплатить 150 фунтов.
Не все биллинговые системы соответствуют законодательству
При расширении на новый регион недостаточно просто составить прейскурант на продукты и услуги. Вам нужно убедиться, что ваша система отвечает требованиям различных правил и норм, которые могут обладать довольно неочевидными тонкостями.
Многие компании покупают услуги сторонних продуктов SaaS, и мы часто предполагаем, что они соответствуют всем необходимым нормам.
Я обнаружил, что это не всегда так (разумеется, обязанность проверки лежит на вас).
Например, Stripe выполняет проверку VAT только один раз, при настройке VAT. Он не проводит никаких последующих проверок и не сопоставляет информацию о клиенте.
Некоторые другие сервисы вообще этого не делают, поэтому убедитесь, что ваша система отвечает требованиям!
Возможно, у вас получится хитростью ввести налоговую информацию, например, в поле для адреса. Как бы то ни было, проверяйте биллинговую систему на соответствие требованиям!
Что происходит, когда пользователь меняет тарифный план?
Я думал, что регистрация в системе компании — это просто. Клиент регистрируется и после кратковременного пробного периода использует продукт как платный бессрочный (evergreen) пользователь, и всё замечательно!
Идеальная компания начинает пользоваться продуктом и не меняет ничего на протяжении всего своего жизненного цикла
Как и многие другие компании, мы предлагаем различные уровни сервиса. Однако мы взымаем оплату за месяц заранее. Поэтому если повышает или понижает уровень сервиса, нам нужно изменить его тарифный план в какой-то момент в будущем.
Смена тарифного плана может быть запланирована на будущую дату, однако клиент может захотеть немедленно начать использовать новый уровень сервиса.
Кажется, что это вполне нормально, но тут стоит рассмотреть различные ситуации.
Вы можете также мгновенно заранее запросить оплату, но что насчёт пропорционального распределения?
Довольно тривиальный пример. Иногда в счетах бывают десятки строк. Проблема!
Существует ещё, наверно, с десяток других вариаций жизненных циклов компаний. Хотя такие ситуации возникают не всегда, они обязательно возникнут, когда у вас появится хотя бы пара сотен клиентов. Думайте заранее, как будете обрабатывать все эти случаи!
А если принудительно отказаться от пограничных случаев?
Клиенты — это не компании. Они люди. А у разных людей есть разные потребности.
Если вы работаете в среде не с чрезмерно строгими правилами, то вам придётся выбирать, насколько серьёзно вы будете заставлять следовать этим правилам.
Вот некоторые мелкие примеры, с которыми мы сталкивались:
На мой взгляд, лучше поддерживать бизнес и завоёвывать благосклонность клиентов, чем быть непреклонным.
Ничто не бывает простым
Какой бы простой ни казалась поначалу сфера задач, в ней всегда присутствует глубина и есть множество вопросов, требующих ответа.
Я осознал, насколько сложно проектировать, разрабатывать и эксплуатировать биллинговые системы, если вы хотя бы ненамного отклоняетесь от «стандартного» поведения. Однако вкладываясь в их правильную реализацию, вы идёте навстречу потребностям клиентов, отделов продаж, техподдержки и финансовых отделов!
Хоть это и самые важные пять пунктов, которые бы я хотел знать перед началом работы с биллинговыми системами, данный список далеко не полон.
На правах рекламы
Серверы для бизнеса и любых крупных проектов — это про наши эпичные серверы. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe, надёжный дата-центр в Москве, защита от DDoS-атак «из коробки», активация сервера в течение минуты!