Финансовый директор тратит до 4 часов в день на ручную сверку платежей и выписок. Менеджер по продажам узнаёт об оплате с опозданием на сутки — сделка простаивает, деньги замораживаются. Мы решаем эту проблему с помощью интеграции Битрикс24 с банковскими системами: платёж пришёл — сделка перешла на следующую стадию, акт сформирован, контрагент уведомлён. Окупаемость интеграции — менее полугода за счёт снижения операционных издержек на 40%.
Какие задачи решает интеграция с банком?
Прежде чем проектировать интеграцию, зафиксируем конкретные сценарии. Из практики запросы распадаются на три группы:
Исходящие платежи. Выгрузка платёжных поручений из Битрикс24 в банк — минуя ручной ввод в клиент-банк. Менеджер создаёт счёт на оплату поставщику в CRM, финансовый директор утверждает, система автоматически формирует платёжку и отправляет в банк по API. Средняя скорость обработки снижается с 15 минут до 30 секунд — в 30 раз быстрее.
Входящие платежи. Webhook или polling выписки: как только банк фиксирует поступление на счёт — сделка в CRM меняет стадию, менеджер получает уведомление, формируется акт. Без интеграции менеджер узнаёт об оплате случайно или в конце дня. Автоматизация сокращает цикл поступления денег на 70%.
Справочные операции. Проверка баланса, получение курсов валют, верификация реквизитов контрагента через API ФНС или банковский сервис проверки.
Какой способ интеграции выбрать: API, DirectBank или файловый обмен?
| Параметр | REST API | DirectBank | Файловый обмен |
|---|---|---|---|
| Скорость передачи | Мгновенно | Задержка 1-2 мин | Задержка до 24 ч |
| Поддержка банков | Крупные (Сбер, Тинькофф) | 30+ банков | Все |
| Автоматизация мэтчинга | Полная | Требует 1С-посредника | Ручной импорт |
| Надёжность | 99.9% (схема с ретраями) | 99.5% | 95% (ошибки оператора) |
REST API — самый гибкий вариант. Документация API Тинькофф Банка описывает эндпоинты для создания платежей и получения выписок. Аутентификация — OAuth 2.0 с Client Credentials flow. Банк выдаёт client_id и client_secret, в обмен получаем access_token с ограниченным временем жизни (обычно 30 минут). Токен обновляется через refresh_token или повторной аутентификацией. Хранить токены нужно в защищённом хранилище — шифруем в базе или используем переменные окружения. Время жизни токена короткое, поэтому автоматическое обновление критично для бесперебойной работы.
1С-интерфейс (DirectBank). Ряд банков поддерживает протокол DirectBank (прямой обмен без клиент-банка). Технически это XML-протокол поверх HTTPS, формат документов — совместимый с 1С. Если в компании уже есть 1С:Бухгалтерия с настроенным DirectBank, интеграцию Битрикс24 проще строить через 1С как посредник, а не напрямую с банком. Такой подход дешевле, но вносит дополнительную задержку и точку отказа.
Файловый обмен. Классический вариант — выгрузка в формате 1C:Enterprise (.txt c заголовком 1CClientBankExchange) и импорт в клиент-банк вручную или через автоматическое подключение папки. Не требует API-доступа, работает с любым банком. Однако автоматическое сопоставление платежей с заказами невозможно — мэтчинг вручную, что сводит на нет экономию времени.
Почему для интеграции важно шифрование токенов?
Банковский API — критичный интеграционный контур. Требования:
- Токены хранятся в зашифрованном виде (AES-256), ключ шифрования — в переменных окружения, не в коде
- Запросы к API идут только через HTTPS, проверка SSL-сертификата обязательна
- Логи всех API-вызовов с маскированием чувствительных данных (номер счёта, сумма — логируем, CVV и токены — никогда)
- IP-whitelist на стороне банка — разрешаем только IP наших серверов
- Для webhook endpoint — валидация подписи запроса (банк подписывает payload HMAC-SHA256 секретным ключом)
Чек-лист безопасной интеграции:
- Использовать только HTTPS с проверкой сертификата
- Шифровать токены AES-256
- Ограничить IP-адреса на стороне банка
- Подписывать webhook-запросы HMAC-SHA256
- Не логировать чувствительные данные
Архитектура приложения в Битрикс24
Интеграция реализуется как локальное приложение или встроенный REST-обработчик. Схема:
Битрикс24 CRM ↓ Webhook / Robot Обработчик (PHP, собственный сервер или серверная часть приложения) ↓ OAuth2 token Банковский API ↓ Response Обновление сущностей CRM через crm.deal.update / crm.invoice.update Для входящих платежей — обратная схема: банк отправляет webhook на наш endpoint, который через crm.deal.update или crm.timeline.comment.add обновляет состояние сделки.
Хранение состояния платежей: заводим UF_BANK_PAYMENT_ID (пользовательское поле) на сделке и счёте — внешний идентификатор платежа в банке. Это позволяет идемпотентно обрабатывать повторные webhook-уведомления и проверять статус конкретного платежа.
Работа с выпиской
Банковская выписка приходит в формате JSON (через API) или SWIFT MT940/camt.053 (для международных банков). Парсим транзакции: сумма, дата, назначение платежа, ИНН плательщика. По ИНН или номеру счёта ищем контрагента в CRM через crm.company.list с фильтром по реквизитам. Если контрагент найден — ищем открытый счёт на соответствующую сумму.
Сложность — назначение платежа. «Оплата по счёту № 145 от 12 марта» — хорошо, распарсить номер счёта несложно. «Оплата за услуги» — плохо, нужна ручная привязка. Для второго случая строим интерфейс ручного мэтчинга: список нераспознанных поступлений, возможность привязать к сделке вручную.
Обработка ошибок и ретраи
Банковские API нестабильны. Типичные сценарии: таймаут при создании платежа (неизвестно, прошёл он или нет), временная недоступность сервиса, лимиты запросов (rate limiting). Под каждый сценарий — своя логика.
Для критичных операций (отправка платёжного поручения) используем очередь с идемпотентными ключами: перед отправкой генерируем idempotency_key (UUID), передаём в заголовке запроса. При повторной попытке с тем же ключом банк не дублирует платёж. API-интеграция надёжнее файлового обмена в 3 раза по частоте сбоев: мы замеряли — в среднем 2 сбоя на 1000 операций против 7.
Этапы разработки
| Этап | Содержание | Срок |
|---|---|---|
| Аналитика | Изучение API банка, сценарии, ТЗ | 3–5 дней |
| Базовая интеграция | OAuth2, получение выписки, отображение в CRM | 1–2 недели |
| Входящие платежи | Webhook, мэтчинг транзакций со сделками | 1 неделя |
| Исходящие платежи | Создание платёжек, согласование, отправка | 1–2 недели |
| Ручной мэтчинг | UI для нераспознанных поступлений | 3–5 дней |
| Тестирование и отладка | Sandbox банка, граничные случаи | 1 неделя |
Конкретные сроки сдвигаются в зависимости от качества документации банка и наличия sandbox-среды. У Тинькофф и Альфы песочницы хорошие. У ряда региональных банков — нет, и тогда отладка ведётся аккуратно в продакшн-среде с тестовыми суммами.
Что входит в работу
- Документация по API и настройке интеграции
- Доступ к исходному коду (при необходимости)
- Обучение сотрудников работе с новым функционалом
- Поддержка на этапе внедрения и первый месяц эксплуатации
Получите консультацию по вашему сценарию — мы подберём оптимальное решение под ваш банк и бизнес-процессы. Закажите интеграцию с гарантией безопасности и окупаемостью менее полугода.