Архитектура финтех-приложения: платежи, данные, роли и интеграции

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

Для финансового продукта мобильный интерфейс - только один из контуров. Рядом обычно находятся backend, внутренние системы компании, банковские или платежные сервисы, проверка пользователя, уведомления и инструменты поддержки. Точный состав зависит от бизнес-модели и доступных интеграций.

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

Начните с границ продукта и движения операции

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

• кто является пользователем и от чьего имени он действует;
• какую задачу решает клиентское приложение, а за что отвечает backend;
• какие внутренние и внешние организации участвуют в операции;
• в какой системе создается и меняется финансовый статус;
• какие действия доступны пользователю и сотрудникам поддержки;
• какие ограничения, проверки и исключения меняют ход сценария.

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

Смоделируйте платежный сценарий как последовательность состояний

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

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

Разделите данные, роли и полномочия

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

Составьте таблицу ролей и действий: клиент, оператор поддержки, администратор и сервисная учетная запись. Для каждого действия укажите, кто может его выполнить, при каких условиях, что фиксируется в журнале и кто разбирает спорный случай. В качестве карты рисков для API можно использовать OWASP API Security Top 10; это справочник классов рисков, а не подтверждение соответствия продукта требованиям.

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

Опишите интеграции и поведение при сбоях

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

• какие запросы и события передаются в каждую сторону;
• какие форматы данных и версии API поддерживаются;
• как обрабатываются задержки, тайм-ауты и временная недоступность;
• как различаются безопасный повтор, отмена и повторная попытка;
• кто получает уведомление об ошибке и как операция восстанавливается;
• как контролируются изменения внешнего API.

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

Выберите серверную структуру под реальные границы

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

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

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

Что можно увидеть в опубликованных проектах L-TECH

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

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

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

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

Что включить в первый релиз

Чтобы оценка была предметной, опишите не только желаемые функции, но и границы первого этапа:

• один или несколько приоритетных пользовательских сценариев;
• роли и полномочия пользователей и сотрудников;
• платформы и устройства, которые нужно поддержать;
• участвующие системы и документацию по их API;
• состояния операции, ошибки и правила восстановления;
• требования к безопасности, журналированию и поддержке;
• критерии приемки, исключения и зависимости от заказчика.

Если часть сведений пока неизвестна, отметьте это как открытый вопрос. Так подрядчик сможет отделить подтвержденный объем от допущений и предложить этап уточнения, а не скрывать неопределенность внутри общей оценки.

С чего начать обсуждение проекта

Для предварительного разговора подготовьте описание продукта, схему одного важного сценария, список внешних систем и уже доступные документы по API. Затем можно определить, какие вопросы влияют на архитектуру, состав работ и последовательность релизов.

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

Частые вопросы

Можно ли начать с одного платежного сценария?

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

Нужны ли микросервисы финтех-приложению?

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

Какие материалы нужны для оценки?

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