Банковский эквайринг на 1С-Битрикс: Сбер, Т-Банк, Альфа и другие

Когда магазин вырастает из «подключить оплату за час», встаёт вопрос: принимать деньги через агрегатор вроде ЮKassa или заключить прямой договор эквайринга с банком — Сбербанком, Т-Банком, Альфа-Банком, ВТБ. У прямого интернет-эквайринга банка своя логика: свои комиссии, свой личный кабинет, свои нюансы с фискализацией. Эта статья — практическое руководство по тому, как устроен банковский эквайринг, чем он отличается от агрегаторов и как подключить платёжную систему банка в интернет-магазине на 1С-Битрикс без сюрпризов.

Разберём по шагам: что такое эквайринг банка и когда он выгоднее агрегатора, какие банки его дают, как настроить обработчик оплаты и параметры мерчанта в Битриксе, как принять callback от банка, не нарушить 54-ФЗ, пройти 3-D Secure, отладить тест и запустить боевые платежи, а затем корректно делать возвраты и сверку с выпиской. Материал основан на нашей практике разработки магазинов с оплатой и доставкой и интеграций платёжных систем. Важный дисклеймер: вопросы комиссий, договора, 54-ФЗ и налогов — это финансово-юридическая зона, которую всегда сверяют с банком и бухгалтером; здесь мы описываем техническую сторону подключения и не приводим конкретных тарифов.

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

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

Ключевое слово здесь — «прямой договор». При банковском эквайринге вы заключаете договор непосредственно с банком, а не с посредником-агрегатором. Из этого вытекают все практические особенности.

• Расчётный счёт в банке. Обычно эквайринг подключают в том банке, где у бизнеса уже открыт расчётный счёт, — тогда деньги от оплат приходят «внутри» одного банка, а сверка проще.
• Своя комиссия эквайринга. Ставку устанавливает банк по договору. Она зависит от оборота, сферы бизнеса и других условий — конкретные цифры всегда обсуждаются с банком индивидуально.
• Личный кабинет банка. Управление операциями, возвраты, реестры и выписки живут в интерфейсе банка, а не в кабинете стороннего сервиса.
• Фискализация — отдельно. Банк принимает деньги, но чек по 54-ФЗ во многих случаях формирует не он, а ваша касса или касса-партнёр. Это важное отличие от агрегаторов с кассой «в комплекте».

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

Эквайринг банка vs агрегатор

Чтобы выбор был осознанным, важно понять разницу между прямым эквайрингом банка и платёжным агрегатором (ЮKassa, Т-Касса и подобные сервисы). Это два разных способа принять те же самые карты.

Агрегатор — это посредник между магазином и банками. Он объединяет множество способов оплаты (карты, СБП, кошельки, рассрочки) в одном подключении, часто предлагает облачную кассу и берёт на себя большую часть технических хлопот. Прямой эквайринг банка — это договор с конкретным банком без посредника: меньше «обёртки», но и меньше готовых удобств вроде кассы в комплекте.

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

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

Какие банки дают эквайринг

Интернет-эквайринг предлагают практически все крупные банки. Ниже — обзорный, не рекламный перечень: мы не сравниваем тарифы (они меняются и обсуждаются индивидуально), а показываем, что подключение технически возможно у разных банков и различается в основном деталями кабинета и наличием готового модуля.

Важно понимать: конкретное название модуля, наличие готового обработчика в Маркетплейс 1С-Битрикс и точный формат интеграции нужно уточнять у самого банка перед подключением. У части банков есть собственный официальный модуль для Битрикса, у части — подключение делается по документации API. С технической точки зрения все они работают по схожему принципу: магазин отправляет банку сумму и данные заказа, покупатель платит на защищённой странице банка, банк возвращает результат и присылает уведомление.

Как устроен приём оплаты через банк

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

Разложим цепочку по узлам, как она устроена внутри 1С-Битрикс:

• Платёжная система. В модуле «Интернет-магазин» это настройка конкретного способа оплаты — эквайринга банка. У неё свой обработчик и свои параметры мерчанта.
• Обработчик платежа. Код (модуль банка или штатный обработчик), который умеет «разговаривать» с банком: формировать платёж, отправлять сумму и заказ, принимать результат и уведомление.
• Страница оплаты банка. Покупатель вводит данные карты не на вашем сайте, а на защищённой странице банка — это ключевой момент для безопасности.
• Callback (уведомление банка). Служебный запрос банка на сайт: «заказ №X оплачен». Именно он переводит заказ в статус «оплачен».
• Возврат покупателя. Параллельно покупателя возвращают на страницу «Спасибо за заказ», но факт оплаты подтверждает не это, а callback.

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

Что подготовить до подключения

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

Договор эквайринга и расчётный счёт

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

Параметры мерчанта и доступы

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

Касса по 54-ФЗ

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

Технические требования к сайту

• HTTPS. Сайт должен работать по защищённому протоколу — это обязательное условие и для безопасности, и для приёма callback от банка.
• Модуль «Интернет-магазин». Нужна редакция с этим модулем («Малый бизнес» или «Бизнес»), иначе платёжных систем просто нет.
• Доступность сайта извне. Адрес для уведомлений банка должен быть доступен из интернета, без блокировки файрволом.
• Настроенные ставки НДС и признаки товаров. Для корректных чеков у товаров должны быть заданы ставка НДС, признак предмета и способа расчёта.

Эквайринг Сбербанка пошагово

Эквайринг Сбербанка (в связке со СберБизнес) — один из самых распространённых у российских магазинов, и для него в 1С-Битрикс есть готовый обработчик или модуль. На его примере удобно показать общий порядок подключения — у других банков он похож, отличаются лишь названия параметров и кабинет.

1. Получите параметры мерчанта. В личном кабинете эквайринга Сбербанка возьмите идентификатор магазина/логин и пароль (или ключи) для интеграции. Это данные, которые свяжут сайт с вашим договором эквайринга.
2. Установите или включите обработчик. В админке Битрикса в разделе «Магазин → Платёжные системы» добавьте новую платёжную систему и выберите обработчик эквайринга Сбербанка (штатный или из установленного модуля банка).
3. Впишите параметры. Укажите логин, пароль и другие параметры мерчанта в настройках платёжной системы. Внимательно — опечатка тихо ломает оплату, а ошибку потом трудно найти.
4. Настройте чек по 54-ФЗ. Подключите вашу кассу или кассу-партнёр, включите формирование чека и сопоставьте ставки НДС, признаки предмета и способа расчёта.
5. Укажите адрес уведомлений (callback). Пропишите в кабинете банка адрес, на который банк будет присылать подтверждение оплаты и (при необходимости) результат возврата. Адрес подсказывает обработчик в Битриксе.
6. Привяжите к оформлению. Сделайте так, чтобы способ оплаты эквайрингом показывался покупателям на шаге оформления заказа, при нужных доставках и типах плательщика.
7. Проверьте на тесте. Прежде чем включать боевой режим, прогоните тестовый платёж в тестовой среде банка и убедитесь, что заказ отмечается оплаченным и формируется чек.

После настройки эквайринг Сбербанка принимает оплату картами, а СБП обычно подключается как отдельный способ (об этом — в разделе про СБП). Ключевые точки, где чаще всего спотыкаются, — параметры мерчанта, адрес callback и настройка чека; их проверяют особенно тщательно.

Эквайринг Т-Банка

Т-Банк — ещё один распространённый эквайер с инструментами для e-commerce. Логика подключения та же, что у Сбербанка: получить параметры, настроить обработчик, вписать ключи, задать callback, проверить. Отличаются кабинет и названия параметров.

1. Получите доступы эквайринга. В личном кабинете Т-Банка возьмите идентификатор терминала и ключ/пароль для интеграции.
2. Добавьте платёжную систему. В разделе платёжных систем Битрикса подключите обработчик Т-Банка (модуль банка или совместимый обработчик).
3. Впишите параметры мерчанта. Укажите идентификатор терминала и ключ, проверьте корректность без опечаток.
4. Настройте чек по 54-ФЗ. Сопоставьте ставки НДС и признаки расчёта в зависимости от того, какая касса используется.
5. Пропишите адрес уведомлений в кабинете Т-Банка, чтобы заказы корректно отмечались оплаченными по callback.
6. Проверьте на тесте и в бою. Сначала тестовый платёж в тестовой среде, затем контрольный реальный на малую сумму.

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

Альфа-Банк, ВТБ и другие

Альфа-Банк, ВТБ и остальные банки подключаются по той же схеме, что Сбербанк и Т-Банк. Различия — в конкретных параметрах мерчанта, наличии официального модуля для Битрикса и деталях кабинета. Универсальный порядок для «любого банка» выглядит так.

1. Уточните способ интеграции. Спросите у банка, есть ли официальный модуль для 1С-Битрикс или подключение делается по документации API. Это определит объём работ.
2. Получите параметры мерчанта и доступ в личный кабинет эквайринга.
3. Установите модуль или настройте обработчик по документации банка, впишите параметры.
4. Задайте адрес callback и, если требуется, адрес возврата покупателя (успех/неуспех).
5. Подключите кассу и настройте чеки по 54-ФЗ.
6. Проверьте на тесте и в бою перед полноценным запуском.

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

Параметры мерчанта и обработчик

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

• Идентификатор магазина / терминала. Уникальный номер вашей точки приёма оплаты у банка. По нему банк понимает, чьи это платежи.
• Логин и пароль API (или ключ). Учётные данные, которыми обработчик авторизуется у банка при создании платежа и запросе статуса.
• Секретный ключ / сертификат. Используется для подписи запросов и проверки подлинности уведомлений — чтобы нельзя было подделать «заказ оплачен».
• Режим (тест / боевой). Переключатель между тестовой средой банка и приёмом реальных денег. На старте всегда тест.
• Адреса возврата и уведомлений. Куда вернуть покупателя после оплаты (успех/неуспех) и на какой адрес банк шлёт callback.

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

Callback и статус заказа

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

Как работает связка:

1. Покупатель оплачивает на защищённой странице банка и подтверждает операцию по 3-D Secure.
2. Банк проводит списание и отправляет на специальный адрес сайта служебное уведомление «заказ №X оплачен».
3. Обработчик платёжной системы Битрикса принимает уведомление, проверяет его подлинность (по ключу/подписи) и переводит заказ в статус «оплачен».
4. Параллельно покупателя возвращают на страницу «Спасибо за заказ», а по 54-ФЗ формируется чек.

Из этого следует, что при настройке критично проверить три вещи: правильно ли указан адрес callback в кабинете банка, доступен ли сайт по HTTPS для входящих запросов банка и совпадают ли ключи/подпись на сайте и у банка. Если хоть что-то из этого не так, возникает классическая беда: деньги списались, а заказ висит неоплаченным. Как связать статусы оплаты со всей воронкой обработки заказа — от «оплачен» до «выполнен» — мы разбираем в статье про возвраты и отмены заказов в 1С-Битрикс, где статус оплаты играет ключевую роль.

Отдельно отметим особенность банковского эквайринга: даже при корректном callback окончательная истина — это выписка по расчётному счёту. Callback говорит «операция прошла», но реальное зачисление денег банк проводит по своему регламенту. Поэтому надёжная схема двухуровневая: оперативно — статус по callback, окончательно — сверка с выпиской (об этом в разделе про сверку).

Фискализация и чеки 54-ФЗ

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

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

Технически чек можно формировать двумя способами:

• Своя касса. Фискальный накопитель и касса (физическая или арендованная), подключённые к магазину. Чек формируется на вашем оборудовании и отправляется покупателю.
• Касса-партнёр (облачная). Отдельный сервис фискализации, который по данным о платеже формирует чек и отправляет его покупателю. При банковском эквайринге это частый вариант, так как «в комплекте» кассы обычно нет.

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

3-D Secure и подтверждение платежа

3-D Secure — это технология дополнительного подтверждения платежа держателем карты. После того как покупатель ввёл данные карты на странице банка, банк-эмитент (банк покупателя) просит подтвердить операцию: обычно кодом из СМС или подтверждением в мобильном приложении банка. Только после этого платёж считается подтверждённым.

Зачем это нужно и почему важно для эквайринга:

• Защита от мошенничества. Даже зная данные карты, злоумышленник не подтвердит платёж без доступа к телефону/приложению владельца.
• Перенос ответственности. При успешном 3-D Secure ответственность за спорные операции в значительной части переходит на банк-эмитент — это выгодно магазину.
• Фактический стандарт. Для интернет-эквайринга подтверждение по 3-D Secure — норма. Отключать его самостоятельно не стоит: это вопрос безопасности и условий договора.

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

СБП через банк

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

Почему СБП стоит подключить в дополнение к картам:

• Комиссия обычно ниже, чем у карточного эквайринга, — для магазина это прямая экономия на обороте.
• Деньги поступают быстро, что удобно для оборотки.
• Покупателю проще: отсканировал QR или нажал кнопку в приложении банка и подтвердил, без ввода реквизитов карты.

Как это выглядит для покупателя: на десктопе он видит QR-код и сканирует его приложением своего банка, на мобильном — нажимает кнопку перехода в банковское приложение. После подтверждения банк присылает сайту уведомление, и заказ отмечается оплаченным — та же логика callback, что и с картами. Важно проверить мобильный сценарий отдельно: на телефоне покупатель не сканирует QR сам с себя, поэтому нужна именно кнопка-переход, а не картинка с кодом. Базовую механику подключения СБП и оплаты по QR мы подробно разбираем в статье про подключение ЮKassa и СБП — принцип для банковского СБП тот же.

Тестовые и боевые платежи

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

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

• Создание платежа. При выборе эквайринга покупатель корректно уходит на страницу банка, сумма совпадает с заказом.
• Успешная оплата с 3-D Secure. После подтверждения заказ переходит в статус «оплачен» по callback банка.
• Возврат на сайт. Покупателя возвращает на «Спасибо за заказ» с номером заказа.
• Чек по 54-ФЗ. Формируется и отправляется тестовый чек с правильными суммами и ставками НДС.
• Неуспешная оплата. Отказ или отмена обрабатываются корректно — заказ не отмечается оплаченным, покупатель видит понятное сообщение.
• СБП на мобильном. Кнопка перехода в банковское приложение работает, а не только десктопный QR.

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

1. Переключите параметры на боевые. Замените тестовые доступы банка на боевые в настройках платёжной системы.
2. Сделайте контрольный платёж. Оплатите реальный заказ на небольшую сумму настоящей картой и через СБП.
3. Проверьте всю цепочку. Деньги отражены у банка и придут на счёт, заказ отметился оплаченным по callback, чек по 54-ФЗ сформировался и пришёл покупателю.
4. Сделайте возврат контрольного платежа. Заодно проверите, что возвраты работают (об этом ниже).
5. Только потом — полный запуск. Убедившись, что боевая цепочка работает, открывайте оплату всем покупателям.

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

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

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

Что важно учесть по возвратам через эквайринг:

• Полный и частичный возврат. Иногда возвращают всю сумму, иногда часть (вернули один товар из нескольких). Банки это поддерживают, но сценарий нужно проверить заранее.
• Где инициируется возврат. Из админки сайта (если обработчик умеет) или из личного кабинета банка. Договоритесь, как именно, чтобы бухгалтерия и менеджеры не путались.
• Чек на возврат. По 54-ФЗ на возврат тоже формируется кассовый чек (чек возврата прихода). Нужно проверить, что он формируется — это часть фискализации.
• Возврат только на ту же карту. Деньги возвращаются на карту, с которой была оплата, и приходят не мгновенно — об этом честно предупреждают покупателя.

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

Сверка с банком и выписки

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

Как выстроить сверку на практике:

• Реестр операций эквайринга. В кабинете банка есть список платежей и возвратов за период. Его сопоставляют с заказами на сайте: каждой оплате должен соответствовать оплаченный заказ.
• Выписка по расчётному счёту. Итоговое зачисление денег (за вычетом комиссии) отражается в выписке. Это финальный контроль, что деньги реально пришли.
• Регулярность. Сверку делают регулярно (например, ежедневно или по расписанию бухгалтерии), а не «когда что-то не сошлось».
• Расхождения. Типовые случаи — платёж есть у банка, но заказ не оплачен (не дошёл callback), или заказ оплачен, но платежа у банка нет (редко, но проверяют). Оба разбирают вручную.

Для магазинов с заметным оборотом сверку часто автоматизируют через обмен с учётной системой (1С), чтобы бухгалтерия видела соответствие заказов и поступлений без ручного труда. Как построить надёжный обмен заказами и статусами оплаты с учётной системой, мы разбираем в статье про интеграцию магазина с 1С.

Безопасность и PCI DSS

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

Здесь уместно упомянуть PCI DSS — международный стандарт безопасности данных платёжных карт. Если очень коротко и обзорно: он описывает требования к тем, кто хранит, обрабатывает или передаёт данные карт. Когда магазин не касается карточных данных (покупатель вводит их у банка), объём применимых требований к магазину существенно меньше — этим и хорош сценарий с оплатой на стороне банка. Точную применимость и объём требований для вашего случая определяют банк-эквайер и специалисты по безопасности; самостоятельно «трактовать PCI DSS» не нужно.

Базовые меры, которые соблюдают всегда:

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

Эквайринг или агрегатор: как выбрать

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

Когда чаще выбирают прямой эквайринг банка

• У бизнеса уже есть расчётный счёт в банке, и удобно держать деньги и приём оплаты в одном окне.
• Заметный оборот, при котором условия по комиссии от банка становятся ощутимо выгоднее.
• Нужна тесная связка с банковскими сервисами и единая поддержка по счёту и эквайрингу.

Когда чаще выбирают агрегатор

• Нужен быстрый старт с минимумом бумаг и настройки.
• Важно «всё в одном»: карты, СБП, кошельки, рассрочки и касса в комплекте.
• Оборот пока небольшой, и удобство важнее, чем небольшая экономия на комиссии.

На что смотреть при сравнении по существу: комиссия (с учётом реального оборота и среднего чека), скорость и сложность подключения, кто и как решает фискализацию (54-ФЗ), качество и скорость поддержки, надёжность и наличие резервного канала оплаты. Нередко разумный путь — начать с агрегатора, а по мере роста пересчитать экономику и при выгоде перейти на прямой эквайринг или держать оба канала для надёжности (если один недоступен, работает второй).

Частые ошибки при подключении

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

• Деньги списались, а заказ не оплачен. Самая частая беда. Причина — не доходит или не обрабатывается callback банка: неверный адрес уведомлений, сайт недоступен по HTTPS, не совпадают ключи/подпись, запрос блокирует файрвол. Проверяйте именно цепочку уведомлений и логи платёжной системы.
• Опечатка в параметрах мерчанта. Один неверный символ в логине, пароле или ключе тихо ломает оплату. Сверяйте параметры внимательно и не копируйте с лишними пробелами.
• Не настроена касса по 54-ФЗ. При эквайринге кассы «в комплекте» может не быть, и про чек забывают. Оплата проходит, а чек не формируется — нарушение закона. Настройте и проверьте чек на тесте.
• Неверные ставки НДС и признаки товаров. Чек уходит некорректным. Заранее проставьте ставки НДС, признак предмета и способа расчёта.
• Не проверили 3-D Secure. Сценарий подтверждения не прогнали, и в бою на отказе 3DS заказ ведёт себя непредсказуемо. Тестируйте и успех, и отказ подтверждения.
• СБП не работает на мобильном. На телефоне показан QR вместо кнопки перехода в банк — покупатель не может оплатить. Тестируйте мобильный сценарий отдельно.
• Не настроены возвраты. Приём сделали, возврат — нет, и первый же возврат превращается в ручную возню в кабинете банка. Включайте возврат в сценарий запуска.
• Нет регулярной сверки. Без сверки с реестром и выпиской расхождения копятся незаметно. Настройте регулярную сверку заказов с операциями банка.
• Сразу в боевой режим без теста. Пропустили тестовую среду банка ради скорости — поймали ошибку на реальных деньгах. Всегда сначала тест, потом контрольный реальный платёж.

Чек-лист подключения

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

1. Договор эквайринга и расчётный счёт оформлены, магазин прошёл проверку банка.
2. Параметры мерчанта (идентификатор, логин/пароль, ключи) получены и надёжно сохранены.
3. Сайт на HTTPS и доступен извне для callback банка.
4. Платёжная система создана в Битриксе, обработчик установлен, параметры вписаны без опечаток.
5. Адрес уведомлений (callback) прописан в кабинете банка, ключи/подпись совпадают.
6. Касса по 54-ФЗ настроена: касса выбрана, ставки НДС и признаки расчёта заданы, чек формируется.
7. 3-D Secure проверен: и успешное подтверждение, и отказ обрабатываются корректно.
8. СБП проверен и на десктопе (QR), и на мобильном (кнопка в банк), если подключён.
9. Тестовые сценарии пройдены: успех, отказ, чек, возврат.
10. Контрольный боевой платёж на малую сумму сделан и возвращён.
11. Возвраты работают: полный и частичный, с чеком возврата.
12. Сверка настроена: заказы сопоставляются с реестром эквайринга и выпиской банка.

Вывод

Банковский интернет-эквайринг — это приём карт напрямую от банка, с прямым договором, расчётным счётом и своими условиями по комиссии. От агрегатора он отличается не тем, «лучше или хуже», а профилем: единое окно с банком и потенциально выгодные условия на обороте — но фискализацию (чеки 54-ФЗ) чаще нужно решать отдельно, а подключение занимает больше времени. Технически же эквайринг Сбербанка, Т-Банка, Альфа-Банка и других подключается в 1С-Битрикс по одной логике: параметры мерчанта, обработчик, callback, чек, тест и боевой запуск.

Запускайте эквайринг осторожно: сначала тестовая среда банка со всеми сценариями (включая 3-D Secure и отказы), затем контрольный реальный платёж с возвратом, и только убедившись, что цепочка работает и деньги приходят, — открывайте приём для всех. Не забывайте про надёжность второго уровня: заказ отмечается оплаченным по callback, а окончательный контроль — регулярная сверка с реестром и выпиской банка. Тогда покупатели платят удобно, а вы — без сюрпризов «деньги ушли, а заказа нет». А что выбрать именно вам — прямой эквайринг или агрегатор вроде ЮKassa — решайте по цифрам своего оборота, а не по общим словам.