Финтех — отрасль, где инженерия проверяется деньгами. Зависший платёж, двойное списание, отчёт, не сошедшийся со сверкой банка, — это прямые потери и подорванное доверие, которые не вернуть косметическим релизом. Поэтому разработка для финтеха начинается не с интерфейсов, а с контрактов: что система обязуется сделать с деньгами, что происходит при сбое на каждом шаге и как это доказать аудитору.
Специфика финтеха
Платежи — ядро со своей физикой. Деньги не терпят «примерно». Каждая операция проектируется идемпотентной: повторный запрос из-за обрыва сети или повторная отправка формы не приводят к двойному списанию. Распределённые цепочки — списание, зачисление, комиссия, уведомление — собираются по схеме саги с компенсациями: любой шаг может отказать, и система возвращается в согласованное состояние без ручного разбора. Журнал операций дописывается событиями и не переписывается задним числом — он и есть версия правды для сверок и разбора инцидентов.
Регуляторика — часть архитектуры, а не документ после запуска. Персональные данные и границы их передачи, требования банков-партнёров и платёжных систем, стандарт PCI DSS при работе с картами — всё это ложится на структуру системы. Где физически лежат данные, кто и к чему имеет доступ, как фиксируются действия — ответы на эти вопросы зашиты в саму платформу. Аудит в финтехе — не разовое событие перед сделкой, а режим работы: воспроизводимость окружений, прослеживаемость операций и история изменений конфигураций существуют в платформе по умолчанию.
Интеграции с банками и эквайрингом. REST- и SOAP-интерфейсы, файловые обмены, форматы выписок, электронная подпись, песочницы, которые ведут себя иначе, чем продакшн, — финтех редко контролирует обе стороны интеграции. Поэтому обязательны ограниченные повторные попытки, согласованные статусы операций и регулярная сверка как встроенный процесс, а не пожарная процедура.
Требования к надёжности. Доступность платёжного контура конвертируется в деньги напрямую: минута простоя — это неоплаченные заказы клиентов и репутационная цена. Отказоустойчивость проектируется и проверяется, а не декларируется: изоляция контуров, режимы деградации, отрепетированные откаты. Режим деградации продумывается заранее: что отключаем первым, что остаётся последним и куда платёж попадает в очередь, когда партнёр недоступен.
Что болит
Безопасность по остаточному принципу: секреты в конфигурационных файлах, права доступа «по знакомству», отсутствие журнала «кто, что и когда сделал». Пока инцидента не было, это кажется экономией — после инцидента ценой становится сама лицензия или договор с банком.
Нагрузка транзакций идёт волнами: зарплатные дни, списания по расписанию, массовые возвраты после сбоя партнёра. Очереди растут, таймауты каскадируются, а повторные запросы внешних систем превращаются в дубли операций.
Соответствие как проект «к дате»: к аудиту готовятся внезапно, документация отстаёт от реальности на полгода, окружения невоспроизводимы — и проверка превращается в археологию по чатам и логам.
Мониторинг зелёный, а деньги потерялись: метрики здоровья контейнеров есть, сквозной трассировки платежа нет, и место разрыва ищут вручную по логам трёх систем.
Наследие быстрого прототипа, который стал продакшном: самописный шлюз, державшийся на энтузиазме первых разработчиков. Он работает, пока его не трогают, но любое изменение превращается в археологию, а о сбое первыми узнают пользователи, а не мониторинг.
Как мы подходим
Инженерная дисциплина вместо обещаний. Контракты API фиксируются до написания кода; идемпотентность, саги и событийный журнал закладываются в ядро, а не прикручиваются после первого двойного списания. Значимые решения описываются записями архитектурных решений — с контекстом и альтернативами, чтобы через год не вспоминать, почему шлюз устроен именно так. Каждая внешняя зависимость — банк, эквайринг, партнёр по выплатам — описывается контрактом с таймаутами, лимитами повторов и поведением при недоступности: платёжный контур не может «повиснуть в надежде».
Инфраструктура и её сопровождение. Воспроизводимые окружения, разграничение прав, управление секретами и журнал изменений — кто, что и когда выкатил — живут в конфигурации платформы, а не в памяти одного инженера. Регулярные обновления с канареечными проверками становятся рутиной, а не событием, которого боятся.
Наблюдаемость каждого перевода. Сквозная трассировка платёжной цепочки, сверка как автоматический тест, алерты с владельцем и процедурой реакции. Разрыв в платёжном контуре должна находить система, а не жалоба клиента.
Этапность вместо большого взрыва. Работа начинается с аудита платёжного контура: потоки операций, точки отказа, требования регуляторов и партнёров. Затем план миграции обратимыми шагами: пилотный сценарий, параллельный запуск, контрольные сверки на каждом этапе. Продакшн не останавливается, откат — заранее отрепетированная процедура, и решение о следующем шаге принимается по данным, а не по ощущениям.
Релевантные услуги для финтеха собираются автоматически из каталога ниже — связь «отрасль ↔ услуга» поддерживается в данных, а не вручную.