Полгода назад я устроился в финтех-стартап, имеющий примерно 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, и мы часто предполагаем, что они соответствуют всем необходимым нормам.
Я обнаружил, что это не всегда так (разумеется, обязанность проверки лежит на вас).
Два примера:
- В ЕС поставщик должен перед каждой продажей проверять правильность номера плательщика НДС (VAT) клиента.
Например, Stripe выполняет проверку VAT только один раз, при настройке VAT. Он не проводит никаких последующих проверок и не сопоставляет информацию о клиенте.
Некоторые другие сервисы вообще этого не делают, поэтому убедитесь, что ваша система отвечает требованиям!
- Налоговый счёт-фактура ЕС (EU VAT invoice) должен содержать определённую информацию о кодах НДС (VAT ID) вашей компании. Однако многие генераторы счетов (в том числе до недавнего времени и генератор Stripe) даже не имели способа ввода информации об НДС.
Возможно, у вас получится хитростью ввести налоговую информацию, например, в поле для адреса. Как бы то ни было, проверяйте биллинговую систему на соответствие требованиям!
Что происходит, когда пользователь меняет тарифный план?
Я думал, что регистрация в системе компании — это просто. Клиент регистрируется и после кратковременного пробного периода использует продукт как платный бессрочный (evergreen) пользователь, и всё замечательно!
Идеальная компания начинает пользоваться продуктом и не меняет ничего на протяжении всего своего жизненного цикла
Как и многие другие компании, мы предлагаем различные уровни сервиса. Однако мы взымаем оплату за месяц заранее. Поэтому если повышает или понижает уровень сервиса, нам нужно изменить его тарифный план в какой-то момент в будущем.
Смена тарифного плана может быть запланирована на будущую дату, однако клиент может захотеть немедленно начать использовать новый уровень сервиса.
Кажется, что это вполне нормально, но тут стоит рассмотреть различные ситуации.
- Что если клиент немедленно хочет получить новый уровень сервиса? В таком случае мы не можем изменить его план, не выставив ему счёт. Это означает, что нужно отделить движок биллинга от движка регулирования прав (entitlement engine), управляющего уровнем сервиса!
Вы можете также мгновенно заранее запросить оплату, но что насчёт пропорционального распределения?
- Что если клиент захочет немедленно платить за новый тарифный план? (Такая ситуация встречается гораздо чаще, чем вы бы могли подумать.) Мы можем мгновенно изменить их план! Но тогда нам взымать только разность или вернуть сумму за целый месяц и повторно взять оплату за новый сервис? О нет, нам снова мешает это ужасное пропорциональное распределение (у Chargebee есть хорошее руководство по пропорциональному распределению), из-за которого возникают счета, в которых очень сложно разобраться вам, службе поддержки и самому клиенту.
Довольно тривиальный пример. Иногда в счетах бывают десятки строк. Проблема!
- Иногда мы должны немного увеличить время пробной версии, чтобы у клиента было больше бесплатного времени для подготовки. Но с этим аспектом всё достаточно просто...
- Однако иногда клиент вспоминает об этом только после начала фазы evergreen. Это кошмар, но вам, возможно, придётся создавать возвратные накладные для некоторых счетов!
Существует ещё, наверно, с десяток других вариаций жизненных циклов компаний. Хотя такие ситуации возникают не всегда, они обязательно возникнут, когда у вас появится хотя бы пара сотен клиентов. Думайте заранее, как будете обрабатывать все эти случаи!
А если принудительно отказаться от пограничных случаев?
Клиенты — это не компании. Они люди. А у разных людей есть разные потребности.
Если вы работаете в среде не с чрезмерно строгими правилами, то вам придётся выбирать, насколько серьёзно вы будете заставлять следовать этим правилам.
Вот некоторые мелкие примеры, с которыми мы сталкивались:
- Мы предоставили скидку только для клиентов из Великобритании. Отлично, но что насчёт британского клиента, имеющего дочернюю компанию в Германии? Эта скидка относится и к ней? (Мы ответили положительно!)
- Мы запустили кампанию, в течение которой каждый зарегистрировавшийся получил возможность бесплатно пользоваться продуктом до 1 апреля 2021 года. Это предложение было доступно всем компаниям, даже имеющим договор на несколько лет. Однако после подписания договора многие компании всё равно захотели заплатить.
- Некоторые компании захотели заплатить в конце 2020 года заранее за 2021 год, потому что у них был остаток бюджета, который нельзя было бы использовать в 2021 году. Наша система не была рассчитана на поддержку авансовых платежей, которые вносят раньше срока.
Какие бы ограничения вы не планировали, планируйте и способы их обхода. Это обязательно пригодится.
На мой взгляд, лучше поддерживать бизнес и завоёвывать благосклонность клиентов, чем быть непреклонным.
Ничто не бывает простым
Какой бы простой ни казалась поначалу сфера задач, в ней всегда присутствует глубина и есть множество вопросов, требующих ответа.
Я осознал, насколько сложно проектировать, разрабатывать и эксплуатировать биллинговые системы, если вы хотя бы ненамного отклоняетесь от «стандартного» поведения. Однако вкладываясь в их правильную реализацию, вы идёте навстречу потребностям клиентов, отделов продаж, техподдержки и финансовых отделов!
Хоть это и самые важные пять пунктов, которые бы я хотел знать перед началом работы с биллинговыми системами, данный список далеко не полон.
На правах рекламы
Серверы для бизнеса и любых крупных проектов — это про наши эпичные серверы. Максимальная конфигурация — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe, надёжный дата-центр в Москве, защита от DDoS-атак «из коробки», активация сервера в течение минуты!
Автор: Mikhail
