Подключение ЮKassa, СБП и Т-Кассы в 1С-Битрикс

Покупатель дошёл до оплаты, выбрал способ — и в этот момент решается, станет визит заказом или нет. Если оплата неудобная, медленная или вызывает недоверие, человек уходит с наполненной корзиной. Поэтому приём платежей — это не «техническая галочка», а один из самых чувствительных к деталям узлов магазина. Эта статья — практическое руководство по подключению ЮKassa, оплаты по СБП и Т-Кассы в интернет-магазине на 1С-Битрикс с учётом кассовых чеков по 54-ФЗ.

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

Какие способы оплаты нужны магазину

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

• Оплата картой онлайн. Базовый способ для розницы: покупатель вводит данные карты на защищённой странице провайдера и платит сразу.
• СБП (Система быстрых платежей). Оплата по QR-коду или кнопке через приложение банка, без ввода данных карты. Для покупателя быстрее, для магазина — обычно дешевле по комиссии.
• Оплата при получении. Наличными или картой курьеру / в пункте выдачи. Снимает барьер недоверия, но создаёт риск невыкупа.
• Безналичный счёт для юрлиц. Для B2B: магазин выставляет счёт, организация оплачивает его с расчётного счёта.

Для большинства розничных магазинов разумный минимум — карта + СБП, плюс при необходимости оплата при получении. Для B2B добавляют безналичный счёт. Дальше в статье мы сосредоточимся на онлайн-оплате через ЮKassa и Т-Кассу, потому что именно она вызывает больше всего вопросов по настройке и 54-ФЗ.

Как устроен приём оплаты в 1С-Битрикс

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

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

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

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

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

Договор и доступы к провайдеру

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

Касса по 54-ФЗ

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

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

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

Подключение ЮKassa пошагово

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

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

После этого одно подключение ЮKassa, как правило, даёт сразу несколько способов оплаты внутри себя: карту и СБП. Как именно показать СБП покупателю — в следующем разделе.

Оплата по СБП через QR-код

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

Как это выглядит для покупателя:

1. На шаге оплаты он выбирает «Оплатить по СБП».
2. Сайт показывает QR-код (на десктопе) или кнопку перехода в приложение банка (на мобильном).
3. Покупатель сканирует код приложением своего банка или нажимает кнопку.
4. Подтверждает платёж в приложении — деньги уходят со счёта.
5. Провайдер присылает сайту уведомление об оплате, заказ отмечается оплаченным.

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

Подключение Т-Кассы

Т-Касса — ещё один распространённый платёжный провайдер, который тоже даёт и карту, и СБП, и для него в 1С-Битрикс есть свой обработчик. Логика подключения та же, что у ЮKassa, отличаются только конкретные параметры и личный кабинет.

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

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

Кассовые чеки и 54-ФЗ

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

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

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

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

Уведомления о платеже и статус заказа

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

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

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

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

Тестовый режим: что проверить

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

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

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

Боевые платежи: запуск без сюрпризов

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

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

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

Возвраты и отмены платежей

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

Что важно учесть по возвратам:

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

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

Оплата для юрлиц и B2B

Если среди ваших покупателей есть организации, им часто удобнее платить не картой, а по безналичному расчёту — выставленным счётом с расчётного счёта. Это отдельный сценарий, который сосуществует с онлайн-оплатой картой и СБП.

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

Для магазинов с заметной долей B2B приём оплаты проектируют вместе с разделением плательщиков (физлицо / юрлицо) и привязкой способов оплаты к типу клиента. Это уже соприкасается с темой цен и условий для разных групп — её мы разбираем в материалах про B2B, а реализуем в рамках разработки магазина под нужные сценарии.

Безопасность приёма оплаты

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

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

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

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

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

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

Чек-лист запуска оплаты

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

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

Вывод

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

Запускайте оплату осторожно: сначала тестовый режим со всеми сценариями, потом контрольный реальный платёж на малую сумму с возвратом, и только убедившись, что цепочка работает, — открывайте приём денег всем. Тогда покупатели будут платить удобно и быстро, а вы — без сюрпризов «деньги ушли, а заказа нет». А куда поедет оплаченный заказ дальше — это вопрос доставки, который мы разбираем в материале про расчёт доставки СДЭК, Boxberry и Почты.