Английское слово «биллинг» — означает выставление счета за оказанные услуги. В наши дни оно имеет несколько понятий.
Термин применяется в различных отраслях народного хозяйства: медицине, торговле, ЖКХ и т. д. Большое количество людей сегодня сталкивается с данным понятием, как с определением, касающимся оплаты оказанных работ. Определение широко используется в сотовой связи или при обеспечении доступа к интернету.
Основной функцией биллинга является перевод денег потребителя на лицевой счет компании за оказанные услуги. Биллинговая система справляется с задачей и защищает пользователя от мошенников.
Биллинг в этом смысле представляет собой ряд последовательных операций, которые требуют программного и аппаратного обслуживания с юридическим и банковским обеспечением всех этапов зачисления платежа.
Биллинговые системы
Только крупные предприятия могут позволить себе организацию собственной биллинговой системы. А более мелкие фирмы и частные лица используют поддержку специализированных биллинговых компаний. Основной процесс выставления счетов заключается в определении количества предоставленных услуг.
Если это доступ к интернету или телефонная связь, программное сопровождение фиксирует время звонка или часы, проведенные пользователем в глобальных сетях. Далее, программа производит расчет в соответствии с тарифами, указанными в программном обеспечении компании.
Затем в автоматическом режиме, по заранее заданному графику приложение направляет информацию пользователю о стоимостях полученных услуг, а поставщику информацию о поступлении оплаты и возможности вывода денежных средств с вычетом согласованного платежа за эксплуатацию этой системы. Многие виды бизнеса используют циклический биллинг.
Циклический биллинг
Циклический биллинг — это стратегия выставления счетов, которая включает ежедневное создание и обновление непогашенных остатков на счетах клиентов. Это позволяет подготовить единый счет-фактуру, охватывающий весь период, а не выставлять счета покупателям в каждом отдельном случае.
Существуют преимущества, связанные с моделью выставления счетов за циклы, которые применяются как к поставщику, так и к заказчику. Коммунальные предприятия регулярно обновляют учетные записи в зависимости от объема использования за определенный период.
Как правило, расчетный период составляет тридцать дней или один календарный месяц.
В течение этого времени учетная запись абонента время от времени обновляется, отражая использование предоставленного обслуживания. В конце текущего цикла счет за все тридцать дней завершается и направляется пользователю для оплаты.
Сферы использования циклического биллинга
Различные телекоммуникационные услуги также используют циклический биллинг. Например, бюро телеконференций часто рассчитывает стоимость каждого звонка, проводимого данным абонентом, и добавляет расходы и подробности к счету, подготовленному специально для этого периода.
Предполагая, что потребитель проводит еженедельную телефонную конференцию, расчет за цикл будет содержать информацию, связанную с каждым из этих вызовов, которые обычно располагаются в хронологическом порядке. Использование цикличности выставления счетов имеет ряд преимуществ для всех участников.
Для поставщика использование этой модели вместо выдачи отдельных счетов-фактур по каждому заказу или событию означает, что на подготовку, проверку, печать и отправку счета расходуется меньше времени. Поскольку все операции для одного периода отображаются в одном счете, поставщик также экономит время и ресурсы, когда платежи получены, и их необходимо разместить в бухгалтерских записях.
Для клиентов периодичность выставления счетов позволяет управлять только одним счетом в течение месяца. Не затрачивая времени на поток отдельных счетов, которые должны быть оплачены индивидуально. Пользователь также экономит время и, возможно, деньги, если оплата каждого счета сопряжена с какими-либо расходами. Такими, как почтовые расходы или плата за прием онлайн-платежей.
Циклический биллинг обычно используется, когда отношения регулируются договором или носят регулярный характер. Для клиента не является чем-то необычным пройти проверку кредитоспособности до того, как поставщик заключит этот тип соглашения с потенциальным потребителем. Модель хорошо работает для счетов кредитных карт, коммунальных услуг и даже для вкладок в местных клубах или магазинах.
В современном компьютеризированном обществе растет число предпринимателей, оценивших удобство применения электронных платежных систем при получении оплаты за предоставленные услуги. Этим объясняется растущий интерес к биллинговым компаниям, осуществляющим вышеописанные технические мероприятия этого процесса.
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Информационное обслуживание
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Финансовое обслуживание
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
В биллинговую систему заводится информация, на основании которой за определенный период обслуживания (как правило, расчетный период составляет один календарный месяц) оператор связи выставляет счет абоненту за потребление услуг связи. Что это за информация? Тарифы, стоимость минуты звонка в зависимости от направления (междугородняя и международная связь), стоимость интернет-трафика, стоимость подключенных ТВ-каналов и так далее. Кроме того, биллинг должен учитывать индивидуальные и общие скидки, акции, временное приостановление услуг по желанию абонента, налоговые начисления, дополнительные начисления и многое другое, что определяет для своего бизнеса оператор связи. Помимо этой информации, в биллинг поступают первичные тарификационные данные – информация обо всех звонках, совершаемых абонентами этого оператора связи и об объеме интернет-трафика. На основании всех этих данных биллинговая система рассчитывает стоимость своих услуг за расчетный период для каждого клиента и выставляет платежные документы.
Биллинговая система должна иметь удобный интерфейс для заведения и мониторинга всей необходимой информации: тарифы и тарифные планы, пакеты, опции, скидки, стоимость звонков в зависимости от направления и т.д.; уметь составлять отчеты; иметь возможность взаимодействовать с абонентами – рассылать документы, управлять событиями уведомления абонентами и многое другое.
Автоматизированная система расчетов должна не только уметь корректно выставлять счета абонентам, но и обрабатывать поступившие платежи, разносить их по выставленным счетам, управлять дебиторской задолженностью абонентов, при необходимости взаимодействовать с бухгалтерскими программами.
Это основные функции, которые должна уметь выполнять автоматизированная система расчетов. Однако сейчас появляется все больше операторов связи, которые хотят обеспечить своим сотрудникам удобную работу с биллингом, взаимодействие разных отделов через единую систему, прозрачные расчеты с другими операторами связи, а своим абонентам не только качественную связь, но и дополнительные услуги, удобный личный кабинет, доступные варианты оплаты, индивидуальный подход и легкую коммуникацию с операторами.
Все эти требования, а также многие другие пожелания, легко обеспечиваются автоматизированной системой расчетов (АСР) Platex® — универсальной масштабируемой системой высшего функционального уровня. Она обеспечивает единое управление всеми бизнес-процессами между абонентами и операторами, независимо от типа услуг, технологии их предоставления, схемы тарификации, методов оплаты. Линейка продуктов, разработанная нашей компанией, дает возможность приобрести биллинговую систему и расширить ее функциональность, в случае необходимости, дополнительными модулями АСР Platex®. Кроме того, многофункциональная система комплексной автоматизации бизнес-процессов оператора связи, построенная на основе ядра программных продуктов линейки Platex®, позволит решить задачи, выходящие за рамки функциональности обычных биллинговых систем.
АСР Platex® совместима с продуктами компании «1С», интегрируется с различными платежными системами, соответствует всем требованиям государственных регулирующих органов, сертифицирована для применения в сетях электросвязи емкостью до 2,5 млн. абонентов.
Биллинговый период определяет на сколько времени вперед могут быть внесены абонплаты за ресурсы этого периода.
В дополнение к 1 месяцу биллингового периода, начинающемуся с каждым новым хостинг-планом, вы можете создать для своих клиентов/реселлеров множество биллинговых периодов различной продолжительностью, чтобы они могли выбрать подходящий им вариант во время регистрации или сменить период позже. Это дает возможность вам конфигурировать ценообразование отдельно для каждого биллингового периода.
Действительные и установленные по умолчанию биллинговые периоды. Базовые цены
При создании нового хостинг-плана вы можете устанавливать цены и бесплатные единицы на один месяц биллингового периода по умолчанию. Это базовые цены и бесплатные единицы, используемые при расчете действующих цен и бесплатных единиц. После создания плана, вы можете продолжить и создать для него действующие биллинговые периоды. В отличие от биллинговых периодов по умолчанию, действующие биллинговые периоды пользователи могут выбирать самостоятельно. Если вы не установили цену или бесплатные единицы для действующего биллингового периода, расчет будет проводиться исходя из соответствующих базовых платных/бесплатных единиц и скидок.
Ежемесячные ресурсы и ресурсы биллингового периода
Расчет таких ресурсов как трафик, использование дискового пространства, квоты MySQL и PGSQL проводится не биллинговыми периодами, как для остальных ресурсов, а биллинговыми месяцами (ежемесячно). Биллинговый месяц равен количеству дней биллингового периода, делимых на продолжительность биллнгового периода в месяцах. Вот почему эти ресурсы относятся к ежемесячным ресурсам в отличие от ресурсов биллингового периода.
Открытие нового биллингового периода/месяца
Новый биллинговый период/месяц открывается:
— когда активизируется новый аккаунт после регистрации или модерации, которые определяют время открытия каждого отдельного аккаунта — когда биллинговый период закрывается — после разблокирования заблокированного аккаунта после окончания биллингового периода — после изменения биллингового периода аккаунта — после изменения даты открытия биллинга
В остальных случаях биллинговый период не закрывается.
Создание и настройка действующих биллинговых периодов
Каждый новый хостинг-план предоставляется с 1 месяцем биллингового периода, но вы можете создать несколько действующих биллинговых периодов.
Чтобы создать или отредактировать биллинговый период:
В H-Sphere биллинговые периоды не могут быть удалены, зато можно менять их продолжительность. Например, если вы решите, что не нуждаетесь более в ежегодном биллинговом периоде, вы можете изменить его продолжительность до двух месяцев. Внимание: не меняйте продолжительность биллингового периода, если на нем есть действительные аккаунты, так как это приведет к сбою в их биллинге. Вместо этого можно создать идентичный план с таким же набором ресурсов, но с различными биллинговыми периодами и переместить аккаунты под этот план. Как только вы узнаете, что у вас нет аккаунтов в этом биллинговом периоде, вы можете спокойно менять его продолжительность.
Изменение биллингового периода аккаунта
Если есть более одного действующих биллинговых периодов, пользователи могут переходить с одного на другой:
При переходе на биллинговый период
более длинный
более короткий
чем время, прошедшее от начала текущего биллингового периода, пользователь переходит на новый биллинговый период с датой открытия:
аналогичной той, с которой он совершает переход.
Важно: дата начала нового биллингового периода устанавливается по текущей дате при любом изменении для аккаунтов, в которых дата начала биллингового преиода была смещена назад и открытый биллинговый период закрылся ранее данной даты. Для таких случаев не предвидится никаких возмещений для прерванного биллингового периода.
Изменение даты начала биллингового периода
Если вы установите одинаковую биллинговую дату для многих клиентов, система может быть перезагружена в этот биллинговый день.
Изменение даты начала биллингового периода не меняет его продолжительность. Чтобы изменить продолжительность биллингового периода, обращайтесь к разделу Создание и редактирование биллинговых периодов.
Чтобы изменить дату начала биллингового периода:
Когда вы смещаете дату начала биллингового периода назад:
Достижение отрицательного баланса на момент открытия нового биллингового периода может привести к блокировке или даже к удалению аккаунта, потому что до этой даты на аккаунте, скорее всего уже была задолженность более допустимых в разделе управление должниками дней. Если вы не хотите, чтобы аккаунт был автоматически заблокирован, выполните одно из двух: (a) перед тем, как смещать дату начала биллинга, внесите на баланс сумму, которая не приведет к отрицательному балансу. (b) установите дату возникновения долга на балансе, биллинговые данные пользователя (доступно после нажатия на имени пользователя на странице результата поиска) по отношению к текущей дате.
Когда вы смещаете дату начала биллингового периода вперед:
Смещая дату начала биллинга вперед, вы создаете интервал между биллинговыми периодами. Система не взимает с клиента абонплату за этот интервал. Трафик и дисковое пространство, использованные за этот интервал, отслеживаются и учитываются в конце биллингового периода при подсчете использованных ресурсов. Если пользователь совершает заказ во время интервала, система взимает с него абонплату за заказанные ресурсы. Тем не менее, цена будет рассчитываться с момента покупки до конца нового биллингового периода. Предположим, ваш текущий биллинговый период закрывается 11 ноября, установите новую дату начала биллинга 1 декабря (с месячным биллинговым периодом). Таким образом, пользователь не оплачивает за оставшиеся дни ноября. Кроме того, если пользователь покупает ресурс 20 ноября, с него взимается плата за 40-дневной интервал (с 20 ноября по 1 января).
Биллинговый период определяет на сколько времени вперед могут быть внесены абонплаты за ресурсы этого периода.
В дополнение к 1 месяцу биллингового периода, начинающемуся с каждым новым хостинг-планом, вы можете создать для своих клиентов/реселлеров множество биллинговых периодов различной продолжительностью, чтобы они могли выбрать подходящий им вариант во время регистрации или сменить период позже. Это дает возможность вам конфигурировать ценообразование отдельно для каждого биллингового периода.
Действительные и установленные по умолчанию биллинговые периоды. Базовые цены
При создании нового хостинг-плана вы можете устанавливать цены и бесплатные единицы на один месяц биллингового периода по умолчанию. Это базовые цены и бесплатные единицы, используемые при расчете действующих цен и бесплатных единиц. После создания плана, вы можете продолжить и создать для него действующие биллинговые периоды. В отличие от биллинговых периодов по умолчанию, действующие биллинговые периоды пользователи могут выбирать самостоятельно. Если вы не установили цену или бесплатные единицы для действующего биллингового периода, расчет будет проводиться исходя из соответствующих базовых платных/бесплатных единиц и скидок.
Ежемесячные ресурсы и ресурсы биллингового периода
Расчет таких ресурсов как трафик, использование дискового пространства, квоты MySQL и PGSQL проводится не биллинговыми периодами, как для остальных ресурсов, а биллинговыми месяцами (ежемесячно). Биллинговый месяц равен количеству дней биллингового периода, делимых на продолжительность биллнгового периода в месяцах. Вот почему эти ресурсы относятся к ежемесячным ресурсам в отличие от ресурсов биллингового периода.
Открытие нового биллингового периода/месяца
Новый биллинговый период/месяц открывается:
— когда активизируется новый аккаунт после регистрации или модерации, которые определяют время открытия каждого отдельного аккаунта — когда биллинговый период закрывается — после разблокирования заблокированного аккаунта после окончания биллингового периода — после изменения биллингового периода аккаунта — после изменения даты открытия биллинга
В остальных случаях биллинговый период не закрывается.
Создание и настройка действующих биллинговых периодов
Каждый новый хостинг-план предоставляется с 1 месяцем биллингового периода, но вы можете создать несколько действующих биллинговых периодов.
Чтобы создать или отредактировать биллинговый период:
В H-Sphere биллинговые периоды не могут быть удалены, зато можно менять их продолжительность. Например, если вы решите, что не нуждаетесь более в ежегодном биллинговом периоде, вы можете изменить его продолжительность до двух месяцев. Внимание: не меняйте продолжительность биллингового периода, если на нем есть действительные аккаунты, так как это приведет к сбою в их биллинге. Вместо этого можно создать идентичный план с таким же набором ресурсов, но с различными биллинговыми периодами и переместить аккаунты под этот план. Как только вы узнаете, что у вас нет аккаунтов в этом биллинговом периоде, вы можете спокойно менять его продолжительность.
Изменение биллингового периода аккаунта
Если есть более одного действующих биллинговых периодов, пользователи могут переходить с одного на другой:
При переходе на биллинговый период
более длинный
более короткий
чем время, прошедшее от начала текущего биллингового периода, пользователь переходит на новый биллинговый период с датой открытия:
аналогичной той, с которой он совершает переход.
Важно: дата начала нового биллингового периода устанавливается по текущей дате при любом изменении для аккаунтов, в которых дата начала биллингового преиода была смещена назад и открытый биллинговый период закрылся ранее данной даты. Для таких случаев не предвидится никаких возмещений для прерванного биллингового периода.
Изменение даты начала биллингового периода
Если вы установите одинаковую биллинговую дату для многих клиентов, система может быть перезагружена в этот биллинговый день.
Изменение даты начала биллингового периода не меняет его продолжительность. Чтобы изменить продолжительность биллингового периода, обращайтесь к разделу Создание и редактирование биллинговых периодов.
Чтобы изменить дату начала биллингового периода:
Когда вы смещаете дату начала биллингового периода назад:
Достижение отрицательного баланса на момент открытия нового биллингового периода может привести к блокировке или даже к удалению аккаунта, потому что до этой даты на аккаунте, скорее всего уже была задолженность более допустимых в разделе управление должниками дней. Если вы не хотите, чтобы аккаунт был автоматически заблокирован, выполните одно из двух: (a) перед тем, как смещать дату начала биллинга, внесите на баланс сумму, которая не приведет к отрицательному балансу. (b) установите дату возникновения долга на балансе, биллинговые данные пользователя (доступно после нажатия на имени пользователя на странице результата поиска) по отношению к текущей дате.
Когда вы смещаете дату начала биллингового периода вперед:
Смещая дату начала биллинга вперед, вы создаете интервал между биллинговыми периодами. Система не взимает с клиента абонплату за этот интервал. Трафик и дисковое пространство, использованные за этот интервал, отслеживаются и учитываются в конце биллингового периода при подсчете использованных ресурсов. Если пользователь совершает заказ во время интервала, система взимает с него абонплату за заказанные ресурсы. Тем не менее, цена будет рассчитываться с момента покупки до конца нового биллингового периода. Предположим, ваш текущий биллинговый период закрывается 11 ноября, установите новую дату начала биллинга 1 декабря (с месячным биллинговым периодом). Таким образом, пользователь не оплачивает за оставшиеся дни ноября. Кроме того, если пользователь покупает ресурс 20 ноября, с него взимается плата за 40-дневной интервал (с 20 ноября по 1 января).
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в 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 и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.
Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в Badoo и что можно встретить на рынке платежных шлюзов. Сразу предупреждаем, что в статье вы не найдете конкретных цифр по обороту средств компании, но все остальное будет не менее интересно.