Разработка финтех-приложений

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

Flutter подходит для финтеха, потому что рисует интерфейс сам. Кастомный график, дашборд портфеля или список операций ведут себя одинаково на iOS и Android из одной кодовой базы — примерно на 30–40% дешевле, чем делать тот же продукт дважды нативно. То, что напрямую касается платформы, — аппаратное хранение ключей, платёжные шторки, часть KYC-SDK — идёт через platform channels: это рутина, но это реальная работа.

Какие продукты мы делаем

• Инвестиционные и торговые приложения — портфели, списки наблюдения, заявки и экраны с графиками, которые не тормозят при живых котировках
• Необанки и банковские клиенты — счета, переводы, выписки, управление картами и онбординг со сканированием документов
• Платёжные продукты и кошельки — оплата, история операций, регулярные платежи и нативные платёжные шторки
• Личные финансы и кэшбэк — агрегация, категоризация и механика вознаграждений, как в кэшбэк-платформе, которую мы построили
• Иншуртех — расчёт стоимости страховки, оформление страховых случаев и управление полисами, где пайплайн документов и фото важнее дашборда

Кто будет делать ваше финтех-приложение

Команду, которая может сделать финансовое приложение, от команды, которая делала просто приложения, отличают две вещи.

Платёжная инфраструктура, проверенная на масштабе

Nerdy Production возглавляет Илья Никсан, ранее CTO QIWI — одной из крупнейших платёжных платформ на своём рынке, где он руководил примерно 12 инженерными командами: от веб-продуктов до карточного процессинга, зоны PCI-DSS и бесконтактных платежей. Он построил бесконтактную оплату картой на Android через Host Card Emulation поверх ISO/IEC 14443, с платёжным протоколом EMV Contactless (Visa PayWave), и выпустил NFC-оплату картой примерно за год до того, как на рынке появился собственный Android Pay от Google. Он также был архитектором терминала Evotor — устройства на форкнутом AOSP, работающего на кассах в продакшене.

Что это значит для вас: человек, который ведёт вашу разработку, эксплуатировал регулируемую платёжную инфраструктуру, отвечал за зону PCI-DSS и выпускал card-present сценарии оплаты, а не просто писал приложения, вызывающие платёжное API.

Финтех-продукт, уже опубликованный в обоих сторах

Мы сделали ExtraETF для Isarvest GmbH в 2022 году — инвестиционное приложение на Flutter с бэкендом на Go: рыночные данные в реальном времени, интерактивные графики и учёт портфеля, опубликованное в App Store и Google Play. Технический разбор — в статье Как мы делали финтех-приложение реального времени на Flutter и Go, включая веерную рассылку по WebSocket, которая держит поток котировок, не перегружая клиент.

Что на самом деле требуют финтех-приложения

В каждом финансовом проекте возникают пять задач. Вот как мы решаем каждую.

Рыночные и транзакционные данные в реальном времени

Цены, балансы и статусы заявок меняются непрерывно, и интерфейс должен это переваривать, не роняя кадры и не теряя позицию скролла. В ExtraETF решением стал сервис на Go, раздающий рыночные данные через WebSocket, вместе с клиентом, который сужает перестройки до реально изменившейся серии. Наивная реализация — перестраивать поддерево виджетов на каждом тике — это ровно то, из-за чего экраны с графиками дёргаются на среднем Android-железе.

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

Безопасность и комплаенс

У нас нет сертификации PCI-DSS или SOC 2, и если агентство намекает на обратное — вам что-то продают. Что мы действительно делаем — строим так, чтобы ваша сертификация была достижимой, а не переписыванием с нуля:

• Учётные данные в iOS Keychain и Android Keystore, а не в shared preferences
• TLS с пиннингом сертификатов и планом ротации, который не ломает старые клиенты
• Биометрия и код-пароль на чувствительных действиях, а не только при запуске
• Шифрование локального хранилища для всего, что кэшируется на устройстве
• Никаких персональных и финансовых данных в логах, крэш-репортах и аналитике
• Карточные данные вне зоны вашего приложения везде, где это позволяет SDK провайдера

Архитектурные ограничения, которые накладывают PCI-DSS, GDPR, SOC 2 и KYC/AML, — это решения, которые принимают заранее или оплачивают потом; ровно этот опыт наш основатель вынес из карточного процессинга. На практике это значит решить заранее, каких данных ваше приложение вообще имеет право касаться: ввод карты отдан SDK провайдера, чтобы сырой PAN не доходил до вашего кода; персональные данные разделены так, чтобы запрос на удаление по GDPR был запросом к базе, а не археологией; журнал аудита спроектирован вместе с функцией, а не прикручен, когда его впервые попросят. Архитектуру, которой мы придерживаемся, и места, где она незаметно ломается, разбирает наш материал про шифрование в мобильных приложениях.

Точная денежная арифметика

Деньги никогда не бывают числом с плавающей точкой. В IEEE 754 0.1 + 0.2 не равно 0.3, и в финансовом приложении эта ошибка округления вырастает в несошедшуюся сверку. Мы храним суммы целыми числами в наименьших единицах валюты — в копейках, а не в рублях — или используем decimal-тип, а правила округления держим явными и покрытыми тестами на каждой границе — отображение, API, хранилище. Подробный разбор — в статье Почему 0.1 + 0.2 ≠ 0.3.

Платежи, подписки и доступы

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

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

Производительность и надёжность

У пользователей финансовых приложений низкая терпимость к спиннеру там, где должен быть баланс. Это значит 60fps на экранах с графиками — на реальных устройствах, а не на флагманских симуляторах, offline-first, чтобы кэш отрисовывался мгновенно, пока грузятся свежие данные, и состояния ошибок, которые говорят, что произошло, вместо тихого показа устаревшей цифры. Вопрос «когда это число было верным в последний раз?» мы считаем полноценной частью состояния интерфейса и тестируем на среднем Android-железе, которое реально в руках у ваших пользователей.

Почему Flutter для финтеха

Честный аргумент за Flutter здесь:

Экономия здесь — не скидка на инженерию, а снятие дублирующей работы: один набор бизнес-правил, одна логика форматирования денег, один набор экранов, которые тестируют дважды, а не строят дважды.

Где нативная разработка всё ещё выигрывает: если ваш продукт по сути тонкая обёртка вокруг платформенной возможности — глубокая интеграция с Apple Wallet или card-present NFC-сценарий, завязанный на стек одной платформы, — преимущество кроссплатформенности схлопывается, и честным ответом может быть нативная разработка. Мы скажем, если это ваш случай. Общая страница услуги — разработка на Flutter.

Как мы работаем

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

Staff augmentation. Наши инженеры входят в вашу команду, в ваш репозиторий и спринты, под ваше управление. Подходит, когда инженерное руководство уже есть и нужна мощность на Flutter — см. расширение команды и наш гайд по найму Flutter-разработчиков, который честно говорит и о том, когда нас брать не стоит.

В обоих случаях смету под задачу мы присылаем за два рабочих дня после того, как поймём требования.

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

Что чаще всего спрашивают команды, которые строят финансовые продукты на Flutter.

Разбор стоимости — в статье Стоимость разработки Flutter-приложения в 2026 году, а посмотреть, как выглядит выпущенный финтех-продукт на Flutter, можно в кейсе ExtraETF.