😵💫 Почему биллинговые системы — кошмар для инженеров

Эта статья была первоначально опубликована в блоге Lago, API биллинга с открытым исходным кодом, и 2 дня подряд занимала первое место на HackerNews.


«В мой первый день мне сказали: «Оплата придет позже, должно быть несложно, верно?». Я забеспокоился. Мы продавали и доставляли не товары, а SSD и ядра процессора, петабайты и миллисекунды, пространство и время. Мгновенно, через API. Мгновенно, через API. На всех континентах. Таково было видение. Через неделю я почувствовал, что я единственный, кто действительно обеспокоен предстоящим долгим путем. В амбициозных корпоративных проектах сложность быстро нарастает: многопользовательский режим, много пользователей, много ролей, много валют, много налоговых кодов, много всего. Эти системы были невеселыми, некоторые из них были древними и часто «похожими на спагетти». То, что должно было быть годичным проектом R&D, в итоге заняло семь лет моей профессиональной жизни, в течение которых я увеличил команду биллинга с 0 до 12 человек. Так что да, если вы спросите меня, биллинг — это сложно. Труднее, чем вы думаете. Пришло время решить эту проблему раз и навсегда».
Кевин Делдайк, бывший вице-президент по инженерным вопросам в Scaleway

Это типичный разговор, который мы ежедневно ведем с инженерами.

После моего последнего сообщения о «взломе ценообразования» некоторые из вас спросили меня, почему биллинг настолько сложен. Мой соучредитель Раффи взял на себя труд объяснить, почему эта проблема до сих пор не решена для инженеров.

Мы также собрали информацию от других друзей, которые прошли через тот же болезненный путь, включая Algolia, Segment, Pleo… не пропустите их! Передаем микрофон Раффи.

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

Затем вы можете задаться вопросом: стоит ли нам создавать эту систему своими силами? Это не выглядит сложным, и логика кажется специфичной для вашего бизнеса. Кроме того, вы, возможно, хотите сохранить свою драгоценную маржу и поэтому избегаете существующих биллинговых решений, таких как Stripe Billing или Chargebee, которые берут часть вашего дохода. Честно говоря, кому нравится такой подход «искателей ренты»?

Наша команда в Lago до сих пор хранит болезненные воспоминания о внутренней биллинговой системе Qonto, которую нам пришлось создавать и поддерживать. Почему это было так болезненно? В этой статье я расскажу о технических проблемах, с которыми мы столкнулись при внедрении гибридного ценообразования (на основе подписки и использования), и о том, чему мы научились во время этого пути.


TL;DR: Выставлять счета в 100 раз сложнее, чем вы думаете

«Давайте выставлять счета ежегодно, это будет довольно просто», — утверждает команда Revenue. Отлично! Все с нетерпением ждут начала работы над этим. Все, кроме технической команды. Когда вы начинаете создавать свою внутреннюю биллинговую систему, трудно представить себе все сложности, которые могут возникнуть в дальнейшем, если только вы не сталкивались с этим раньше.

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

В Qonto наши первые пользователи могли подключиться только к тарифному плану стоимостью 9 евро. Мы быстро решили добавить тарифные планы и функции «оплата по факту» (например, снятие денег в банкомате, платежи в иностранной валюте, депонирование капитала и т.д.), чтобы увеличить доход.

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

Это, конечно, не характерно для Qonto. Pleo, еще один финтех-единорог из Дании, столкнулся с аналогичными проблемами:

«Я научился ценить, что биллинговые системы сложно создавать, сложно проектировать и сложно заставить их работать на вас, если вы хоть на йоту отклоняетесь от «стандарта»».
Арнон Шимони, лидер по инфраструктуре биллинга в Pleo

Это даже не относится к финтех-компаниям. Команда Algolia в итоге создала целый отдел ценообразования, который теперь возглавляет Джай, ветеран ценообразования и монетизации из Twilio, VMWare, Service Now. Они перешли на модель ценообразования «оплата по факту», основанную на количестве ежемесячных поисков API.

«На бумаге это выглядит просто — однако, это сложная задача: довести автоматизацию и прозрачность до клиента, чтобы он мог легко понять. За этим стоит большая закулисная работа, и для того, чтобы сделать это правильно, требуется много инженерии и инвестиций».
Бернардетт Никсон, генеральный директор Venture Beat


#1 — Даты

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

Вот неполный список трудностей, с которыми сталкиваются инженеры:

  1. Как быть с високосными годами?
  2. Начинается ли ваша подписка с начала месяца или с даты создания клиента?
  3. Сколько дней/месяцев пробной версии вы предлагаете?
  4. Кто решил, что в феврале только 28 дней?
  5. Подождите, пункт 1 также важен для февраля…
  6. Как рассчитать плату за использование (цена за секунду, час, день)?
  7. Возобновлять ли потребление или складывать его месяц за месяцем? Год за годом?
  8. Применять ли пропорциональную ставку на основе количества дней, потребленных клиентом?

Хотя каждое решение обратимо, вопросы биллингового цикла часто являются самым важным источником тикетов поддержки клиентов, и итерации по ним довольно сложны. Например, Qonto перешел от «юбилейных» дат к календарным датам для своих биллинговых периодов (см. здесь). Это изменение не было тривиальным.


#2 — Обновление и понижение статуса

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

Что делать, когда пользователь:

  1. Обновляет или понижает тарифный план в середине периода;
  2. оплатил первоначальный тарифный план заранее;
  3. Должен оплатить первоначальный тарифный план с задолженностью;
  4. Переходит с годового плана на месячный;
  5. переходит с месячного плана на годовой;
  6. переходит с плана, оплаченного авансом, на план, оплаченный с задержкой (и наоборот); или
  7. Имеет скидку и обновления/понижения?

В то время у нас в Qonto не было бесплатного пробного периода, но Арнон из Pleo описывает эту ситуацию здесь.


#3 — Расчеты на основе использования

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

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

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

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

Ценообразование в Segment основано на количестве ежемесячно отслеживаемых пользователей. Это означает, что им необходимо подсчитывать количество пользователей каждый месяц и обнулять это значение для следующего расчетного периода. Чтобы получить количество уникальных посетителей, необходимо применить функцию ‘distinct’ для их дедупликации.

{
  "transaction_id": "2345",
  "timestamp": "2022-03-16",
  "event_type": "tracked_users",
  "properties": {
            "user_id": "123456789"
    }
}
Вход в полноэкранный режим Выход из полноэкранного режима
SELECT
    DATE_TRUNC('month', timestamp) AS month,
    COUNT(DISTINCT user_id) AS unique_users
FROM events
WHERE event_type = 'tracked_used'
GROUP BY month
Войти в полноэкранный режим Выход из полноэкранного режима

Algolia отслеживает количество поисков API в месяц. Это означает, что им необходимо суммировать количество ежемесячных поисков для каждого клиента и обнулить это значение для следующего расчетного периода.

{
  "transaction_id": "2345",
  "timestamp": "2022-03-16T00:00:00Z",
  "event_type": "searches",
  "properties": {
            "api_search": "1"
    }
}
Вход в полноэкранный режим Выход из полноэкранного режима
SELECT
    DATE_TRUNC('month', timestamp) AS month,
    SUM(api_search) AS monthly_searches
FROM events
WHERE event_type = 'searches'
GROUP BY month
Войти в полноэкранный режим Выход из полноэкранного режима

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

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

— Час 1: *10 КВт, использованных за 0,5 часа = 5 КВт (10 x 0,5)
*- Час 2: 20 КВт, использованных за 1 час = 20 КВт (20 x 1)
— Час 3: *0 КВт, использованных за 1 час = 0 КВт (0 x 1)
*- Час 4: 30 КВт использовано в течение 0,5 часа = 15 КВт (30 x 0,5)
— ИТОГО = 40 использованных КВт x $10 ⇒ $40


#4 — Идемпотентность, сделанная правильно

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

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

Это простой принцип проектирования, однако, поддерживать его в любое время очень сложно.


#5 — Дело для сотрудника по инкассации наличности

Инкассация — это процесс сбора денег, которые вам должны клиенты. Самым неприятным моментом в инкассации наличности является «dunning»: когда платежи не проходят, торговец должен упорно и настойчиво обращаться к своим клиентам с повторными просьбами об оплате, стараясь при этом не испортить отношения.

В Qonto мы называли это «ожидающими средствами». Статус клиента был «ожидание средств», когда он успешно прошел процесс регистрации, KYC и KYB, но баланс его счета все еще был равен 0.

Для необанка это имеет двоякий эффект: вы не можете взимать плату за услуги (например, за ежемесячную подписку), и ваш клиент не генерирует доход от межбанковской комиссии (например, когда вы совершаете платеж на сумму $100 с помощью своей карты, эмитент карты получает $0,5-$1 дохода от межбанковской комиссии через комиссию торговца).

Таким образом, два ваших основных потока доходов «нулевые», но вы платите за приобретение, привлечение, KYC пользователя, а затем за выпуск и отправку ему карты. Мы часто полушутя говорили о необходимости нанять «главного специалиста по ожиданию средств»: финансовые последствия этого столь же велики, сколь недооценена проблема.

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

  1. **логику повторного запроса **для запроса нового намерения платежа;
  2. Система сверки счетов (например, если взыскиваются платежи за несколько месяцев);
  3. логика приложения для отключения доступа к услуге; и
  4. рабочий процесс рассылки электронных писем, призывающий пользователя перейти к оплате.

Некоторые SaaS даже взяли на себя миссию борьбы с неплатежами и построили полноценные компании вокруг сбора наличности, например, Upflow, который используется успешными B2B-масштабируемыми компаниями, включая Front и Lattice.

«Отправка качественных и персонализированных напоминаний занимала у нас много времени, и, поскольку Lattice быстро росла, нам было необходимо масштабировать наши процессы сбора наличности. Мы используем Upflow, чтобы персонализировать то, как мы просим наших клиентов о деньгах, многократно, сохраняя при этом хорошие отношения. Теперь мы собираем 99% наших счетов без особых усилий».
Джейсон Лопес, контролер в Lattice


#6 — Лабиринт налогов и НДС

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

Теперь представьте, что вы продаете различные типы товаров/услуг различным типам клиентов в 100+ странах. Если на бумаге логика выглядит сложной, то инженерная задача усложняется в десять раз. Инженерам необходимо продумать целую логику налогообложения в рамках приложения. Эта пирамидальная логика основана на клиентах и продуктах, включая:

1. Налоги на уровне компании: у вашей компании будет общая налоговая ставка, которая по умолчанию применяется ко всем клиентам;
2. Налоги на уровне клиента: налоговая ставка по умолчанию может быть переопределена для каждого клиента в зависимости от вышеупомянутых параметров (см. иллюстрацию); и
3. Налоги на уровне функции: в основном это относится к банковской сфере. В Qonto, например, банковские комиссии не облагаются налогами, но ставка НДС 20% применяется к небанковским функциям.

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

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

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

Если вы заинтересованы, вы можете связаться с командой Lago или заглянуть в наш открытый репозиторий: https://github.com/getlago/lago.

Оцените статью
devanswers.ru
Добавить комментарий