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