Интеграция 1С-Битрикс с платёжными системами

Когда речь заходит о приёме онлайн-оплаты на сайте Битрикс, соблазн понятен: поставить готовый модуль платёжной системы из маркетплейса, вписать ключи и забыть. Иногда это работает — если у вас простой магазин, одна ставка НДС и не нужны ни возвраты, ни подписки, ни сверка. Но на практике приём денег — это не одна кнопка, а цепочка из платежа, фискального чека, статуса оплаты в заказе и сверки с банком. Готовый модуль закрывает только самое начало этой цепочки, и стоит появиться возвратам, рассрочке, регулярным списаниям или нестандартной номенклатуре для чеков, как начинаются проблемы: оплаты не сходятся с заказами, чеки пробиваются не так, платежи задваиваются. Разберём, в чём разница между коробочным модулем и приёмом оплаты под вашу модель, и как мы строим платежи так, чтобы деньги всегда сходились.

Почему оплата срывается и не сходится

Главная боль плохо настроенного приёма оплаты — потерянные деньги и расхождения. Покупатель оформил заказ, но оплата зависла на редиректе, и он ушёл. Деньги списались, а статус на сайт не пришёл, и заказ висит как неоплаченный. Уведомление от платёжной системы пришло дважды, и оплата задвоилась. Чек по 54-ФЗ не пробился, потому что в составе заказа оказалась позиция без ставки НДС. Возврат оформили в кабинете банка, но на сайте он не отразился, и бухгалтерия свела отчёт с ошибкой. Каждое такое расхождение — это либо потерянная продажа, либо недовольный покупатель, либо проблема с налоговой.

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

Чем приём под модель отличается от коробочного модуля

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

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

Российские системы: ЮKassa, банки и агрегаторы

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

Подключение приёма оплаты почти всегда идёт рука об руку с фискализацией по 54-ФЗ, поэтому отдельное внимание мы уделяем онлайн-кассе: регистрации, схеме чеков, ставкам НДС под вашу номенклатуру. Если у вас сложный каталог с разными ставками или маркируемыми товарами, состав чека требует аккуратной настройки. А чтобы оплаты не висели и не терялись, важно, чтобы заказы и статусы корректно ходили между сайтом и учётом — это тесно связано с интеграцией с ERP и CRM, где оплата проставляется в заказе и уходит в учётную систему.

Зарубежные платежи и рекуррентные списания

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

Когда нужен платёжный контур, а когда хватит одной системы

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

Как мы делаем приём оплаты надёжным

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

Возражения, которые мы слышим чаще всего

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

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

Сценарии, под которые мы настраиваем оплату

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

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

Этапы работы по шагам

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

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

С чего начать

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