Интеграция 1С-Битрикс с платёжной системой Расчёт (ЕРИП) (Беларусь)
«Расчёт» — это торговое наименование системы ЕРИП, используемое в контексте розничных платежей. Часть банков и платёжных сервисов Беларуси предоставляет доступ к ЕРИП именно под брендом «Расчёт», и для разработчика важно понимать: на техническом уровне это тот же ЕРИП (Единое расчётное и информационное пространство), просто с другой точкой входа и API от конкретного банка-агента. Путаница в терминологии часто приводит к тому, что один магазин подключает «Расчёт» и «ЕРИП» как два разных способа оплаты, хотя они ведут в одну инфраструктуру.
Принципиальное отличие от других платёжных систем
ЕРИП/Расчёт — это не карточный шлюз. Покупатель не вводит данные карты на сайте. Вместо этого:
- Магазин выставляет счёт в ЕРИП через API банка
- Покупатель получает уникальный номер (код) счёта
- Оплачивает через любой банк, привязанный к ЕРИП: Беларусбанк, Приорбанк, Альфа-Банк, МТБанк, БелВЭБ и другие — через интернет-банкинг, мобильный банк, банкомат или кассу
- Информация об оплате поступает в магазин через webhook
Ключевой момент: сервис «Расчёт» предполагает, что покупатель ищет ваш магазин в дереве услуг ЕРИП. Для этого у компании должен быть зарегистрирован код услуги в дереве ЕРИП. Без этого кода система выставленных счетов работать не будет.
Подключение через банк-агент
Прямого API у ЕРИП/Расчёт нет. Взаимодействие идёт через банк, в котором открыт расчётный счёт компании. Каждый банк предоставляет свой протокол:
| Банк | Протокол | Особенности |
|---|---|---|
| Беларусбанк | SOAP/XML | Детальная документация |
| Приорбанк | REST JSON | Современный API |
| МТБанк | REST JSON | Быстрый onboarding |
| Альфа-Банк | REST JSON | Поддержка QR |
| БелВЭБ | REST/XML | Корпоративные клиенты |
При разработке обработчика для Битрикс выбор протокола определяется банком клиента. Если планируется смена банка — обработчик придётся адаптировать.
Реализация в Битрикс
Размещение: /local/php_interface/include/sale_payment/raschyot_erip/
Базовая логика initiatePay (на примере REST-протокола):
public function initiatePay($payment, $request = null)
{
$order = $payment->getOrder();
$billData = [
'merchantId' => $this->getParam('MERCHANT_ID'),
'serviceCode' => $this->getParam('SERVICE_CODE'),
'invoiceNo' => $order->getField('ACCOUNT_NUMBER'),
'amount' => $payment->getSum(),
'currency' => 'BYN',
'description' => 'Заказ ' . $order->getField('ACCOUNT_NUMBER'),
'expireDate' => date('Y-m-d', strtotime('+3 days')),
'callbackUrl' => $this->getCallbackUrl(),
];
$response = $this->sendRequest('POST', '/invoices', $billData);
if ($response['status'] === 'created') {
$payment->setField('PAY_SYSTEM_ID_EXTERNAL', $response['invoiceId']);
$this->showEripRequisites($response['invoiceId'], $response['eripCode']);
}
}
Отображение реквизитов ЕРИП
Покупателю нужно показать чёткую инструкцию. Разные сегменты аудитории используют разные каналы:
- Интернет-банкинг: ЕРИП → Поиск → Ввести код счёта или найти через дерево услуг
- Мобильное приложение: QR-сканирование
- Банкомат/инфокиоск: ЕРИП → ваша услуга → ввести номер заказа
- Касса банка: назвать кассиру код услуги и номер заказа
Шаблон платёжной системы в Битрикс должен показывать все варианты, а не только один — это снижает количество обращений в поддержку.
Статусы и логика подтверждения
Возможные статусы счёта в ЕРИП:
| Статус | Значение | Действие в Битрикс |
|---|---|---|
CREATED |
Счёт выставлен | Ожидать |
PAID |
Оплачен | $payment->setPaid('Y') |
PART_PAID |
Частично оплачен | Уведомить менеджера |
EXPIRED |
Истёк срок | Отменить или продлить |
CANCELLED |
Отменён магазином | Обновить статус |
Частичная оплата в ЕРИП допустима по умолчанию — если её не нужно принимать, явно указывать в запросе создания счёта (partialPayment: false).
Двойная регистрация: типичная ошибка
Магазин создаёт счёт в ЕРИП, покупатель не платит. Покупатель возвращается, нажимает «Оплатить снова» — магазин создаёт второй счёт. Теперь два активных счёта на один заказ. Покупатель оплачивает один, второй висит активным. Через три дня оба истекают — и база засоряется.
Решение: перед созданием счёта проверять, нет ли уже активного счёта по этому заказу (хранить invoiceId в полях платежа b_sale_payment). Если есть — показывать его реквизиты, а не создавать новый.
Реальный кейс: регистрация в дереве ЕРИП
Минский розничный магазин бытовой химии. Техническая интеграция заняла 3 дня, но запуск задержался на 3 недели — компания не знала, что регистрация кода услуги в дереве ЕРИП — отдельный административный процесс через банк и НКФО «Расчёт». Документы, согласования, тестирование дерева. Рекомендация: начинать регистрацию в ЕРИП параллельно с разработкой, а не после неё.