company_banner

Биллинг в большом проекте

    Существуют разные способы «монетизировать» проект. Но у них есть одна общая составляющая ― то, как деньги переходят из кошелька пользователя на счет организации. Сегодня мы расскажем о том, как организован прием платежей в Badoo и что можно встретить на рынке платежных шлюзов. Сразу предупреждаем, что в статье вы не найдете конкретных цифр по обороту средств компании, но все остальное будет не менее интересно.

    Что такое «биллинг»


    Для нас биллинг ― это всё, что связано с получением денег от пользователей: конфигурация цен, страница приема платежей, непосредственно прием и обработка платежей, оказание оплаченных услуг, различные промоакции и, конечно же, мониторинг всего вышеописанного.

    Изначально, как и во всех стартапах, у нас не было платных услуг. Первые серьезные шаги в сторону монетизации начались в далеком 2008 году, при том что официально сайт был запущен в 2006-м. Для экспериментов была выбрана Франция, а оплата принималась только через SMS. Сам прием платежей был организован на файлах. Каждый запрос записывался в отдельный файл, который затем перекладывался bash-скриптами из одной папки в другую, что означало смену статусов обработки. База данных использовалась только для учета успешно обработанных транзакций. Такая схема успешно проработала чуть больше года, после чего ее стало сложно поддерживать, и мы решили отказаться от файлов и переписать всё с использованием БД.

    Разработка новой версии прошла достаточно быстро, так как стран, где были доступны платные услуги, было не много. Но она была рассчитана только на прием платежей через SMS, из-за этого у нас даже до сих пор сохранилось несколько забавных артефактов, например, поля MSISDN (номер телефона) и short code (короткий номер, на который отсылают платную SMS) в таблице обработанных платежей.

    Сейчас мы принимаем платежи почти во всём мире. Каждую секунду пользователи пытаются что-то оплатить на сайте или в приложениях для всех популярных мобильных платформ. А если наложить это на карту, то получится картина «Вид на Землю из космоса ночью»:

    image

    У нас доступно около 50-ти способов оплаты, предоставляемых разными партнерами. Самые популярные ― это банковские карты, SMS & Direct billing и покупки в мобильных приложениях.

    image

    Среди них есть и экзотические, например, прямое списание со счета интернет-провайдера или оплата через городской телефон. А однажды нам поступил платеж через обычную почту!

    image

    Банковские платежи


    Все платежные системы позволяют принимать платежи от своих пользователей. Такие прямые интеграции удобно делать, пока их не очень много и вы подключаете известные системы с отлаженными процессами. Но когда нужно выйти на локальные рынки, то начинают появляться проблемы. Поддерживать «зоопарк» разных API становится всё сложнее, отличаются требования регуляторов, популярная локальная платежная система может вообще отказаться работать с иностранными клиентами при низких оборотах, или подписание контракта и улаживание юридических проблем может затянуться на долгое время. Несмотря на такие сложности, локальные платежные системы могут вас приятно удивить своей конверсией. Например, Голландия, которую мы считали не очень перспективной, после подключения популярного в этой стране способа оплаты iDeal стала приносить на 30-40% больше денег.

    Если есть спрос, будет и предложение. На рынке много компаний-агрегаторов, или, по-другому, платежных шлюзов (англ. payment gateway), целью которых является объединение всех популярных платежных систем, в том числе локальных, под единым API. Сделав одну такую интеграцию, мы получаем возможность принимать платежи через десятки платежных систем по всему миру. Можно даже не делать страницу оплаты на своем сайте, а воспользоваться уже готовой, предоставленной агрегатором, и подогнать под себя только дизайн. Особо продвинутые компании дают возможность загружать свои CSS- и JS-файлы, менять картинки, тексты переводов и даже зарегистрировать получившуюся страницу на вашем поддомене, например, payments.example.com. Это дает очень богатые возможности по «кастомизации», и у пользователя складывается ощущение, что он не покидает ваш сайт. У себя мы этой возможностью не пользуемся, так как одновременно работаем с несколькими агрегаторами, но для кого-то это может быть очень удобным решением.

    Какой способ использовать ― прямую интеграцию или через агрегатора ― зависит в первую очередь от размера комиссии. Чем больше ваших клиентов пользуется платежной системой, тем выгоднее может оказаться сэкономить на комиссии и подключиться к ней напрямую. Второй важный фактор ― это качество API, удобство работы и стабильность. Здесь агрегаторы позволяют сгладить шероховатости, а иногда и предоставить более стабильный сервис, чем прямое подключение.

    SMS-платежи


    Особняком стоят платежи через SMS и прямые списания с баланса мобильного телефона. Они находятся под очень жестким контролем во многих странах, особенно в Европе. Локальные регуляторы или само государство могут предъявлять особые требования к тому, как должна выглядеть страница оплаты или каким должен быть текст отсылаемых SMS-сообщений. За изменениями подобных требований нужно следить и вовремя вносить изменения у себя на сайте. Так, например, в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне, а рядом с ним должна быть указана его стоимость.

    image

    Отличается и тип SMS-биллинга ― MO (Mobile Originated) или MT (Mobile Terminated). С MO-биллингом всё достаточно просто: пользователь отправил SMS на короткий номер, мы получили деньги. А вот для MT существует несколько вариантов. Оплата происходит не в момент отправки пользователем SMS-сообщения, а после того, как он получит специальное платное SMS от нас. То есть фактом оплаты считается полученное от агрегатора уведомление о том, что платное SMS успешно доставлено. Основная цель такого подхода ― это добавить дополнительную проверку перед отправкой пользователю платного SMS-сообщения и предотвратить ошибки, связанные с некорректным текстом в SMS. Для этого оплата происходит в две фазы. Первая ― пользователь выражает желание оплатить что-то, вторая ― это подтверждение. К примеру процесс оплаты может выглядеть так:
    • отправляем SMS на короткий номер, отвечаем на пришедшее SMS определенным текстом или без него;
    • отправляем SMS на короткий номер, вводим на сайте полученный PIN-код;
    • вводим на сайте номер телефона, получаем PIN-код, вводим его на сайте.

    К счастью, на рынке SMS-платежей тоже есть компании-агрегаторы, услугами которых стоит воспользоваться. Они за скромную, а иногда и не очень, плату лишают вас «удовольствия» разбираться с такими подробностями. Еще один приятный бонус ― они нередко берут на себя часть обязанностей по поддержке конечных пользователей. Пользователи начинают писать о своих проблемах напрямую владельцу короткого номера, т.е. агрегатору.

    Технические детали


    Badoo работает на связке PHP + MySQL, поэтому для обработки платежей мы используем те же технологии. Код выполняется на отдельной группе серверов, выделенной из общего пула. Внутри мы ее разделили еще на несколько логических подгрупп: cерверы для обработки входящих запросов, серверы для фоновых операций и сбора статистики, серверы баз данных, серверы для обработки платежей по банковским картам. Последние выделены в отдельную группу, потому что они должны соответствовать стандарту безопасности PCI DSS, разработанному при участии Visa, MasterCard, American Express, JCB и Discover для организаций, работающих или хранящих данные держателей банковских карт.

    Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного (на время его обслуживания, для запросов от системы мониторинга или сбора статистики).

    Всю систему биллинга можно условно разделить на несколько больших частей:
    • Ядро. Сюда входят базовые сущности, такие как Заказ, Платеж, Услуги и правила их учета и оказания, различные инфраструктурные вещи.
    • Плагины агрегаторов. Всё, что отвечает за коммуникацию между нами и платежной системой.
    • Страница выбора и оплаты услуг.

    Подключение нового платежного метода к системе заключается как раз в создании его плагина. Он отвечает за все взаимодействия между нами и платежным шлюзом, которые бывают двух видов: когда мы являемся инициатором (pull request) и когда инициатором является агрегатор (push request). Для pull-запросов в качестве протокола обычно используется HTTP, чистый или как транспорт для JSON/XML, либо SOAP. Популярная в последнее время концепция REST API нам встречалась не часто, только у новых на рынке компаний, например, у Британского GoCardless, либо у старых, которые решили переработать свой API, например, PayPal. Для push-запросов практически не используется SOAP (из тех, кто предлагает такой формат push-уведомлений, легко вспоминается только Qiwi). В основном используется чистый HTTP или он же в качестве транспорта для всё тех же JSON и XML.

    После реализации API наступает этап тестирования. На Хабре уже были статьи о том, как выглядит наш процесс разработки и автоматизации. Но для биллинга есть некоторые особенности, связанные в основном с тем, что приходится тестировать не просто наш код, но и взаимодействие с агрегаторами. Очень удобно, если у них есть для этого тестовое окружение, которое полностью эмулирует реальный прием платежей. Если же его нет, мы делаем «заглушки», эмулирующие поведение агрегатора. Это упрощает нам ручное тестирование и позволяет писать автотесты, проверяющие весь процесс оплаты. Вот пример того, как выглядит одна из заглушек.

    image

    После тестового окружения нужно проверить, как всё будет работать в жизни, провести реальную оплату. Но для SMS-платежей часто приходится получать одобрение от регуляторов или операторов, а это может длиться несколько месяцев. Чтобы не выкладывать полуготовый код на продакшн-серверы, мы придумали такую вещь, как External Shot. Это наш обычный Shot, который представляет из себя директорию с веткой задачи и предназначен для ее тестирования на продакшн-серверах, но кроме локального домена он имеет дополнительный внешний адрес, по которому любой желающий может зайти и посмотреть сделанные изменения. Для безопасности такие «шоты» создаются не для каждой задачи, а только в тех случаях, когда действительно необходимо. Ссылки на них мы даем нашим партнерам, и они в любое время дня и ночи могут проверить сделанные изменения. Особенно это актуально для стран, расположенных в другом полушарии, с которым разница во времени может достигать 12 часов.

    Поддержка и эксплуатация


    После того как новая интеграция выкладывается на продакшн-серверы, наступает этап ее эксплуатации и поддержки. Техническая поддержка занимает примерно 60-70% нашего времени.

    image

    Сюда входит, во-первых, разбор жалоб от пользователей. Все простые ситуации решаются командой первой линии поддержки, она же переводит для нас жалобы с разных языков на английский. Поэтому к нам попадают только самые сложные случаи, действительно требующие внимания разработчиков.

    Вторая составляющая технической поддержки ― это исправление ошибок или внесение изменений в существующие интеграции. Ошибки возникают по разным причинам. Например, из-за невнимательного чтения документации или пробелов в ней. Однажды вместо нее нам даже пришлось использовать логи чата с разработчиком агрегатора, потому что документация для их новой системы была еще не готова. Были случаи, когда агрегатор без уведомления менял протокол взаимодействия или его параметры. В другой раз банк-эквайер отключил наш шлюз, и пришлось в срочном порядке перенаправлять трафик в другое место. Как потом выяснилось, это был древний сервер из 80-х, который, по данным банка, вообще ничего не должен был обрабатывать. В общем, скучать не приходится, особенно если учитывать, что каждая минута простоя ― это недополученная прибыль.

    Для решения подобных проблем мы пишем подробные логи работы приложения. Туда попадают не только ошибки, но и всё взаимодействие с системами агрегаторов или просто важные события, происходящие во время выполнения запросов. Каждый запрос имеет свой уникальный идентификатор, по которому можно найти все связанные с ним записи и восстановить ход его обработки. Это бывает особенно полезно, когда приходится разбираться с ошибками, с момента которых уже прошло несколько недель или месяцев.

    Вот так организован биллинг в Badoo. Конечно, осталось еще много интересных тем, о которых мы планируем рассказать будущем, например мониторинг, сертификация PCI DSS и обработка платежей по банковским картам. Если есть вопросы или какие-то пожелания по теме будущих статей, добро пожаловать в комментарии.

    Анатолий Панов
    Ведущий разработчик
    Badoo
    354,00
    Big Dating
    Поделиться публикацией

    Комментарии 52

      +15
      Интересно было бы почитать, как именно вы получали PCI DSS. Какого уровня, сколько заплатили, как долго проходила сертификация.
        +4
        Есть планы написать отдельную статью о том, как у нас в целом организован прием кредиток. В ней обязательно расскажем.
        +2
        А нет ли возможности сгенерировать картинку о распределении платежей по способам оплаты не для всего мира, а для Евразии (у вас, как я понимаю, велика доля Южной Америки) или даже отдельно — севр. америка, юж. америка, западная европа, снг, восточная европа?
          +1
          Для СНГ будет не репрезентативно. На карту посмотрите.
            +1
            Именно по странам не очень просто. Сделал картинку со странами которые используют Евро в качестве валюты
            image
              0
              спасибо за диаграмму! А это за какой период статистика?
              Как-то не верится что в европе такие дремучие люди, предпочитающие платить через смс…
                +1
                За последние сутки. Мне тоже не верилось когда писал, но с цифрами сложно спорить :)
                В раздел «SMS & Direct Billing» так же входят платежи которые были сделанны из приложения под Android и c мобильной версии сайта. Я думаю для таких пользователей SMS может быть удобнее и привычнее, поэтому такие цифры.
                  +1
                  А какой возраст у большинства ваших юзеров в евросоюзе? Может у вас большинство это пожилые люди?

                  а у вас все виды платежей стоят одинаково для пользователя (то есть вы комиссию за платеж платите сами, хотя она для мобильных платежей и для direct debit различается на несколько порядков)?

                  ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.
                    0
                    Про возраст не скажу, аналитикой больше продуктовый отдел занимается, а комиссию платим сами. Например в Европе 100 кредитов (внутреняя валюта) на всех способах оплаты стоит 2€, не смотря на то что комиссия везде разная.

                    ИМХО вам стоит подумать чтобы стать платежным шлюзом (принимающим эти 50 видов национальных платежей) — в данный момент эта ниша почти никем не занята.

                    Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы. Мы сами же ими и пользуемся, еще и выбираем у кого комиссия меньше, API удобнее, покрытие выше.
                    Если и становиться самим платежным шлюзом, то надо какое-то конкуретное преимущество иметь, чтобы выбирали именно нас. Вот пока непонятно какое именно.
                      +1
                      > Мой опыт показывает что ниша уже давно не свободная. Предложений очень много, на любые вкусы.

                      Подскажите какие-нибудь варианты, чтоб поддерживали 50 видов популярных национальных платежей. plimus (bluesnap), share-it и все что от digital river,2checkout, и даже payproglobal (вроде он поддерживает макс. число национальных платежей из всех регистраторов) каждый в сумме 50 видов платежей не поддерживают. Постоянно мониторю этот вопрос ибо это актуально.

                      Если бы такие всеядные шлюзы уже были, вы бы наверно не стали сами городить весь этот зоопарк из плагинов, а пользовались бы им, верно?
                        0
                        Например Adyen, очень приятные в работе ребята. Вот список того что они поддерживают.
                          +1
                          огромное спасибо за Adyen!
                          А можете еще аналоги назвать, на случай если у нас с ними что-то не срастется?
                            0
                            Все остальное увы под NDA. Насколько я помню упомянутый «digital river» тоже имеет внушительный список. На сайте у них не нашел в открытом доступе, думаю высылают по запросу.
                              0
                              Ко мне можно обратиться касательно сервисов Digital River для индивидуальных предпринимателей и СМБ (они, т.е. мы — уже почти год представлены в России целым офисом в Москве — под брендом MyCommerce, это компания группы Digital River, объединяющая платформы MyCommerce-RegNow, ShareIt-Element5, SWREG и eSellerate). По Enterprise-аккаунтам тоже знаю, с кем связать.

                              Сейчас на самых массовых платформах доступно до 20-25 топовых способов платежей (с учетом того, что они cost-effective — т.е. не в виде Premium SMS, где комиссия может быть до 90%...), и это число можно расширить — новые регионы подключаются on-demand + постоянно идет расширение числа платежей, доступных на массовых платформах.

                              Для справки, а не для SEO: Тарифы и способы платежей флагманской платформы MyCommerce для продаж программ, веб-сервисов и т.п.
                                0
                                Речь про массовые платформы MyCommerce/Share-It, разумеется.
                            +1
                            мы связались с Adyen.
                            Открыли у них тестовый акк, они спросили подробности о нас, мы им сказали, они подумали и сказали что с компаниями из РФ они не работают…

                            Так что если вспомните еще кого-либо не под вашим NDA, дайте знать.
                            0
                            Смысл иметь больше одного всеядного платежного шлюза лежит не столько в технической, сколько в бизнес сфере. Например мы хотим через кого-то принимать платежи по банковским картам, но для этого должны проводить не меньше определенного количества транзакций, по картам у нас столько не получается, приходиться добавлять другие платежные методы.
                +1
                Спасибо, интересная статья.

                > Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации

                А чем продиктовано master-master? master-slave судя по пояснениям в скобках тоже бы хватало?
                  0
                  Второй сервер становиться основным если например нужно перезагрузить MySQL на первом. Плюс он используется для горячей замены, если вдруг первый выйдет из строя.
                    0
                    Но percona рекомендует минимум 3 узла в кластере (если у вас percona xtradb cluster, конечно)
                      +1
                      У нас обычный master-master, без xtradb cluster.
                  +1
                  Для обработки платежей мы используем два сервера базы данных с MySQL от Percona, работающих в master-master репликации. Основная нагрузка идет только на один из них, второй используется для «горячей» замены в случае аварии или для подмены основного

                  А не страшно? Ну в смысле репликация асинхронная, бинарные логи синкаются иногда не так как ожидается – данные потерять можно запросто.
                    0
                    Со Statement-Based репликацей были проблемы, сейчас перешли на Mixed и настроили автоматический check-sum таблиц. Пока все хорошо :)
                    +1
                    Здравствуйте! Расскажите пожалуйста подробнее о ядре вашего биллинга? ;]

                    Пишу свой биллинг для личных нужд, самые простые вещи делать он умеет, но как научить биллинг таким вещам, как промо-акции, механизм бонусов, скидок, Я пока не придумал как это красиво сделать.
                      +8
                      делайте некрасиво, походу подгоните
                        0
                        Наша текущая схема промо, скидок и т.п. нас тоже полностью не устраивает. Думаем над ее развитием и улучшением. Как реализуем, поделимся опытом :)
                        +3
                        что-то я не совсем понял про сервера которые соответствуют PCI DSS. вы же гетевэями пользуетесь, у себя платёжную инфу не храните, зачем?
                          +1
                          Для обработки платежей по картам мы тоже используем больше одного гейтвея, поэтому у нас своя страница ввода деталей карты и правила по которым транзакции отправляются к нужному гейтвею. А раз мы обрабатываем детали карточек, то партнеры требуют чтобы мы были сертифицированы.
                            +1
                            т.е. вы не хостинг страницы гетевеев используете, а их API?
                              +1
                              я к тому, что если вы посылаете уже данные с карты и получаете ответ платёж принят/платёж отклонён, то странно, что пользователь должен сам выбирать гетевей. а если для осуществления платежа пользователь переходит на страницу гетевея, то для серверов стандарты PCI не категоричны. что-то я упускаю
                                0
                                Для платежных карт пользователь всегда видит одну и ту же форму, которую отдает сам Badoo. Он никогда не выбирает партнера.
                                  0
                                  а вот тут вроде как выбирает,

                                  image

                                  или это вроде с кошелька на кошелёк?
                                    0
                                    Что выбирает? :) Это оплата через SMS на скриншоте он может выбрать только количество кредитов которое хочет купить. Либо сменить тип оплаты.
                                    Форма оплаты кредиткой выглядит вот так
                                    image
                                  +2
                                  Да, для карт мы не используем готовые страницы и используем API.
                                  Пользователь ничего не выбирает, только вводит данные карты. Логика о том куда пойдет платеж находится на сервере и зависит от параметров транзакции, например есть список стран с высоким риском фрода, транзакции из этих стран мы хотим принудительно подтверждать через 3D Secure. Если по BIN карты мы видим что она выдана в стране из этого списка, то отправляем ее на аккаунт где он включен. В зависимости от типа карты, транзакция может уйти в банк который лучше обрабатывает именно этот тип карт.
                                    +1
                                    да да, это всё понятно. меня просто смутил выбор между paypal, creditcard, sofort, paysafecard. которые, кроме прочего, предоставляют услуги гетевеев. теперь всё ясно, спасибо за терпение.

                                    кстати, ради профессионального интереса, если выбраный гетевей недоступен, платёж идёт на другой или отклоняется?
                                      0
                                      Пока что откланяется, но мы вот-вот добавим функционал делающий несколько попыток, через разные гейтвеи.
                                        +1
                                        здорово. а пока транзакция процессится, данные карточки в базе хранятся или на криптоустройстве?
                                          0
                                          В памяти. Мы пользуемся чудесной возможностью PHP-FPM fastcgi_finish_request(), которая позволяет завершить HTTP запрос, но продолжить выполнение скрипта.
                                            +1
                                            хорошо. а если с сервером что-то случилось до получения ответа, вы потом пробегаетесь по незавершённым транзакциям, запрашиваете статус платежа у гетевея и проставляете транзакции статус?
                                              0
                                              По разному. У кого-то есть push нотификации, если что-то сломается в процессе обработки запроса мы узнаем об этом когда статус транзакции измениться у агрегатора. А для кого-то приходиться опрашивать статус.
                                                0
                                                теперь вроде как сложилось. спасибо
                              +3
                              1. Как Вы делаете заглушки, эмулирующие платежные системы? По документации разбираетесь в протоколе?

                              2. Как вы поддерживаете зоопарк шаблонов страниц оплаты (в Бельгии есть правило, что короткий номер должен быть написан белым шрифтом на черном фоне). Куча if'ов по стране и типу оплаты?
                                +2
                                1. Каждый плагин конкретной платежной системы реализует некий абстрактный класс. Когда пишется новый плагин для платежного метода, то он по большей части реализует стандартные методы абстрактного класса, а потому основные методы заглушек реализуются автоматически. Для всего остального по документации протокола дописывается свой код. Сам вызов из заглушки дергает процессор из devel окружения и отрабатывает полный алгоритм.

                                2. Плагин агрегатора расширяется наследником для страны, если это необходимо. Аналогично для шаблонов — простыми префиксами реализуется выбор нужного шаблона для конкретной страны/агрегатора/оператора.
                                0
                                Как биллинг общается с сервисами? Например когда пользователь хотел купить подарок.
                                  0
                                  Не понял вопрос. С какими сервисами? С внутренними?
                                    0
                                    Да, с внутренними.
                                      +1
                                      Никакой особой магии нет. У нас общий репозиторий, просто вызываем методы нужных классов :)
                                      Если чуть подробнее, то во время обработки платежа, в транзакции, мы кладем запись в очередь доставки подарков. От туда ее забирают скрипты и доставлют подарок до пользователя.
                                      Сам биллинг выступает для баду в виде «сервиса» у нас есть внутренее API, используем HTTP + JSON. Но весь остальной функционал просто код, дополнительных абстракций нет.
                                      В виде полноценных сервисов работают только демоны написанные на C.
                                  0
                                  Direct billing — вы имеете ввиду прямой биллинг баланса моб телефона?
                                    0
                                    Да
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Вы описываете биллинг, но нигде не говорите о выставлении счетов. Этой задачи у Вас нет? Или у Вас проста и тривиальна​?
                                        0
                                        Если вопрос о бухгалтерской части и выставлении/сверке счетов, то этим занимается Лондонский офис. Мы только обеспечиваем их исходными данными и поддерживаем интерфейс позволяющий проставлять процент комиссий.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое