BNPL (Buy Now, Pay Later) — одна из самых быстрорастущих ниш в fintech. Но за простым пользовательским опытом «раздели оплату на 4 части» скрывается сложная техническая инфраструктура: скоринговые модели, antifraud, real-time лимиты и глубокие банковские интеграции.
Ядро любой BNPL-системы — скоринговый движок. На первом этапе можно использовать простые правила: история платежей, средний чек, частота покупок. Но для масштабирования нужна ML-модель, которая учитывает сотни сигналов: поведение в приложении, источник трафика, время суток, геолокацию. Правило первое: никогда не храните скоринговую логику в монолите — выносите в отдельный сервис со своим API.
Antifraud — отдельный зверь. Самые опасные схемы в BNPL: заявки с чужими данными, массовые отказы и повторные попытки, координированные мошеннические группы. Против первой схемы помогает верификация через банковские API и SMS-OTP. Против второй — rate limiting и device fingerprinting. Против третьей — граф-анализ связей между аккаунтами.
Интеграция с банками — самый болезненный этап. В СНГ банки работают через разные протоколы: кто-то даёт REST API, кто-то требует SFTP с CSV-файлами, кто-то работает только через Host-to-Host. Закладывайте на каждую банковскую интеграцию минимум 6–8 недель и не забудьте про тестовую среду — у большинства банков она либо нестабильна, либо отсутствует.
Главные архитектурные ошибки при построении BNPL: синхронные вызовы в критическом пути выдачи лимита, отсутствие idempotency keys в транзакциях, хранение балансов в одной таблице без партиционирования. И главное — никогда не делайте BNPL монолитом. Event-driven архитектура с Kafka или RabbitMQ — ваш лучший друг.
Расскажите о задаче — получите развёрнутое предложение в течение 24 часов.