Финтех платформы и платёжная инфраструктура: опыт разработки и эксплуатации

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

Чем финтех отличается от обычной разработки

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

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

Архитектура платёжного контура

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

Базовый слой — ядро баланса и проводок (ledger). Это источник правды о деньгах, реализованный по принципу двойной записи: любое движение средств отражается парой проводок, а сумма по счёту всегда выводится из истории операций, а не хранится отдельным «изменяемым» числом. Такой подход исключает ситуацию, когда баланс «разъехался» с историей и непонятно, какому значению верить.

Над ядром — слой оркестрации платежей: он управляет жизненным циклом транзакции (создан → ожидает подтверждения → проведён / отклонён / возвращён) и общается с внешними провайдерами. Здесь живёт логика ретраев, таймаутов и обработки вебхуков. Отдельно стоит интеграционный слой с конкретными платёжными системами — в Узбекистане это типично Click, Payme, Uzum, а также эквайринг банков и работа с НСПК/локальными картами. Каждый провайдер выносится за единый внутренний интерфейс, чтобы добавление нового метода не требовало переписывать ядро.

Интеграция с платёжными провайдерами

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

• Вебхуки обрабатываются идемпотентно — повторное уведомление об одном и том же платеже не меняет состояние второй раз.
• Активная сверка — система не ждёт пассивно вебхук, а сама опрашивает статус «зависших» операций по таймауту и через периодический reconcile-процесс.
• Подпись и проверка подлинности каждого входящего запроса от провайдера — обязательны, как и фиксация сырого тела запроса для последующего разбора.
• Разделение методов по гео и доступности — список доступных способов оплаты должен корректно вести себя, когда часть провайдеров недоступна, а не показывать пользователю единственный нерабочий вариант.

Эксплуатация: что начинается после запуска

Запуск платёжной системы — это не финал, а начало самой ответственной фазы. Эксплуатация финтеха отличается тем, что многие проблемы невидимы «изнутри»: API отвечает 200, дашборд зелёный, а приём данных или платежей по факту остановился. Поэтому мониторинг строится не вокруг «сервис жив», а вокруг бизнес-метрик: сколько успешных платежей в минуту, какова доля отказов по каждому методу, есть ли необъяснимый провал по конкретному провайдеру.

Из реальной практики: важно отличать нормальный фон отказов от поломки. Часть методов оплаты даёт высокий процент «неуспешных» транзакций просто потому, что пользователи сами отменяют операцию или закрывают форму — это норма, а не дефект интеграции. Если такой фон не понимать, команда тратит силы на «починку» того, что работает. И наоборот — внезапное падение успешных вставок при формально живом API должно подниматься алертом немедленно, потому что именно так выглядит реальный простой приёма платежей.

Отдельная дисциплина — обращение с деньгами в коде эксплуатации. Любая правка биллинга на проде сопровождается бэкапом, проверкой синтаксиса и тестом вставки в транзакции с откатом до релиза. Тестовые аккаунты исключаются из отчётов о выручке, чтобы E2E-проверки платежей не раздували бизнес-метрики. Сверка кассы или CRM с данными ОФД и банка делается регулярно — именно она ловит расхождения вроде «платёж прошёл другим типом» или «сдвиг даты на следующий день».

Безопасность и соответствие требованиям

Финтех работает в регулируемом поле. В Узбекистане это требования по локализации и хранению персональных данных, правила работы с платёжными системами и банками-эквайерами, а на международном уровне — стандарт PCI DSS при работе с картами. Практический вывод для бизнеса: чувствительные данные карт по возможности не должны попадать в ваш контур вообще — токенизация и вынос ввода карты на сторону сертифицированного провайдера резко снижают зону ответственности и стоимость аудита.

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