Доработка системы оплаты на 1С-Битрикс под ваш эквайринг и кассу

Доработка системы оплаты на 1С-Битрикс — это подключение и тонкая настройка всей платёжной цепочки магазина: от кнопки «Оплатить» на сайте до прихода денег на расчётный счёт и точного статуса оплаты в заказе. Мы работаем с эквайрингом ЮKassa, Т-Банк, Сбербанк и Альфа-Банк, подключаем Систему быстрых платежей по QR-коду, настраиваем рекуррентные списания для подписок, фискализацию чеков по 54-ФЗ, частичную оплату, сплитование выручки между несколькими получателями и корректные возвраты. Задача услуги — сделать так, чтобы деньги не терялись между банком, онлайн-кассой и сайтом, а статус оплаты в заказе всегда отражал реальное положение дел.

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

Что входит в доработку оплаты

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

Основные блоки, которые мы настраиваем и дорабатываем:

• подключение и донастройка эквайринга ЮKassa, Т-Банк, Сбербанк и Альфа-Банк;
• оплата через СБП по QR-коду с возвратом статуса в заказ;
• рекуррентные платежи для подписок и регулярных списаний;
• чеки по 54-ФЗ с корректными ставками НДС, признаками и номенклатурой;
• частичная оплата, предоплата и доплата по одному заказу;
• сплитование выручки между несколькими получателями;
• полные и частичные возвраты с отражением в заказе и кассе;
• надёжная обработка статусов оплаты и колбэков от банка и кассы.

Почему статусы оплаты так важны

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

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

Когда нужна доработка, а когда хватает настроек

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

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

Почему базового модуля оплаты часто не хватает

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

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

Где платёжная цепочка ломается чаще всего

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

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

Третье — нестандартные сценарии расчётов. Рекуррентные списания требуют безопасного хранения привязки карты на стороне банка и аккуратного расписания списаний. Сплитование выручки между получателями — корректного разделения суммы и комиссий. Частичная оплата — связки нескольких платежей с одним заказом. Возвраты — синхронного отражения в заказе, кассе и учёте. Каждый такой сценарий мы продумываем целиком, а не латаем по месту, чтобы он работал предсказуемо и при росте оборота.

Эквайринг ЮKassa, Т-Банк, Сбербанк и Альфа — в чём различия

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

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

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

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

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

Когда нужна доработка, а когда хватит настройки

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

Как мы ведём работу и что гарантируем

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

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

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

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

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

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

С чего начать

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