Чему я научился, разрабатывая биллинговую систему

Автор оригинала: Arnon Shimoni
  • Перевод


Полгода назад я устроился в финтех-стартап, имеющий примерно 15 тысяч клиентов. Моя задача заключалась в развитии биллинговой инфраструктуры. Когда я пришёл в компанию, меня немного беспокоила узость задач моей новой должности и нового отдела. Я думал: ну какая глубина может быть в биллинге? Разве у нас не закончатся задачи спустя 3-4 месяца? Клиент регистрируется, ежемесячно оплачивает подписку, вот и всё, правда ведь?

… правда?

Вообще да, но на самом деле нет. Это только самый простой сценарий, а кроме него существует множество пограничных случаев и тонкостей.

Поиск всех этих пограничных случаев один за другим был не самым приятным процессом. Было бы здорово, если бы кто-то составил краткое руководство о том, что мне нужно знать. Поэтому вот и оно, моё руководство! Если вы размышляете о создании (или даже об использовании) системы биллинга, то читайте внимательно.

Деньги не всегда десятичны


Все знают, что при проектировании баз данных никогда не нужно использовать для хранения денег числа с плавающей запятой. Кто-то рекомендует использовать тип данных MONEY, другие — тип DECIMAL.

И те, и другие иногда ошибаются. Да, конечно, в США и большей части Европы деньги десятичны.

Но с Японией другая ситуация — вы не можете взять оплату в 2500,50 японских йен. Впрочем, можно и не трогать Японию — в Исландии тоже нет дробных значений валюты. И наоборот — иракский динар имеет в дроби три десятичных знака.

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

Храните деньги с записью наименьшего возможного деления.

Например, в большинстве ситуаций:

  • 100 долларов США можно хранить как 10000
  • 2500 японских йен можно хранить как 2500
  • 2500 исландских крон можно хранить как 2500
  • 100 иракских динаров можно хранить как 100000

Вот выборка валют, не имеющих дробных значений (столбец Д)

Код Номер Д Валюта Регионы, в которых используется эта валюта
BIF 108 0 Бурундийский франк Бурунди
CLP 152 0 Чилийский песо Чили
DJF 262 0 Франк Джибути Джибути
GNF 324 0 Гвинейский франк Гвинея
ISK 352 0 Исландская крона Исландия
JPY 392 0 Японская йена Япония
KMF 174 0 Франк Комор Коморы
KRW 410 0 Южнокорейская вона Южная Корея
PYG 600 0 Парагвайский гуарани Парагвай
RWF 646 0 Руандийский франк Руанда
UGX 800 0 Угандийский шиллинг Уганда
VND 704 0 Вьетнамский донг Вьетнам

Полный список валют с их делением можно найти в стандарте ISO 4217, часть которого есть в Википедии.

Нельзя отменять или аннулировать уже созданные счета


По крайней мере, в большей части Европы. В США аннулирование неоплаченных счетов является распространнёной практикой. Однако это незаконно в большинстве стран ЕС. Если вы сделаете ошибку, это создаст большую головную боль!

Это «стандартная бухгалтерская практика», однако иногда больно узнавать о ней, потому что ошибки случаются. После создания счёта для его отмены можно сделать только одно: создать возвратную накладную на полную сумму.

Что такое «возвратная накладная»? Можно рассматривать её как счёт в обратную сторону. Возвратные накладные — это отдельный уникальный тип коммерческого документа. Как и счета, они имеют собственный номер.

То есть возвратная накладная — это документ, позволяющий отметить исходный счёт как «оплаченный», даже несмотря на то, что деньги не передавались между сторонами.

Возвратные накладные также полезны для взимания общей суммы, которую должен заплатить клиент. Допустим, вы составили счёт клиенту за 20 пользователей по 10 фунтов, но пять из этих пользователей были неактивны и должны быть отменены. На исходный счёт в 200 фунтов можно оформить возврат на 50 фунтов (5 × 10), то есть клиенту нужно будет заплатить 150 фунтов.

Не все биллинговые системы соответствуют законодательству


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

Многие компании покупают услуги сторонних продуктов SaaS, и мы часто предполагаем, что они соответствуют всем необходимым нормам.

Я обнаружил, что это не всегда так (разумеется, обязанность проверки лежит на вас).

Два примера:

  1. В ЕС поставщик должен перед каждой продажей проверять правильность номера плательщика НДС (VAT) клиента.

    Например, Stripe выполняет проверку VAT только один раз, при настройке VAT. Он не проводит никаких последующих проверок и не сопоставляет информацию о клиенте.

    Некоторые другие сервисы вообще этого не делают, поэтому убедитесь, что ваша система отвечает требованиям!

  2. Налоговый счёт-фактура ЕС (EU VAT invoice) должен содержать определённую информацию о кодах НДС (VAT ID) вашей компании. Однако многие генераторы счетов (в том числе до недавнего времени и генератор Stripe) даже не имели способа ввода информации об НДС.

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

Что происходит, когда пользователь меняет тарифный план?


Я думал, что регистрация в системе компании — это просто. Клиент регистрируется и после кратковременного пробного периода использует продукт как платный бессрочный (evergreen) пользователь, и всё замечательно!


Идеальная компания начинает пользоваться продуктом и не меняет ничего на протяжении всего своего жизненного цикла

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


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

Кажется, что это вполне нормально, но тут стоит рассмотреть различные ситуации.

  • Что если клиент немедленно хочет получить новый уровень сервиса? В таком случае мы не можем изменить его план, не выставив ему счёт. Это означает, что нужно отделить движок биллинга от движка регулирования прав (entitlement engine), управляющего уровнем сервиса!



Вы можете также мгновенно заранее запросить оплату, но что насчёт пропорционального распределения?

  • Что если клиент захочет немедленно платить за новый тарифный план? (Такая ситуация встречается гораздо чаще, чем вы бы могли подумать.) Мы можем мгновенно изменить их план! Но тогда нам взымать только разность или вернуть сумму за целый месяц и повторно взять оплату за новый сервис? О нет, нам снова мешает это ужасное пропорциональное распределение (у Chargebee есть хорошее руководство по пропорциональному распределению), из-за которого возникают счета, в которых очень сложно разобраться вам, службе поддержки и самому клиенту.



Довольно тривиальный пример. Иногда в счетах бывают десятки строк. Проблема!

  • Иногда мы должны немного увеличить время пробной версии, чтобы у клиента было больше бесплатного времени для подготовки. Но с этим аспектом всё достаточно просто...


  • Однако иногда клиент вспоминает об этом только после начала фазы evergreen. Это кошмар, но вам, возможно, придётся создавать возвратные накладные для некоторых счетов!



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

А если принудительно отказаться от пограничных случаев?


Клиенты — это не компании. Они люди. А у разных людей есть разные потребности.

Если вы работаете в среде не с чрезмерно строгими правилами, то вам придётся выбирать, насколько серьёзно вы будете заставлять следовать этим правилам.

Вот некоторые мелкие примеры, с которыми мы сталкивались:

  1. Мы предоставили скидку только для клиентов из Великобритании. Отлично, но что насчёт британского клиента, имеющего дочернюю компанию в Германии? Эта скидка относится и к ней? (Мы ответили положительно!)
  2. Мы запустили кампанию, в течение которой каждый зарегистрировавшийся получил возможность бесплатно пользоваться продуктом до 1 апреля 2021 года. Это предложение было доступно всем компаниям, даже имеющим договор на несколько лет. Однако после подписания договора многие компании всё равно захотели заплатить.
  3. Некоторые компании захотели заплатить в конце 2020 года заранее за 2021 год, потому что у них был остаток бюджета, который нельзя было бы использовать в 2021 году. Наша система не была рассчитана на поддержку авансовых платежей, которые вносят раньше срока.

Какие бы ограничения вы не планировали, планируйте и способы их обхода. Это обязательно пригодится.

На мой взгляд, лучше поддерживать бизнес и завоёвывать благосклонность клиентов, чем быть непреклонным.

Ничто не бывает простым


Какой бы простой ни казалась поначалу сфера задач, в ней всегда присутствует глубина и есть множество вопросов, требующих ответа.

Я осознал, насколько сложно проектировать, разрабатывать и эксплуатировать биллинговые системы, если вы хотя бы ненамного отклоняетесь от «стандартного» поведения. Однако вкладываясь в их правильную реализацию, вы идёте навстречу потребностям клиентов, отделов продаж, техподдержки и финансовых отделов!

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



На правах рекламы


Серверы для бизнеса и любых крупных проектов — это про наши эпичные серверы. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe, надёжный дата-центр в Москве, защита от DDoS-атак «из коробки», активация сервера в течение минуты!

VDSina.ru
Серверы в Москве и Амстердаме

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

    +2
    Это они ещё не пытались правильно учесть российскую банковскую комиссию в валюте, выставленную на 365 дней, пересекающих високосный год, списываемую со счёта в другой валюте, которую клиент оплачивает где-то в середине срока. Там могут быть и учёт доходов будущих периодов, и доходы/расходы от встроенных производных инструментов, неотделяемым от основного договора (из-за колебания курсов валют). А ещё для такой комиссии может потребоваться возврат… или клиент её может так и не оплатить… Или оплатить частично…
      +2

      В начале статьи, когда рассуждали про десятичное деление валют, я, уж было, запаниковал, представив, что есть валюты с делением не кратным 2 или 5. Это ж запросто могло быть 3. А вот представьте, треть рубля или доллара, которые надо хранить точно и из из трёх третей составить рубль и при этом сохранить точность в десятичной сфере...

        0
        есть валюты с делением кратным 12. К счастью последняя такая устарела уже лет 15 как. Примерно в тот момент стали становиться популярными подходы с хранением денег в decimal или money.
          0
          Я попытался найти что-то такое самостоятельно и, судя по вики, примерно в 1970ых закончился процесс перехода на десятичные валюты. Осталась парочка с делением на 5, но это не мешает. Единственной формальной валютой всё ещё не перешедшей на десятичный размен, получается, остаётся Мальтийский скудо. Но, я так понимаю, валюта не участвует в торгах на валютных рынках и является больше традицией. Валюта всё ещё имеет хождение на территории Мальтийского ордена, где в 2005 году было также разрешено хождение евро.
            0
            Вот загуглил, тоже не нашел. Можно списать на то, что это просто байка. Там насколько я помню, что было было прямо в ISO 4217 где-то до средины нулевых.
        0
        А в биллинге сотовых операторов надо имитировать онлайновый расчёт при звонках prepaid клиентов, то есть здесь есть не только все вышеперечисленные сложности, но и все расчёты надо производить очень быстро, прямо в процессе звонка!
          +1
          Еще в некоторых странах бывают тн «sudden holidays» — религиозные праздники, дата которых недетерминирвана и определяется чуть ли не по звездам и фазам луны толкователями священных книг. Очень весело пересчитывать документы и счета при этом.
            0
            Какие бы ограничения вы не планировали, планируйте и способы их обхода. Это обязательно пригодится.

            Вот это прям в точку.
              0
              Все случаи всегда были в бизнесе, не правда ли? Возьмите биллинг любой b2с компании.
              Почему «фин-тех стартап» исследует велосипед и ИТ это решает?
              Нет ответа, все вопросы к бизнесу, который не компетентен что бы родит продукт до эго внедрения.
                0
                А еще есть криптовалюты, которые хотя бы спасибо, что десятичные, но после запятой там может твориться много всякого.

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

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