Как подключить Сбербанк Эквайринг к магазину на 1С-Битрикс

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

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

Что даёт интернет-эквайринг

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

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

Что понадобится до старта

Прежде чем настраивать что-либо в админке, соберите исходные данные. Без них подключение застопорится на середине.

• Договор эквайринга. Заключённый с банком договор интернет-эквайринга.
• Реквизиты мерчанта. Идентификатор и пароль (или ключи) доступа к платёжному шлюзу.
• Тестовые доступы. Отдельные реквизиты для тестового контура и тестовые карты.
• Онлайн-касса. Подключённая касса или договор с ОФД для фискализации по 54-ФЗ.
• Доступ к сайту. Административная часть Битрикса и возможность настроить внешний адрес для callback.

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

Как устроена оплата в Битриксе

В 1С-Битрикс приём платежей живёт в модуле «Интернет-магазин». Оплата описывается сущностью «платёжная система» с обработчиком, который знает, как общаться с конкретным банком. Общая логика процесса такая:

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

Шаг 1. Реквизиты мерчанта от банка

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

1. Запросите реквизиты у банка. Боевые и тестовые доступы к интернет-эквайрингу.
2. Уточните адреса шлюза. URL для формирования платежа в тестовом и боевом контуре.
3. Согласуйте формат уведомлений. Как банк присылает callback и как проверяется его подпись.
4. Держите доступы в секрете. Пароли и ключи не хранят в открытом виде и не светят в публичном коде.

Эти данные вы будете вводить в настройках платёжной системы, поэтому проверьте, что они актуальны и относятся к нужному контуру (тест или бой).

Шаг 2. Платёжная система в магазине

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

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

Если в вашей сборке нет готового обработчика под нужный шлюз, берут решение из Маркетплейса или дорабатывают обработчик под API банка. Инженерные аспекты такой доработки мы разбирали в статье про разработку модуля для Битрикс.

Шаг 3. Callback и смена статуса

Самая ответственная часть — обработка уведомления банка о результате платежа. Банк присылает callback на заранее указанный адрес, а обработчик должен принять его, проверить подлинность и перевести заказ в оплаченный статус.

1. Задайте адрес обратного вызова. URL callback должен быть доступен извне и указан в настройках у банка.
2. Проверяйте подпись. Каждое уведомление проверяется на подлинность, чтобы исключить подделку.
3. Меняйте статус по callback. Заказ переводится в «оплачен» именно по серверному уведомлению.
4. Ведите журнал. Логируйте платёжные операции для сверки с личным кабинетом банка.

Корректная и безопасная обработка входящих уведомлений — общая инженерная тема. Принципы работы с внешними вызовами и их защитой мы описывали в статье про REST, вебхуки и безопасность в Битрикс.

Шаг 4. Фискальные чеки по 54-ФЗ

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

• Привяжите онлайн-кассу. Свяжите платёжную систему с кассой (своей или через ОФД).
• Настройте состав чека. Позиции, ставки НДС, признаки предмета и способа расчёта.
• Проверьте отправку копии. Электронный чек уходит покупателю на почту или телефон.
• Учтите возвраты. При возврате формируется чек возврата — это тоже настраивается заранее.

Состав чека часто зависит от данных товара (ставка НДС, тип), которые приходят из учётной системы. Поэтому корректная фискализация опирается на порядок в номенклатуре 1С — то, что мы настраиваем в проектах по автоматизации на 1С.

Шаг 5. Тестовый режим

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

1. Включите тестовые реквизиты. В платёжной системе укажите тестовый шлюз и доступы.
2. Проведите пробные платежи. Оплатите тестовыми картами успешный и неуспешный сценарии.
3. Проверьте весь путь. Переход на оплату, возврат на сайт, приход callback, смену статуса, формирование чека.
4. Проверьте ошибки. Как ведёт себя заказ при отказе банка и при недошедшем уведомлении.

Только когда тестовые сценарии проходят стабильно, платёжную систему переключают на боевые реквизиты. Разделение тестового и боевого контуров — часть здорового процесса выката; как он устроен в Битриксе, мы описывали в статье про CI/CD и деплой на Битрикс.

Одно- и двухстадийная оплата

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

• Одностадийная. Проще, деньги сразу у вас; подходит для товаров, которые точно в наличии.
• Двухстадийная. Сначала холд, потом списание; удобна, когда нужно проверить наличие или собрать заказ.
• Отмена холда. Если товара не оказалось, неподтверждённый холд отменяется без полноценного возврата.

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

Возвраты и частичные возвраты

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

• Полный возврат. Возвращается вся сумма заказа, формируется чек возврата по 54-ФЗ.
• Частичный возврат. Возвращается часть заказа — важно, чтобы состав чека возврата был корректным.
• Отмена холда. Для двухстадийной схемы неподтверждённый платёж проще отменить, чем возвращать.
• Сверка статусов. Статус заказа в Битриксе должен соответствовать реальному состоянию в банке.

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

Запуск в бой и мониторинг

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

• Контрольный платёж. Реальная оплата на малую сумму с проверкой чека и статуса, затем возврат.
• Журнал операций. Сверяйте платежи в Битриксе с личным кабинетом банка.
• Повторная проверка статуса. Настройте регламентную сверку (агентом), чтобы «повисшие» заказы дожимались до корректного статуса.
• Мониторинг доступности callback. Адрес обратного вызова должен быть стабильно доступен извне.

Стабильность приёма платежей во многом упирается в инфраструктуру: доступность callback, отсутствие сбоев на пике. Как это обеспечивается, мы разбирали в статье про хостинг и инфраструктуру BitrixVM.

Частые ошибки

• Статус по редиректу, а не по callback. Клиент закрыл вкладку — деньги списаны, заказ «не оплачен».
• Нет проверки подписи. Уведомление банка принимается без проверки подлинности.
• Забыли про 54-ФЗ. Приём оплаты запущен без фискальных чеков — нарушение закона.
• Запуск без тестов. Эквайринг включают сразу на боевых реквизитах и ловят ошибки на реальных клиентах.
• Callback недоступен извне. Адрес закрыт, уведомления не доходят, статусы расходятся.
• Возвраты не продуманы. Первый же возврат превращается в ручную возню и неверные чеки.
• Доступы в открытом виде. Пароли шлюза лежат в публичном коде или незащищённо.

Чек-лист внедрения

1. Исходные данные собраны. Договор, реквизиты мерчанта, тестовые доступы, онлайн-касса.
2. Платёжная система заведена. Обработчик выбран, реквизиты введены, привязка к оплате картой настроена.
3. Callback работает. Адрес доступен извне, подпись проверяется, статус меняется по уведомлению.
4. Фискализация настроена. Чеки по 54-ФЗ формируются, состав и НДС корректны, копия уходит покупателю.
5. Тесты пройдены. Успешный и неуспешный сценарии проверены на тестовом контуре.
6. Схема оплаты выбрана. Одно- или двухстадийная под ваши товары и процессы.
7. Возвраты продуманы. Полный и частичный возврат с корректными чеками работают.
8. Мониторинг настроен. Журнал операций, сверка с банком и регламентная проверка статусов.

Вывод

Подключение интернет-эквайринга Сбербанка к магазину на 1С-Битрикс укладывается в понятную схему: платёжная система в модуле «Интернет-магазин» плюс реквизиты мерчанта от банка. Но дьявол в деталях — статус заказа должен меняться по серверному callback с проверкой подписи, а не по возврату пользователя, а каждый платёж обязан сопровождаться фискальным чеком по 54-ФЗ.

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