Подключение оплаты ЕРИП (Расчёт) к 1С-Битрикс

Оплата через ЕРИП ломается на этапе подтверждения заказа

Чаще всего сбой проявляется так: клиент оплачивает заказ через ЕРИП, деньги уходят, а в личном кабинете заказ так и висит в статусе «ожидает оплаты». Менеджер видит неоплаченный заказ, звонит клиенту, тот присылает чек — и только тогда выясняется, что оплата прошла. Причина почти всегда в том, что интеграция 1С-Битрикс с ЕРИП настроена на приём платежа, но не на его подтверждение: система не получает или неверно обрабатывает уведомление банка о статусе операции.

Второй типовой сбой — дублирование счетов. При повторном обращении к оплате (обновление страницы, возврат из ЕРИП, повторный клик) система создаёт новый счёт на тот же заказ, и в банк уходят два платежа с разными номерами. Клиент оплачивает один, второй остаётся висеть, а сверка в конце дня не сходится: бухгалтерия тратит часы на ручной поиск соответствий между заказами и выпиской.

Третий сбой — потеря уведомлений банка. Если обработчик подтверждения оплаты не отвечает вовремя или падает с ошибкой, банк повторяет уведомление, но не бесконечно. После исчерпания попыток платёж остаётся без статуса, и заказ «застревает» навсегда. Здесь важна идемпотентность: повторное уведомление с тем же идентификатором не должно создавать новый платёж или менять уже подтверждённый статус.

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

Что даёт корректная интеграция 1С-Битрикс с ЕРИП

Корректная интеграция 1С-Битрикс с ЕРИП убирает главный источник ручной работы в интернет-магазине — разбор платежей «глазами». Когда оплата приходит в систему автоматически, заказ переходит в статус «оплачен» без участия оператора: доля заказов, подтверждённых без человека, выходит на 95–98%, а время зачисления в статусе заказа сокращается с часов до 1–3 минут после подтверждения платежа банком.

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

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

Для заказчика интеграция 1С-Битрикс с ЕРИП — это предсказуемая нагрузка на операторов: чем больше заказов, тем меньше доля ручных операций на каждый. Ниже разбираем, как это устроено и что нужно для подключения.

Способы подключения оплаты ЕРИП: сравнение вариантов

Есть три рабочих схемы приёма оплаты через ЕРИП, и выбор между ними определяется не «модностью», а тем, кто у вас ведёт учёт счетов и как часто меняется номенклатура. Ниже — сравнение по условиям применимости, а не по цене: стоимость у всех трёх складывается из разного набора работ, и на старте это не всегда очевидно.

Прямое подключение

Здесь вы сами формируете счёт с идентификатором в системе «Расчёт» и получаете от банка статус оплаты. Это даёт полный контроль: можно закрывать заказ автоматически, слать уведомления, строить отчётность по фактическим поступлениям. Плата за это — договор с банком и модуль обмена, который придётся сопровождать при изменениях на стороне банка.

Агрегатор и ручная выгрузка

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

Разбираем, какой вариант закрывает вашу схему учёта без лишних доработок.

Этапы внедрения оплаты ЕРИП в 1С-Битрикс

Внедрение оплаты через ЕРИП затрагивает не только страницу оформления заказа, но и обмен с 1С, статусы заказов и сверку платежей. Поэтому работаем по этапам — от разбора текущей схемы до передачи настроенной системы с регламентами. Ниже — как выглядит процесс для заказчика.

1. Аудит заказов и текущей схемы оплаты. Смотрим, как формируются заказы, какие статусы используются, где хранятся суммы и как данные попадают в 1С. Фиксируем узкие места: ручные сверки, дублирование заказов, расхождения статусов после оплаты.

2. Проектирование сценария оплаты. Определяем, на каком шаге покупатель уходит в ЕРИП, как возвращается на сайт, что происходит при отказе и повторной попытке. Согласуем логику статусов: «ожидает оплаты», «оплачен», «отменён» — чтобы бухгалтерия и склад видели одно и то же.

3. Настройка обмена с 1С. Настраиваем выгрузку заказов, синхронизацию номенклатуры и корректную передачу сумм. Обмен идёт по расписанию и по событиям — заказ не «зависает» в промежуточном состоянии.

4. Подключение оплаты ЕРИП. Интегрируем платёжный модуль в оформление заказа, настраиваем формирование счёта и приём подтверждений об оплате. Проверяем, что покупатель видит понятный статус, а система — корректную отметку.

5. Тестирование платежей. Прогоняем сценарии: успешная оплата, отказ, повторная попытка, оплата с задержкой. Сверяем, что суммы, статусы и данные в 1С совпадают на каждом шаге.

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

7. Поддержка после запуска. Сопровождаем первые циклы оплат, отслеживаем расхождения и корректируем обмен, если меняются условия или номенклатура.

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

Что заказчик получает после настройки интеграции

Интеграция считается завершённой не когда «оплата прошла», а когда передача результата не зависит от конкретного инженера. Поэтому фиксируем всё, что нужно для эксплуатации, сопровождения и передачи другой команде.

• Конфигурации обмена: рабочие профили интеграции 1С-Битрикс с ЕРИП и учётной системой, параметры сопоставления номенклатуры, ставок и статусов заказа, настройки очередей повторной отправки при недоступности шлюза.
• Схема обмена: карта потоков «корзина → счёт → подтверждение оплаты → закрывающие документы» с точками идемпотентности, чтобы повторный вызов не создавал дубль платежа.
• Политики доступа: разграничение прав на платёжные методы и выгрузки, отдельные сервисные учётные записи, ротация ключей и правила хранения логов транзакций.
• Документация: описание сценариев оплаты и возврата, перечень кодов ошибок ЕРИП с расшифровкой и действиями оператора, инструкция для менеджера по ручной сверке зависших счетов.
• Регламенты обслуживания: периодичность сверки оплат с банковской выпиской, порядок действий при расхождении сумм, точки контроля после обновлений платформы и модулей.
• Инструменты диагностики: журналирование запросов и ответов платёжного шлюза, тестовый контур для прогона сценариев оплаты и возврата без реальных списаний.
• План отката: порядок возврата к прежнему способу оплаты и сохранение корректности уже проведённых транзакций.

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

Кейс: как мы устранили двойные списания при оплате через ЕРИП

Клиент — сервисный провайдер с личным кабинетом на 1С-Битрикс — принимал платежи через ЕРИП и вручную разбирал обращения. Проблема проявлялась не постоянно, а пачками: при обрыве сессии между шлюзом и сайтом покупатель видел ошибку, повторял платёж, и оба списания проходили. Заявки на возврат копились, бухгалтерия сверяла выписки ЕРИП с заказами вручную, а часть расхождений всплывала только при закрытии месяца.

Что было до внедрения

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

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

Что изменили

Мы перевели подтверждение оплаты на асинхронную схему: заказ закрывается по уведомлению от платёжного шлюза, а не по возврату покупателя на сайт. Каждому платежу присваивается уникальный идентификатор, по которому повторная попытка распознаётся и не создаёт второе списание.

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

Что стало

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

Чем отличается оплата через ЕРИП от эквайринга?

Эквайринг — это карточный поток: покупатель вводит данные карты, банк-эквайер авторизует операцию онлайн и отвечает в момент оплаты. Деньги при этом зачисляются не сразу, а расчётным циклом, но статус «оплачено» приходит синхронно, и заказ можно проводить в 1С практически мгновенно. ЕРИП устроен иначе: это платёжная система с деревом услуг, где каждой услуге соответствует код в иерархии, а платёж инициируется на стороне банка или инфокиоска, а не на сайте.

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

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

Требования к интеграции из этого и вытекают. Для ЕРИП нужны регистрация услуги в дереве, корректный код и номер счёта, обработчик уведомлений от банка и регулярная сверка реестра — иначе платежи «зависнут» без привязки к заказу. Для эквайринга достаточно платёжного модуля и обработки колбэка. На практике многие проекты держат оба способа: эквайринг для быстрой оплаты картой, ЕРИП — для тех, кому удобнее платить через банк.

Частые технические вопросы по интеграции оплаты

Интеграция оплаты почти никогда не идёт «в пустое поле»: на стороне заказчика уже работает учётная система, есть справочники, документы, роли. Поэтому первый вопрос на старте — не «какой модуль поставим», а «что именно придётся менять в уже развёрнутой системе». Ниже — то, что чаще всего всплывает на этапе оценки.

У нас уже развёрнута система на 1С — придётся её перестраивать?

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

Чем плоха ручная выгрузка платежей и когда она всё же допустима?

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

Какие ограничения есть у интеграции и как вы их закрываете?

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

Обсудим вашу задачу по интеграции оплаты

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

Опишите задачу — и мы разберём её по существу. Достаточно ответить на несколько вопросов:

• Какая конфигурация 1С используется и как она связана с сайтом: обмен через модуль, веб-сервисы или ручная выгрузка.
• Как сейчас принимаются оплаты: ЕРИП, эквайринг, наличные — и какие статусы заказа проставляются вручную.
• Где ведётся учёт заказов и номенклатуры: в 1С, в Битрикс24 или в двух системах параллельно.
• Есть ли доработки в типовом обмене и кто их поддерживает — это влияет на объём работ.
• Какие отчёты нужны по итогу: сверка оплат, выгрузка в бухгалтерию, уведомления менеджерам.
• Есть ли ограничения по доступам, хостингу и регламенту обновлений.

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