Несколько платёжных систем на одном сайте

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

Где живут платёжные системы в Битрикс

Все способы оплаты магазина настраиваются в административной части: Магазин → Настройки → Платёжные системы (в старых сборках путь /bitrix/admin/sale_pay_system.php, в актуальном модуле sale — раздел на D7). Каждая запись здесь — это отдельный обработчик (handler): ЮKassa, Robokassa, Сбербанк, СБП, «оплата при получении», «счёт для юрлиц» и т. д.

Ограничения на количество платёжных систем нет — вы можете держать их хоть десяток. Но список, который увидит покупатель, формируется динамически: Битрикс отбирает только те системы, у которых стоит флаг ACTIVE = Y и которые прошли по всем заданным ограничениям для конкретного заказа. Именно на этом отборе и строится вся логика «нескольких систем на одном сайте».

Порядок и оформление на витрине

Порядок, в котором способы оплаты показываются на шаге оформления заказа, задаётся полем «Сортировка» (SORT). Чем меньше число — тем выше в списке. Ставьте самый выгодный и массовый способ (обычно оплата картой или СБП) с наименьшим значением, например 100, а нишевые (счёт, наложенный платёж) — ниже.

• Название и описание — то, что читает покупатель; пишите по-человечески: «Банковской картой онлайн», а не «YANDEX_HANDLER».
• Логотип — загружается в карточке системы и повышает доверие; для карт и СБП это важно.
• Флаг «По умолчанию» (DEF) — какая система будет предвыбрана, если покупатель ничего не трогает.

За вывод отвечает компонент оформления заказа — sale.order.ajax (или sale.order.full в старых шаблонах). Если после добавления системы она не появилась на витрине, в 90% случаев дело не в компоненте, а в ограничениях, о которых ниже.

Ограничения — главный инструмент разграничения

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

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

Связка с типами плательщиков

Самое частое разграничение в B2B/B2C-магазине — физлицо и юрлицо. Тип плательщика в Битрикс — это отдельная сущность (Магазин → Настройки → Типы плательщиков), к которой привязаны свойства заказа (ИНН, КПП, паспорт и т. д.). Онлайн-эквайринг логично разрешить физлицам, а «оплату по счёту» — юрлицам.

Есть два способа связать оплату с типом плательщика:

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

Обработчики, callback и статусы

Каждая внешняя платёжная система (ЮKassa, Robokassa, Тинькофф, CloudPayments) работает через свой callback-URL — адрес, на который банк присылает уведомление об успешной оплате. Когда систем несколько, у каждой свой URL уведомления и свой набор ключей (Shop ID, секретный ключ, пароли). Держите их в порядке: перепутанный секрет — самая частая причина «оплата прошла, а заказ не оплачен».

• Уведомления обрабатываются файлом /bitrix/tools/sale_ps_result.php (или payment.php в зависимости от обработчика) — он и переводит заказ в статус «Оплачен».
• В настройках каждой системы задаётся, в какой статус заказа его перевести после оплаты и надо ли списывать со склада.
• Для отладки нескольких систем удобен тестовый режим: он есть у большинства обработчиков и позволяет проверить callback без реальных денег.

Если магазин работает с онлайн-кассой (54-ФЗ), проверьте, что чек пробивается один раз и корректной ПС — при нескольких эквайрингах легко получить дубль или пропуск фискализации.

Как проверить всё разом

После настройки нескольких систем недостаточно «нажать оплатить» одним способом. Соберите короткий чек-лист сценариев и пройдите каждый как покупатель:

• Физлицо, доставка курьером, сумма в среднем диапазоне — видит карту, СБП, «при получении».
• Юрлицо — видит только «счёт», без онлайн-эквайринга.
• Заказ ниже/выше порога рассрочки — способ появляется и исчезает корректно.
• Самовывоз против курьера — «оплата при получении» ведёт себя по правилам.

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

Итог

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

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