Платежные системы для сайта в 2026 году: как выбрать и подключить онлайн-оплату

Введение

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

Поэтому выбор платежной системы начинается не с сравнения комиссий и логотипов. Сначала нужно описать сам процесс: какие способы оплаты увидит покупатель, когда заказ считается оплаченным, кто формирует чек, как выполняются возвраты, что происходит при сбое и какие данные должны попасть в 1С или CRM. Уже под эту схему выбирают банк или агрегатор, способ интеграции и набор дополнительных сервисов.

Для типового интернет-магазина обычно достаточно готового модуля или платежного виджета с оплатой картой, СБП и подключенной фискализацией. API-интеграция оправдана, когда проекту нужны:

• подписки и повторные списания;
• частичные оплаты и сложные возвраты;
• несколько юридических лиц;
• собственная логика статусов;
• глубокая связка с 1С, CRM или мобильным приложением.

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

Что такое платежная система для сайта и как работает онлайн-оплата

Чем отличаются интернет-эквайринг, платежный агрегатор и платежный шлюз

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

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

В статье «платежная система для сайта» — общее название решения для приема онлайн-платежей.

Чем платежный сервис отличается от способа оплаты и онлайн-кассы

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

Как проходит платеж от покупателя до бизнеса

Типовой сценарий выглядит так:

1. Сайт создает заказ и передает провайдеру сумму, номер заказа и параметры платежа.
2. Покупатель подтверждает операцию на платежной форме.
3. Провайдер отправляет сайту серверное уведомление о результате.
4. Сайт проверяет уведомление, фиксирует оплату и меняет статус заказа.
5. Касса формирует чек, данные передаются в 1С и CRM.

Страницу «Оплата прошла» нельзя использовать как единственное подтверждение: покупатель может закрыть вкладку или не вернуться на сайт. Статус нужно получать через серверное уведомление. Через тот же механизм отслеживают изменения платежей и возвратов.

Какие процессы можно автоматизировать

Рабочая интеграция:

• обновляет статус заказа;
• резервирует товар или запускает оказание услуги;
• формирует чек и уведомляет покупателя;
• передает оплату в 1С и CRM;
• проводит полный или частичный возврат;
• сохраняет историю для сверки и поддержки.

В 1С-Битрикс взаимодействие магазина с провайдером строится через обработчики платежных систем.

Онлайн-платежи в 2026 году: что изменилось и что нужно проверить

В 2026 году обновления затронули тарифы эквайринга, кассовые чеки и подготовку к новым способам расчета. Их нужно учитывать и при подключении нового сервиса, и при аудите действующей интеграции.

НДС 22% в тарифах, настройках сайта и кассовых чеках

С 1 января 2026 года основная ставка НДС выросла с 20 до 22%. Новое значение должны корректно передавать сайт, учетная система и кассовое ПО. Отдельной проверки требуют переходные операции: возвраты покупок 2025 года, предоплаты, последующая отгрузка и чеки коррекции — ставка в них зависит от даты и типа расчета.

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

Требования к интернет-чекам, действующие в 2026 году

С 1 сентября 2025 года для интернет-расчетов применяются дополнительные реквизиты:

• признак расчета в интернете — тег 1125;
• адрес сайта в реквизите «место расчетов» — тег 1187;
• телефон или email покупателя — тег 1008;
• сведения о безналичной оплате и ее идентификаторах.

Проверять нужно весь состав чека: товарные позиции, доставку, скидки, ставку НДС, тип расчета и возвраты. Ошибка на стороне сайта обычно передается дальше в кассу.

Универсальный QR и цифровой рубль

До 1 сентября 2026 года банки должны подготовить системы к универсальному QR-коду НСПК. Через него покупатель сможет выбирать СБП, банковские платежные сервисы, рассрочку и цифровой рубль. Сроки обязательного подключения к универсальному QR конкретных продавцов определяет Банк России.

Первая волна обязательного приема цифровых рублей начинается 1 сентября 2026 года. Она касается продавцов с выручкой более 120 млн рублей за предыдущий год, если на 1 января 2026 года у них был договор приема электронных средств платежа со значимым на платежном рынке банком. Требование относится к продажам гражданам для личных нужд; компании с выручкой менее 20 млн рублей в обязательный график не входят.

Что проверить в уже работающей платежной интеграции

Проверьте:

• ставку НДС и переходные операции;
• реквизиты интернет-чека;
• порядок расчета комиссии с учетом НДС;
• версии кассового ПО и платежного модуля;
• оплаты, отмены и возвраты;
• применимость требований по цифровому рублю;
• передачу данных в 1С и CRM;
• журналы ошибок и оповещения о сбоях.

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

Какие способы и сценарии оплаты можно подключить на сайте

Набор способов оплаты зависит от модели продаж, среднего чека и момента, когда заказ можно считать выполненным. Одному проекту достаточно карт и СБП, другому нужны подписки, рассрочка, холдирование или несколько платежей по одному заказу.

Оплата банковской картой

При подключении карт проверяют сохранение платежного токена, повторную попытку после отказа, работу 3-D Secure и форму на смартфоне. Карточные реквизиты не должны храниться на стороне сайта: для повторной оплаты используют идентификатор, полученный от провайдера.

СБП и оплата по QR-коду

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

SberPay, T-Pay и другие способы быстрой оплаты

Банковские кнопки позволяют подтвердить операцию без ручного ввода карты. Обычно их добавляют через эквайринг или агрегатор. Проверить нужно работу на разных устройствах, возврат покупателя на сайт и получение финального статуса. Доступный набор — например, SberPay, T-Pay, Mir Pay или Alfa Pay — зависит от провайдера.

Рассрочка, кредит и оплата частями

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

Оплата по ссылке

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

Автоплатежи и рекуррентные списания

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

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

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

Предоплата, частичная оплата и доплата

Для сложных заказов заранее описывают:

• аванс и окончательный расчет;
• несколько платежей по одному заказу;
• доплату после изменения состава;
• частичный возврат по отдельным позициям.

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

Как выбрать платежную систему для сайта

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

Банк или платежный агрегатор: в чем разница

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

Когда имеет смысл подключить несколько провайдеров

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

Учитывайте модель бизнеса и тип покупателей

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

Проверьте ограничения по виду деятельности

До разработки уточните, принимает ли провайдер вашу категорию товаров, какие лицензии потребуются, доступны ли предзаказы и подписки. Банки проверяют клиента, расчетный счет, сайт и ассортимент до подключения.

Определите обязательные платежные сценарии

Зафиксируйте функции, без которых процесс не работает:

• карты, СБП и банковские кнопки;
• полные и частичные возвраты;
• одностадийная или двухстадийная оплата;
• рекуррентные списания;
• несколько платежей по заказу;
• несколько юридических лиц;
• передача данных в кассу, 1С и CRM.

Возможности API и готового модуля проверяют отдельно: провайдер может поддерживать операцию, которую модуль CMS не передает в заказ.

Считайте полную стоимость, а не только комиссию

Используйте формулу:

комиссия + НДС + фискализация и ОФД + разработка + сопровождение + возвраты и спорные операции.

Тарифы зависят от способа оплаты, оборота и сферы бизнеса. В 2026 году отдельно проверяйте НДС: некоторые сервисы публикуют комиссию без налога.

Какие условия договора проверить перед подключением эквайринга

Помимо ставки, проверьте:

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

Срок возмещения может различаться по способам оплаты.

Оцените работу с онлайн-кассой

Уточните, кто формирует чек и как передаются позиции, НДС, скидки, доставка и маркировка. Проверьте предоплату, полный расчет, частичный возврат и чек коррекции. Встроенная фискализация упрощает схему, если ее возможности соответствуют процессам магазина.

Проверьте техническую совместимость

Наличия API или модуля CMS недостаточно. Нужны:

• актуальная версия и поддержка модуля;
• тестовый контур;
• вебхуки и их повторная отправка;
• журналы операций;
• документация по статусам и возвратам;
• совместимость с 1С, CRM и кассой.

В Marketplace 1С-Битрикс представлены десятки платежных решений, но набор функций и сопровождение различаются.

Оцените надежность и поддержку

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

Посмотрите на платежную форму глазами покупателя

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

Сравнение платежных сервисов для сайта в 2026 году

Условия в таблице проверены 17 июля 2026 года по официальным сайтам и документации провайдеров. Указаны публичные ставки для стандартных сценариев. Индивидуальные предложения зависят от оборота, отрасли, способов оплаты и набора дополнительных услуг.

Как мы сравнивали сервисы

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

Какой сервис подойдет для разных бизнес-задач

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

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

Крупному магазину или платформе стоит запросить индивидуальные условия у двух-трех провайдеров и проверить:

• ставку отдельно по картам, СБП и Pay-методам;
• НДС и стоимость фискализации;
• сроки зачисления и ограничения по возвратам;
• SLA, журналы уведомлений и порядок разбора спорных операций;
• стоимость резервного провайдера или маршрутизации платежей.

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

Что нужно для подключения платежной системы: требования к бизнесу и сайту

До интеграции проверяют документы, фискализацию и логику заказов. Иначе ограничения провайдера обнаружатся после начала разработки.

Документы и информация о компании

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

Какие страницы должны быть на сайте

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

• реквизиты и контакты;
• описания товаров или услуг с ценами;
• условия оплаты и доставки;
• правила отмены, обмена и возврата;
• публичную оферту;
• политику обработки персональных данных и согласия.

Онлайн-касса и фискализация

Заранее определяют, кто формирует чек: сервис провайдера, облачная касса партнера или собственная ККТ. В техническом задании фиксируют передачу позиций заказа, скидок, доставки, НДС, способа расчета и контакта покупателя. Для интернет-расчетов также передаются адрес сайта и признак онлайн-продажи.

Платежные сценарии и статусы заказов

До настройки модуля или API согласуют состояния заказа:

• ожидает оплаты;
• оплата начата;
• средства заблокированы;
• оплачен;
• отменен;
• возвращен полностью или частично;
• требует ручной проверки.

Отдельно описывают повторную оплату, задержку уведомления, расхождение суммы и недоступность кассы, 1С или CRM.

Распределение зон ответственности

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

Критерии приемки интеграции

Работу принимают по проверяемым условиям:

• платеж корректно меняет статус заказа;
• повторное уведомление не создает дубль;
• чек содержит правильные позиции и налоги;
• полный и частичный возвраты проходят по всей цепочке;
• данные поступают в 1С и CRM;
• ошибки фиксируются в журнале и передаются ответственному.

Тестовый контур, доступы и ответственные

Интеграцию выполняют на тестовой копии сайта с отдельными ключами. До запуска фиксируют владельцев доступов, порядок их смены, журналы, сценарий отката и ответственного за первые операции.

Способы интеграции онлайн-оплаты: ссылка, виджет, модуль или API

Способ интеграции определяет, какая часть платежной логики остается у провайдера, а какая реализуется на сайте. Варианты пересекаются: модуль CMS может работать через API и переводить покупателя на готовую страницу, а виджет требует серверного создания платежа и обработки статуса.

Оплата по ссылке без прямой интеграции

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

Переход на платежную страницу сервиса

Сайт создает платеж и перенаправляет покупателя на страницу провайдера. После подтверждения пользователь возвращается к заказу, а окончательный статус приходит серверным уведомлением. Запуск занимает меньше времени, но оформление и поведение формы ограничены возможностями сервиса.

Платежный виджет на сайте

Виджет встраивается в страницу или открывается поверх нее. Провайдер обслуживает поля оплаты и доступные способы, сайт управляет заказом, статусами и событиями. Внешний вид настраивается частично; нестандартное оформление заказа потребует дополнительной разработки.

Готовый модуль для CMS

Модуль связывает сервис с моделью заказа CMS: передает сумму и корзину, принимает уведомления, меняет статусы, иногда поддерживает чеки и возвраты. Проверяют дату обновления, совместимость и реализованные сценарии. Модуль из каталога может не учитывать измененную корзину, несколько юрлиц или обмен с 1С.

Интеграция через API

API выбирают для подписок, нескольких платежей по заказу, сложных возвратов, личных кабинетов и нестандартных статусов. Разработка включает вебхуки, защиту от дублей, журналы, повторную обработку ошибок и тестирование.

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

Сколько стоит подключить онлайн-оплату и от чего зависят сроки

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

Стоимость подключения готового модуля

В типовом проекте нужны установка, настройка кабинета, сопоставление способов оплаты и статусов, подключение кассы и проверка заказов. Оценка растет, если корзина изменена или модуль не поддерживает нужный сценарий.

Стоимость интеграции через API

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

Что увеличивает трудоемкость

На стоимость сильнее всего влияют:

• несколько юрлиц или провайдеров;
• подписки, холдирование и частичные оплаты;
• маркировка и сложная фискализация;
• синхронизация с 1С, CRM и складом;
• устаревшая CMS или измененный код;
• высокая нагрузка и резервный сценарий.

От чего зависят сроки подключения

Календарный срок включает проверку бизнеса провайдером, получение доступов, настройку кассы, согласование сценариев, тесты и приемку. Задержки чаще возникают, когда документы, статусы заказов и ответственные не определены до старта.

Почему стоимость интеграции не равна стоимости кнопки оплаты

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

Как подключить онлайн-оплату на сайт: пошаговая инструкция

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

Шаг 1. Описать платежные и бизнес-сценарии

Зафиксируйте, что происходит с заказом от оформления до закрытия:

• способы и момент оплаты;
• повторная попытка;
• блокировка и подтверждение списания;
• полная и частичная отмена;
• возвраты и чеки;
• передача статусов в 1С, CRM и на склад.

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

Шаг 2. Выбрать провайдера и способ интеграции

Сопоставьте обязательные сценарии с возможностями банка или агрегатора. Отдельно проверьте готовый модуль: функция может поддерживаться в API сервиса, но отсутствовать в решении для CMS. Здесь же выбирают платежную страницу, виджет, модуль или самостоятельную интеграцию.

Шаг 3. Заключить договор и настроить фискализацию

После проверки бизнеса провайдер выдает тестовые и рабочие доступы. Параллельно подключают онлайн-кассу и определяют, какие данные передает сайт: позиции заказа, количество, скидки, доставку, НДС, способ расчета и контакт покупателя.

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

Шаг 4. Реализовать платежную логику

Создание платежа. Сайт передает сумму, уникальный номер заказа, описание, параметры сценария и данные для чека. Адреса успешного и неуспешного возврата управляют навигацией, отдельный URL уведомлений используется для получения статуса.

Обработка статуса. После серверного уведомления система проверяет идентификатор, сумму и состояние платежа, затем меняет заказ и запускает связанные процессы.

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

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

Шаг 5. Связать оплату с 1С, CRM и аналитикой

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

Шаг 6. Протестировать платежные сценарии

Проверяют успешную оплату, отказ, закрытие формы, задержку и повтор уведомления, возврат, ошибку кассы и недоступность 1С. Провайдеры предоставляют тестовые терминалы и сценарии для обычных платежей, автоплатежей и чеков.

Шаг 7. Запустить оплату и настроить мониторинг

Перед запуском заменяют тестовые ключи рабочими и проводят контрольную операцию. Первые платежи сверяют по всей цепочке: заказ, провайдер, чек, 1С и поступление. Затем настраивают оповещения о необработанных уведомлениях, ошибках кассы и расхождении статусов.

Как подключить платежную систему к сайту на 1С-Битрикс

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

Готовый модуль или собственный платежный обработчик

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

• несколько оплат по одному заказу;
• холдирование и частичное списание;
• подписки;
• несколько юридических лиц;
• нестандартную корзину или глубокий обмен с внутренними системами.

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

Что проверить перед установкой модуля

Наличие решения в Marketplace не подтверждает его пригодность для конкретного сайта. Проверьте:

• дату обновления, версии 1С-Битрикс и PHP;
• совместимость с актуальным API провайдера;
• передачу НДС 22%, доставки, скидок и маркировки;
• СБП, двухстадийную оплату, подписки и частичные возвраты;
• проверку уведомлений и защиту от дублей;
• журналы запросов и ошибок;
• совместимость с оформлением заказа и обменом с 1С;
• документацию и поддержку разработчика.

Как настроить платежную систему в 1С-Битрикс

Новую систему создают в разделе «Магазин → Настройки → Платежные системы». В форме выбирают обработчик, указывают параметры доступа и источники значений. Отдельно настраивают типы плательщиков, компанию-получателя, тип оплаты для обмена с 1С и печать чеков. Ограничения позволяют показывать способ только для нужного сайта, покупателя или условий заказа.

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

Как синхронизировать платежи и статусы заказов

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

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

Как связать оплату с обменом 1С

До разработки определяют, какие события передаются в учетную систему:

• платеж создан;
• деньги заблокированы или списаны;
• заказ оплачен полностью или частично;
• выполнена отмена или возврат;
• сумма и статус расходятся.

Для событий задают соответствие документам и статусам в 1С. При недоступности учетной системы сайт сохраняет событие и повторяет отправку позже. Возврат пользователя на страницу успешной оплаты не используют как основание для выгрузки оплаченного заказа. В модели оплаты 1С-Битрикс предусмотрены отдельные поля для идентификатора и состояния документа из 1С.

Как безопасно обновлять модуль и сайт

Обновление проводят на тестовой копии с резервной копией и зафиксированными версиями платформы, модуля и PHP. После установки проверяют:

• карту и СБП;
• успешную и отклоненную оплату;
• повторное уведомление;
• чек и возврат;
• передачу оплаты в 1С.

Для запуска нужен план отката, доступ к журналам и описание доработок. Такая документация упрощает сопровождение и смену подрядчика.

Как настроить отмены, возвраты и спорные платежи

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

Чем отмена платежа отличается от возврата

При двухстадийной оплате отмена снимает блокировку до списания. Возврат проводят после подтвержденной оплаты — полностью или на часть суммы. Доступные операции и статусы зависят от способа оплаты; провайдеру обычно передают исходный идентификатор платежа и сумму.

Как оформить полный и частичный возврат

Заранее определяют, откуда запускается операция: из кабинета провайдера, сайта, 1С или CRM. Автоматический сценарий должен:

1. проверить статус платежа и доступную сумму;
2. создать уникальный запрос;
3. сохранить ответ и дождаться финального статуса;
4. обновить заказ, склад и учет;
5. уведомить покупателя.

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

Как связать возврат с онлайн-кассой

Покупателю формируют чек с признаком расчета «возврат прихода», где отражают возвращенные позиции и сумму. Если в 2026 году возвращают товар, проданный в 2025 году с НДС 20%, в чеке сохраняют ставку исходной продажи.

Статус фискализации контролируют отдельно: провайдер может выполнить возврат, даже если касса не сформировала чек.

Как обрабатывать возвраты в 1С-Битрикс и 1С

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

Что учитывать при спорных операциях

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

Как информировать покупателя

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

Безопасность онлайн-платежей: защита данных, ключей и уведомлений

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

PCI DSS: за что отвечает провайдер, а за что владелец сайта

В 2026 году действует PCI DSS 4.0.1 для сред, где данные карт хранятся, обрабатываются или передаются. Платежная страница или iframe провайдера сокращают объем карточных данных на стороне продавца, но не снимают ответственность за CMS, доступы, скрипты и подключение формы.

Шифрование, токенизация и хранение платежных данных

Для сохраненной карты используют токен провайдера — идентификатор, заменяющий номер карты. Он уменьшает объем чувствительных данных в системах продавца, но не отменяет защиту интеграции. CVV/CVC после авторизации хранить нельзя, включая логи и зашифрованные записи.

Защита ключей и доступов

Минимальный набор мер:

• раздельные тестовые и рабочие ключи;
• хранение секретов вне репозитория и клиентского кода;
• минимальные права сотрудников и подрядчиков;
• журналирование критичных действий;
• смена ключей после утечки или ухода ответственного;
• отключение неиспользуемых учетных записей.

Проверка серверных уведомлений

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

3-D Secure, антифрод и подозрительные операции

EMV 3-D Secure помогает банку аутентифицировать владельца карты и оценить риск. Антифрод дополняют лимитами, контролем частоты операций и ручной проверкой. Жесткие правила могут увеличивать число отказов, поэтому их оценивают вместе с конверсией в успешную оплату.

Защита платежной страницы от подмены

Требования PCI DSS 6.4.3 и 11.6.1, действующие с 31 марта 2025 года, предусматривают учет и авторизацию скриптов платежной страницы, контроль их целостности и выявление изменений. Проверять нужно сторонние скрипты, заголовки безопасности, обновления CMS и шаблон оформления заказа.

Персональные данные покупателя

Телефон, email, адрес и история заказа также требуют защиты. Сайт собирает данные, необходимые для продажи, чека и доставки, ограничивает доступ по ролям и фиксирует их передачу в CRM, 1С и сторонние сервисы.

Логи, мониторинг и план реагирования

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

Как повысить конверсию оплаты и не потерять покупателя

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

Сделайте оплату удобной на смартфоне

Проверьте переход в банковское приложение, возврат на сайт и восстановление заказа после закрытия вкладки. Сумма и кнопка оплаты должны оставаться видимыми.

Показывайте подходящие способы оплаты

Порядок методов определяют с учетом устройства, среднего чека и статистики. На смартфоне выше размещают СБП и банковские кнопки, для дорогих покупок — оплату частями. Недоступные варианты скрывают.

Не заставляйте покупателя повторно вводить данные

Телефон, email, имя и адрес передают из заказа. Повторный ввод создает опечатки и расхождения между сайтом, чеком и CRM. Сохраненную карту используют через токен провайдера и после согласия клиента.

Показывайте итоговую сумму до перехода к оплате

До подтверждения покупатель должен видеть товары, доставку, скидку и график платежей. Изменение суммы при выборе способа оплаты объясняют рядом с ним.

Снижайте тревогу перед вводом платежных данных

На странице сохраняют название продавца, номер заказа, сумму, контакты поддержки и условия возврата. О переходе на домен провайдера предупреждают заранее.

Объясняйте, что произошло при ошибке

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

Не создавайте новый заказ при каждой попытке

Повторную оплату привязывают к существующему заказу, если состав и сумма не изменились. Это сохраняет резерв и сокращает дубли в 1С и CRM.

Настройте аналитику платежной воронки

Отслеживайте:

• переход к оплате и открытие формы;
• выбор способа;
• успешное подтверждение;
• отказ или техническую ошибку;
• повторную попытку и возврат.

Конверсию сравнивают по устройствам, провайдерам и способам оплаты. Интерфейсные гипотезы тестируют после устранения ошибок вебхуков, кассы и обмена данными.

Как протестировать платежную систему перед запуском

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

Матрица тестирования платежной интеграции

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

Что контролировать после запуска онлайн-оплаты

После запуска контролируют всю цепочку: форму, провайдера, кассу, заказ, 1С, CRM и зачисление денег.

Конверсию в успешную оплату

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

Причины отказов

Разделяйте отказ банка, действие покупателя и сбой интеграции. Для анализа нужны категория ошибки, этап воронки, способ оплаты. Статус «не оплачено» не показывает, где теряются заказы.

Работу уведомлений, кассы и интеграций

Мониторинг должен сообщать, если вебхук не обработан, чек не сформирован или событие не передано в 1С и CRM. Временные сбои обрабатывает очередь повторной отправки. В оповещении указывают номер заказа и идентификатор операции.

Сверку заказов, чеков и поступлений

Регулярно сопоставляйте:

• заказы и возвраты на сайте;
• операции провайдера;
• чеки и статусы фискализации;
• документы в 1С;
• поступления на расчетный счет.

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

Обновления модулей и API

Следите за API, ключами и сертификатами, версиями модуля, CMS, PHP и кассового ПО. Обновления сначала проверяют на тестовой копии: модуль связан с корзиной, заказом и обменом данными.

Резервный сценарий оплаты

Для критичных продаж готовят второй канал: резервного провайдера, платежную ссылку или ручное выставление счета. Заранее определяют, кто включает сценарий и как проводится сверка.

Что должен передать разработчик после подключения

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

Как сменить платежный сервис без остановки продаж

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

Что делать, если деньги списались, а заказ не оплачен

Не просите покупателя повторить оплату, пока не установлен финальный статус операции. Сначала проверяют данные у провайдера, затем восстанавливают заказ, чек и обмен с внешними системами.

Деньги списались, но статус заказа не изменился

Найдите платеж по номеру заказа, сумме, времени и идентификатору. Если списание подтверждено, проверьте журнал вебхуков. Причиной может быть недоступность сайта, ошибка подписи, сбой при сохранении заказа или неверное сопоставление статусов.

Порядок действий:

1. запретить повторную оплату;
2. подтвердить статус и сумму у провайдера;
3. безопасно повторить обработку события;
4. проверить чек, резерв, 1С и CRM;
5. сообщить покупателю результат.

Платеж прошел, но чек не сформировался

Оплата и фискализация обрабатываются отдельно. Проверьте запрос к кассе, состав чека, НДС, контакт покупателя и ответ сервиса. После устранения причины повторяют формирование чека, а не платеж.

Произошло повторное списание или двойная обработка

Сравните идентификаторы операций. Если списаний два, лишнюю операцию возвращают. Если вебхук обработался повторно, исправляют защиту от дублей и проверяют, не были ли повторно созданы отгрузка, чек или документ в 1С.

Платеж отменен, но товар остался зарезервирован

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

Недоступен платежный сервис, касса или 1С

Для каждого сбоя нужен согласованный сценарий:

• скрыть недоступный способ оплаты и предложить резервный;
• поставить фискализацию в очередь;
• сохранить событие для повторной передачи в 1С или CRM;
• запросить статус платежа по API, если вебхук не обработан.

Как провести сверку после сбоя

Сопоставьте операции провайдера, заказы, чеки, документы 1С, возвраты и банковские зачисления. Затем зафиксируйте причину, затронутые операции, исправление и профилактическую меру. Такой отчет поможет предотвратить повторный инцидент.

Заключение

Платежную систему выбирают по бизнес-сценариям: способам оплаты, возвратам, фискализации, статусам заказов и обмену с 1С или CRM. До запуска нужно проверить договорные условия, пройти все тестовые сценарии и настроить мониторинг.

Нужно подключить оплату к действующему проекту, исправить ошибки в чеках и статусах или связать платежи с 1С? Оставьте заявку на техническую поддержку сайта на 1С-Битрикс. Если онлайн-оплата закладывается в новый проект, закажите разработку интернет-магазина: спроектируем платежную логику, подключим сервис и кассу, настроим обмен и протестируем возвраты.

Больше практических материалов о разработке, поддержке и продвижении сайтов — в Telegram-канале Profitkit.