Приём онлайн-оплаты — это тот момент, где ошибки стоят реальных денег. Заказ оплачен, а статус не сменился; чек пробит неправильно и не проходит по 54-ФЗ; кто-то подделал уведомление и пометил заказ оплаченным без денег. Robokassa — популярный агрегатор, который закрывает множество способов оплаты одним подключением, но подключить его нужно правильно, иначе перечисленные проблемы прилетают в первый же день.
Эта статья — практическое руководство, как подключить приём оплаты через Robokassa к интернет-магазину на 1С-Битрикс: настройка платёжной системы, контрольные подписи, обработка уведомлений, фискализация по 54-ФЗ и проверка. Подключение платёжных агрегаторов — часть нашей услуги интеграции с CloudPayments и Robokassa.
Коротко
- Для Robokassa в 1С-Битрикс есть готовый обработчик платёжной системы — интеграцию с нуля писать обычно не нужно.
- Ключевое — контрольные подписи (Password 1 и 2) и корректная обработка уведомления на ResultURL.
- Заказ помечается оплаченным по серверному ResultURL, а не по странице SuccessURL.
- Фискализация по 54-ФЗ требует передавать состав заказа с ценами и ставками НДС.
Что даёт Robokassa магазину
Robokassa — платёжный агрегатор: одно подключение открывает магазину сразу множество способов оплаты — банковские карты, электронные кошельки, оплата по QR и другие. Вместо того чтобы интегрировать каждый банк и сервис по отдельности, магазин подключает один агрегатор и получает широкий набор методов оплаты.
Для интернет-магазина на 1С-Битрикс это удобно вдвойне: агрегатор берёт на себя маршрутизацию платежей и часть требований по безопасности, а фискализация по 54-ФЗ решается в рамках того же подключения. Задача магазина — корректно сформировать платёж, принять и проверить уведомление об оплате и отразить статус в заказе и учёте.
Как устроена оплата: схема
Чтобы правильно настроить подключение, важно понимать поток данных. Оплата через Robokassa проходит по такой схеме:
- Формирование платежа. Магазин создаёт заказ и формирует ссылку на оплату с параметрами (сумма, номер заказа) и контрольной подписью.
- Переход на оплату. Покупатель уходит на страницу Robokassa и выбирает способ оплаты.
- Уведомление на ResultURL. После успешной оплаты Robokassa шлёт серверное уведомление на ResultURL магазина.
- Проверка и статус. Магазин проверяет подпись, помечает заказ оплаченным и отвечает подтверждающей строкой.
- Возврат покупателя. Покупатель возвращается на SuccessURL (успех) или FailURL (отказ).
Что подготовить до подключения
Перед настройкой в Битрикс соберите всё необходимое, чтобы не прерываться на полпути:
- Регистрация в Robokassa. Магазин зарегистрирован, идентификатор магазина (login) получен.
- Пароли. Password 1 и Password 2 из личного кабинета Robokassa.
- Договор и фискализация. Согласованы условия и параметры фискализации по 54-ФЗ.
- Доступный сайт. ResultURL должен быть доступен извне по HTTPS, без закрытия авторизацией.
- Тестовые доступы. Тестовый режим для прогона оплаты без реальных денег.
Настройка платёжной системы в Битрикс
Приём оплаты в 1С-Битрикс настраивается в модуле «Интернет-магазин», раздел «Платёжные системы». Robokassa подключается как обработчик платёжной системы — штатный или установленный из маркетплейса.
- Добавьте платёжную систему. Создайте новую платёжную систему и выберите обработчик Robokassa.
- Пропишите реквизиты. Идентификатор магазина, Password 1 и Password 2 в соответствующие поля обработчика.
- Свяжите со способами оплаты. Привяжите платёжную систему к нужным типам плательщиков и способам оплаты.
- Настройте фискализацию. Укажите параметры чека: ставки НДС, признак предмета и способа расчёта.
- Задайте адреса возврата. SuccessURL и FailURL — страницы результата для покупателя.
Названия полей зависят от версии обработчика, но логика одинакова: реквизиты магазина, пароли, фискализация и адреса. Наличие товаров и цены в заказе при этом должны быть корректны — они уходят и в чек.
Пароли и контрольные подписи
Безопасность Robokassa строится на контрольных подписях, и это самая важная для понимания часть. Используются два пароля с разным назначением:
| Пароль | Где применяется | Назначение |
|---|---|---|
| Password 1 | Формирование ссылки на оплату | Подпись исходящего запроса на оплату |
| Password 2 | Проверка уведомления на ResultURL | Подтверждение подлинности оплаты |
Подпись — это хеш (контрольная сумма) от параметров платежа и соответствующего пароля. При формировании оплаты магазин подписывает запрос Password 1; при получении уведомления — проверяет подпись через Password 2, пересчитывая хеш и сравнивая с присланным. Оба пароля хранятся только на сервере и никогда не попадают во фронтенд. Механику подобных подписей и защиты серверных вызовов мы разбирали в материале про REST, вебхуки и безопасность в Битрикс.
ResultURL, SuccessURL и FailURL
Три адреса определяют, как магазин узнаёт об оплате и куда возвращается покупатель. Путать их роли нельзя.
- ResultURL. Серверный адрес для уведомлений от Robokassa. Именно здесь магазин проверяет подпись, помечает заказ оплаченным и отвечает подтверждающей строкой. Главный источник истины.
- SuccessURL. Страница, куда возвращается покупатель после успешной оплаты. Она информирует человека, но не должна быть местом смены статуса заказа.
- FailURL. Страница при отказе или отмене оплаты с возможностью повторить попытку.
Классическая ошибка новичков — помечать заказ оплаченным на SuccessURL. Покупатель может не дойти до неё (закрыл вкладку, потерял связь), и тогда оплаченный заказ останется в статусе «ожидает оплаты». Статус меняют строго по ResultURL.
Фискализация по 54-ФЗ
При оплате физическим лицом закон 54-ФЗ требует пробить кассовый чек. Robokassa поддерживает фискализацию, но чек будет верным только если магазин корректно передаёт состав заказа.
- Позиции заказа. В запрос на оплату передаются товары с наименованиями, ценами и количеством.
- Ставки НДС. Для каждой позиции указывается корректная ставка налога.
- Признаки расчёта. Признак предмета расчёта (товар, услуга) и способа расчёта (полная оплата, предоплата).
- Соответствие сумме. Сумма чека по позициям должна совпадать с суммой платежа.
Ошибки в фискализации — цены, НДС или состав не совпадают с реальной продажей — приводят к некорректным чекам и претензиям. Данные для чека в идеале берут из учётной системы, чтобы они соответствовали реальной продаже; это зона ответственности связки с 1С.
Тестовый режим и проверка
Запускать приём платежей в бой без теста нельзя. Robokassa даёт тестовый режим, в котором проходят весь путь оплаты без реальных денег. Прогнать нужно все сценарии:
- Успешная оплата. Формирование ссылки, оплата, уведомление на ResultURL, смена статуса заказа.
- Отказ. Отмена оплаты и возврат на FailURL, заказ остаётся неоплаченным.
- Повторное уведомление. Robokassa может прислать уведомление дважды — обработчик должен быть идемпотентным.
- Корректность чека. Проверить, что позиции, цены и НДС в чеке верны.
- Доступность ResultURL. Убедиться, что адрес доступен извне и отвечает подтверждающей строкой.
Безопасность приёма платежей
Приём денег — привлекательная цель для злоумышленников, поэтому безопасность здесь не опциональна.
- Проверка подписи обязательна. Без проверки Password 2 злоумышленник может подделать уведомление и пометить заказ оплаченным.
- Сверка суммы и заказа. Проверяйте, что сумма и номер заказа в уведомлении совпадают с ожидаемыми.
- Идемпотентность. Повторное уведомление по оплаченному заказу не должно ломать логику или дублировать оплату.
- Секреты на сервере. Пароли и ключи хранятся только на сервере, HTTPS обязателен, ResultURL не закрыт авторизацией.
Связка с заказами и 1С
Оплата — не конец цепочки. Оплаченный заказ должен корректно отразиться в учёте, а статусы оплаты — быть согласованы между сайтом и 1С.
- Статус оплаты в заказе. После проверки уведомления заказ помечается оплаченным, запускается обработка (сборка, отгрузка).
- Отражение в 1С. Заказ и факт оплаты уходят в учётную систему обменом, чтобы бухгалтерия и склад видели реальную картину.
- Согласованность чеков. Данные чека соответствуют продаже в учёте.
- Обработка сбоев. Если обмен с 1С временно недоступен, оплаченный заказ не должен теряться — нужна очередь и повтор.
Устойчивость всей связки зависит и от инфраструктуры: чтобы ResultURL стабильно принимал уведомления, площадка должна быть доступной и быстрой — об этом в статье про хостинг и инфраструктуру BitrixVM. А если приём платежей выкатывается на живой магазин, важен аккуратный процесс деплоя — см. CI/CD и деплой Битрикс.
Частые ошибки
- Статус по SuccessURL. Заказ помечают оплаченным на странице возврата, а не по ResultURL — часть оплат теряется.
- Нет проверки подписи. Уведомление принимается без Password 2 — дыра в безопасности.
- ResultURL недоступен. Адрес закрыт авторизацией или файрволом, уведомления не доходят.
- Не идемпотентный обработчик. Повторное уведомление ломает логику или дублирует оплату.
- Кривая фискализация. Состав, цены или НДС в чеке не совпадают с продажей.
- Запуск без теста. Приём денег включён в бой без прогона тестовых сценариев.
- Пароли во фронтенде. Секреты попали в клиентский код — прямая угроза.
Чек-лист подключения
- Реквизиты собраны. Идентификатор магазина, Password 1 и Password 2 получены.
- Обработчик настроен. Платёжная система Robokassa добавлена и привязана к способам оплаты.
- Подписи работают. Формирование оплаты подписано Password 1, уведомления проверяются Password 2.
- Адреса заданы. ResultURL доступен извне и подтверждает уведомление, SuccessURL и FailURL настроены.
- Фискализация верна. Состав заказа, цены, НДС и признаки расчёта передаются корректно.
- Идемпотентность. Повторные уведомления обрабатываются безопасно.
- Тесты пройдены. Успех, отказ, повтор и чек проверены в тестовом режиме.
- Связка с 1С. Статус оплаты и данные заказа корректно отражаются в учёте.
Вывод
Подключить Robokassa к магазину на 1С-Битрикс несложно: для платформы есть готовый обработчик, и интеграцию с нуля обычно писать не нужно. Но дьявол в деталях — в контрольных подписях, обработке уведомления на ResultURL и корректной фискализации. Именно здесь кроются потери оплаченных заказов, проблемы с 54-ФЗ и уязвимости.
Настройте подписи с Password 1 и 2, меняйте статус заказа строго по ResultURL, передавайте корректный состав чека и обязательно прогоните все сценарии в тестовом режиме. И не забудьте про связку с 1С, чтобы оплата отражалась в учёте. Сделанный аккуратно приём платежей работает незаметно — а это и есть признак, что всё сделано правильно.
