Как «Логема» на платформе для работы с самозанятыми в 2 раза сократила ошибки в реестре выплат

Заказчик

Платформа для работы с самозанятыми (NDA)

Задача

Настроить интеграцию сервиса по API с банком. Оптимизировать проверку данных в реестре выплат самозанятым.

Сегодня бизнес активно привлекает самозанятых на конкретные проекты или для решения разовых задач, поэтому спрос на платформы и сервисы для такого взаимодействия растет. При этом многие компании, активно работающие с самозанятыми, сталкиваются с ограничениями существующих платформ: высокие комиссии (до 20% от платежа!), сложности с получением чеков от самозанятых для подтверждения факта оказанных услуг и снижения налоговой нагрузки. В результате все больше компаний-заказчиков принимают решение отказаться от использования сторонних платформ в пользу разработки собственных сервисов для найма самозанятых. Такой подход позволяет не только существенно снизить издержки за счет экономии на комиссиях, но и создать решение, адаптированное под особенности бизнес-процессов конкретной компании.

В 2022 году в компанию «Логема» за разработкой современного сервиса для работы с самозанятыми обратилось кадровое агентство. Требовалось автоматизировать документооборот между компанией-заказчиком и самозанятыми, наладить своевременное получение чеков от исполнителей, а также создать систему, учитывающую специфику внутренних процессов кадрового агентства.

Разработанная командой «Логемы» платформа полностью решила эти задачи, позволив клиенту экономить несколько сотен тысяч рублей в год на комиссиях. В этом кейсе мы расскажем про новый этап развития проекта — переход сбанка N на банк M через интеграцию по API.

Пара слов о задаче

Банк N, через который проводились выплаты, стал работать нестабильно: чтобы реестр выплат проводился без задержек, было решено интегрировать платформу с новым банком M. Для бизнеса сотня или тысяча выплат самозанятым в месяц — это критично.

Что такое реестр выплат?

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

• номер телефона (при оплате по СБП) или банковские реквизиты (при оплате на карту);
• ИНН для поиска нужного пользователя и отображения его ФИО на сайте;
• сумму выплаты;
• основание для перевода (например, выполненное задание или наименование услуги).

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

Спойлер: некоторые банки проверяют соответствие данных в реестре (номер телефона и ФИО) с данными в системе быстрых платежей; если данные не совпадают, выплата не проходит. Именно такая ситуация возникла и у нас с интеграцией по API банка M — об этом расскажем ниже.

С чем столкнулись разработчики «Логемы»? Главная проблема — техническая нестабильность. Сбой API банка N при проведении массовых выплат исполнителям создавал риск срыва сроков взаиморасчетов между самозанятыми и заказчиком.

Что требовалось от решения:

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

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

 

Екатерина Васильева, 

менеджер проектов в компании «Логема»

Процесс интеграции по API с банком M

Интеграция с новым банком потребовала комплексного подхода к решению задачи.

Обеспечили надежность выплат

На замену банку N клиент выбрал банк M, опираясь на предыдущий положительный опыт использования других площадок для найма самозанятых. До старта работ команда банка M организовала онлайн-встречу, чтобы убедиться, что мы правильно поняли их документацию. Специалисты «Логемы» разрабатывали решение строго по документации, проверяли работу вручную и с помощью автотестов. Но, когда пришло время переключить тестовую среду на боевую, при первой же проверке стало понятно — решение банка «сырое».

Преодолев технические сложности, мы смогли:

• реализовать оплату по Системе быстрых платежей (СБП); 
• разработать систему резервного переключения с банка N на банк M и обратно, чтобы повысить отказоустойчивость платформы.

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

Что такое система бенефициаров?

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

Эта система решает три ключевые задачи:

1. Учет поступлений — закрепление поступивших денег за владельцем;
2. Учет выплат — отражение актуального баланса всех участников (сама площадка, заказчик и исполнитель) и детализация всех транзакций на площадке;
3. Прозрачная отчетность — все участники площадки в любой момент видят свой текущий баланс на общем счете.
   
   

Оптимизировали проверку данных

В процессе работы с банком M мы столкнулись с более строгими требованиями к валидации данных исполнителей: требовалась валидация платежных данных самозанятых (телефона и ФИО владельца номера телефона). Банк сверяет эти данные между площадкой для найма самозанятых и Национальной системой платежных карт (НСПК).

У банка M требования к валидации строже, чем у банка N. В переходный период с банка N на банк M из-за строгих требований к валидации временно увеличилось количество отклоненных платежей.

Разработчики «Логемы» смогли реализовать процесс проверки данных до этапа оплаты самозанятым, чтобы уменьшить количество отклоненных выплат:

• предварительная валидация при загрузке реестра заданий заказчиком сразу выявляет ошибки заполнения этого реестра (например, заполнены не все данные или они заполнены некорректно) или тех исполнителей, которые еще не зарегистрировались на площадке;
• автоматическая проверка актуального статуса самозанятого через ФНС.

Клиент получил систему с более предсказуемой работой банковского API: банк М стал заранее информировать о технических работах и потенциальных проблемах. Кроме того, на платформе для работы с самозанятыми появилась возможность заранее информировать исполнителей о необходимости актуализировать данные (ФИО, статус самозанятого или номер телефона), что сделало процесс более прозрачным для всех участников.

“Одним из важных улучшений стала коммуникация с банком: сейчас менеджер банка М рассылает предупреждения о планируемых технических работах и возможных перебоях. Такой подход позволил заранее планировать проведение крупных реестров выплат.“

 

Екатерина Васильева, 

менеджер проектов в компании «Логема»

Результат

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

В текущем проекте переход на новую систему с банком M значительно улучшил ключевые показатели:

• время ответа техподдержки сократилось с 2 суток до 2 часов; 
• процент ошибок в реестрах выплат снизился с 13% до 7%;
• пропали реестры, в которых не прошла ни одна оплата.

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

На переход с банка N на банк M ушло 760 часов: 

• обновление инфраструктуры и настройка API — 171 час;
• разработка системы бенефициаров — 160 часов;
• интеграция с банковским API — 114 часов;
• тестирование и перенос данных — 115 часов;
• фронтенд-разработка — 40 часов;
• регистрация и проверка самозанятых и выбивание чеков – 160 часов.

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