Зачем интернет-магазину на 1С-Битрикс собственная система приёма платежей
Владелец бизнеса, который заказывает интернет-магазин на 1С-Битрикс, обычно думает о каталоге, дизайне и удобстве оформления заказа. Приём оплаты откладывается на потом — «подключим эквайринг перед запуском». На практике именно эта задержка чаще всего срывает сроки запуска: банки и платёжные сервисы проверяют документы, сайт и модель бизнеса не за один день, а интеграция платёжного модуля требует тестирования на реальных транзакциях, а не только в демо-режиме.
В Казахстане ситуация усложняется тем, что покупатель ожидает увидеть на сайте привычные способы оплаты: банковскую карту через Halyk Bank, Kaspi Pay или Kaspi QR, иногда рассрочку. Если магазин предлагает только банковский перевод по счёту или просит написать в WhatsApp «для уточнения оплаты», часть покупателей просто уходит к конкуренту, у которого оплата занимает пятнадцать секунд. Для B2B-сегмента ситуация немного иная: там чаще нужен счёт на оплату и работа с юридическими лицами, но и здесь онлайн-эквайринг для частных клиентов и малого опта становится нормой, а не опцией.
1С-Битрикс изначально проектировался с расчётом на то, что способов оплаты будет много и они будут меняться. Поэтому оплату в системе не «зашивают» в код магазина, а подключают через отдельный механизм — модуль оплаты. Это отличает грамотно сделанный магазин на Битрикс от сайта, где оплата встроена руками программиста как разовое решение: в первом случае добавить новый способ оплаты или отключить старый — вопрос настройки, во втором — новая доработка с рисками что-то сломать.
Как устроена оплата в 1С-Битрикс: модуль интернет-магазина и обработчики платёжных систем
За работу с деньгами в 1С-Битрикс отвечает модуль интернет-магазина (Sale). Внутри него каждая платёжная система подключается как отдельный обработчик платёжной системы, программный компонент, который знает, как сформировать запрос к конкретному банку или сервису, как принять и проверить ответ, и как перевести заказ в статус «Оплачен». Настройка обработчиков делается в административной панели, в разделе, отвечающем за способы оплаты. Там для каждой платёжной системы задаются собственные параметры: идентификатор продавца, секретные ключи, тестовый или боевой режим, а также правила, для каких заказов и покупателей этот способ оплаты доступен.
Такая архитектура даёт бизнесу гибкость: можно подключить сразу несколько платёжных систем и показывать покупателю только релевантные для его региона или суммы заказа, можно временно отключить способ оплаты на время технических работ у банка, не трогая остальной код магазина. Для разработчика это тоже удобно: обработчик платёжной системы пишется по понятному интерфейсу, а грамотно написанный модуль переживает обновления ядра Битрикс, потому что не лезет в чужой код и работает через предусмотренные системой точки расширения.
Поэтому важно, кто именно подключает оплату на сайте. Готовый модуль с маркетплейса решает типовые сценарии быстро, но кастомные бизнес-процессы (например, автоматическая привязка способа оплаты к статусу клиента в CRM, частичная предоплата с последующей доплатой или единая логика для сайта и мобильного приложения) требуют доработки обработчика под конкретный проект. Это и есть разница между «просто вставить виджет оплаты» и полноценной интеграцией, которая учитывает весь путь заказа от корзины до бухгалтерии.
Halyk Bank ePay: базовый вариант интернет-эквайринга
Для приёма оплаты банковскими картами в Казахстане чаще всего используют интернет-эквайринг ePay от Halyk Bank. Чтобы подключить его, бизнесу (юридическому лицу или ИП) нужно оформить пакет документов и подписать договор с банком; на сайте у продавца должна быть размещена публичная оферта, описывающая условия продажи товаров или услуг. Заявку на подключение можно подать через сайт банка или обратиться в отделение.
После подписания договора и получения доступа к личному кабинету продавца остаётся техническая часть: подключить платёжный модуль к сайту. Для 1С-Битрикс это делается через обработчик платёжной системы: в кабинете разработчика магазина указываются полученные от банка идентификаторы и ключи, после чего проводится тестовая оплата в режиме, который банк выделяет специально для проверки интеграции перед переводом магазина в боевой режим. Пропускать этот шаг рискованно: ошибка в обработке ответа от банка на боевых деньгах превращается в спор с клиентом и возврат средств, а не просто в лог с ошибкой.
Отдельно стоит спланировать, кто будет вести переписку с банком на этапе подключения: обычно это занимает не один день, потому что банк проверяет сайт, модель бизнеса и соответствие требованиям безопасности платежей. Разработчику стоит закладывать это время в план запуска магазина, а не рассчитывать, что эквайринг подключится «за час перед стартом».
Kaspi Pay: второй обязательный способ оплаты для казахстанского рынка
Игнорировать Kaspi.kz в казахстанском интернет-магазине — значит терять заметную долю покупателей, привыкших платить через приложение Kaspi. Подключение начинается с открытия бизнес-аккаунта Kaspi для приёма платежей и подписания оферты на пользование сервисом Kaspi Pay в личном кабинете продавца. Важный момент, который часто упускают на этапе планирования: не все категории товаров одобряются автоматически, например табачная и алкогольная продукция, а также ряд услуг попадают под ограничения, и это стоит уточнить у Kaspi до начала интеграции, а не после того, как сайт готов.
Техническая интеграция строится на API: в личном кабинете продавца в разделе настроек генерируется API-токен, который используется для авторизации запросов. Дальше сценарий работы простой по логике, хотя и требует аккуратной реализации: сайт создаёт счёт на оплату через запрос к API Kaspi, покупатель получает уведомление в приложении Kaspi и подтверждает оплату там, а сайт должен корректно отследить смену статуса заказа и не «потерять» оплаченный заказ, если покупатель закрыл вкладку браузера, не дождавшись возврата на сайт.
Этот момент, надёжная обработка уведомлений об оплате независимо от того, вернулся ли покупатель на сайт, чаще всего страдает в самодельных интеграциях. Грамотно сделанный обработчик платёжной системы в 1С-Битрикс проверяет статус оплаты не только по факту возврата пользователя, но и по серверному уведомлению от платёжной системы, что исключает ситуацию «клиент оплатил, а заказ в системе так и остался неоплаченным».
Для агентства, которое ведёт разработку и поддержку сайта, Kaspi Pay и Halyk ePay обычно подключаются одним пакетом работ вместе с базовой настройкой каталога и заказов. Так у бизнеса сразу есть два основных способа оплаты, покрывающих большую часть аудитории.
Готовые модули с маркетплейса или разработка под конкретный проект
На маркетплейсе 1С-Битрикс и у сторонних разработчиков есть готовые платёжные модули: от решений для приёма карт через Halyk Bank и других банков до модулей для CloudPayments, Яндекс Пэй и специализированных «касс» для сайта. Для типового интернет-магазина с простым процессом заказа готовый модуль — разумный выбор: он ускоряет запуск и снимает часть ответственности за обновления, потому что модуль поддерживается его автором.
Проблема начинается там, где бизнес-процесс сложнее типового сценария «положил в корзину — оплатил картой». Частая ситуация в B2B: часть клиентов должна видеть только оплату по счёту с отсрочкой, часть — только предоплату картой, а розничные клиенты — Kaspi Pay в одно касание. Готовый модуль редко умеет различать такие сценарии из коробки, и здесь нужна донастройка обработчика платёжной системы под правила конкретного бизнеса: привязка способов оплаты к группам пользователей, сумме заказа, региону доставки или статусу клиента в CRM.
Ещё один сценарий, где типового решения недостаточно, — интеграция оплаты с 1С:Бухгалтерией или другой учётной системой, когда статус оплаты заказа на сайте должен автоматически синхронизироваться с проведением документа в бухгалтерии, без ручной сверки. Это уже не задача «поставить плагин», а полноценная интеграционная работа, которую стоит поручать команде, знакомой и с архитектурой Битрикс, и с особенностями казахстанских платёжных API. Если у вас уже есть сайт на 1С-Битрикс и нужно подключить или донастроить приём платежей под реальные бизнес-правила, для этого стоит привлекать команду, которая занимается разработкой сайтов на 1С-Битрикс именно с прицелом на такие интеграции, а не разовую установку готового плагина.
Как выглядит подключение на практике: иллюстративный пример
Чтобы связать всё сказанное выше в единую картину, разберём условный пример: не конкретный кейс из практики агентства, а типичную последовательность шагов, через которую проходит владелец интернет-магазина на 1С-Битрикс, решивший навести порядок с приёмом оплаты.
Компания продаёт стройматериалы оптом и в розницу через сайт на 1С-Битрикс. Розничные заказы раньше оплачивались только переводом на карту по номеру телефона, который менеджер присылал в WhatsApp после звонка. Способ рабочий, но медленный и неудобный для клиента, а главное, требующий участия человека в каждой сделке. Оптовые клиенты работали по счетам с отсрочкой платежа через бухгалтерию.
Первым шагом владелец бизнеса оформляет документы на подключение интернет-эквайринга Halyk Bank ePay и параллельно открывает бизнес-аккаунт для приёма Kaspi Pay. Эти два процесса можно вести одновременно, они не зависят друг от друга. Пока идёт согласование с банком и Kaspi, разработчик готовит сайт: проверяет, что в модуле интернет-магазина корректно настроены статусы заказов, и продумывает логику, по которой розничные покупатели увидят кнопки оплаты картой и Kaspi Pay, а оптовые клиенты с признаком «юридическое лицо» в профиле — только выставление счёта, без онлайн-оплаты.
Когда банк и Kaspi выдают доступы, разработчик подключает соответствующие обработчики платёжных систем, вносит идентификаторы и ключи и проводит тестовые платежи в выделенном для этого режиме: сначала успешный сценарий, затем отклонённый платёж, чтобы убедиться, что заказ в этом случае не помечается как оплаченный ошибочно. После успешных тестов способы оплаты переводятся в боевой режим, и уже на реальных заказах владелец бизнеса видит, что доля клиентов, доходящих до оплаты, ощутимо выросла, просто потому что оплата больше не требует переписки с менеджером в мессенджере.
Этот пример нарочно упрощён: в реальности к нему добавляются частности конкретного бизнеса, работа с промокодами, частичная предоплата, возвраты. Но сама последовательность действий: документы с банком и Kaspi, настройка обработчиков, тестовые платежи, поэтапный перевод в боевой режим, остаётся одинаковой для большинства интернет-магазинов на 1С-Битрикс.
Как спланировать бюджет и сроки на интеграцию оплаты
Итоговая стоимость и сроки работ по подключению платёжных систем зависят от нескольких факторов, и на этапе постановки задачи разработчику стоит заранее проговорить каждый из них, чтобы не столкнуться с неожиданным расширением объёма работ на середине проекта.
Во-первых, количество способов оплаты. Подключение одного обработчика (например, только Kaspi Pay) — задача заметно более быстрая, чем одновременная настройка двух-трёх платёжных систем с разной логикой доступности для разных групп клиентов.
Во-вторых, сложность бизнес-правил. Если оплата нужна в простом сценарии «один способ для всех», это близко к установке готового модуля. Если же способ оплаты должен зависеть от типа клиента, суммы заказа, региона доставки или наличия отсрочки платежа — это уже кастомная доработка обработчика платёжной системы, которая требует больше времени на проектирование логики и тестирование граничных случаев.
В-третьих, интеграция с внешними системами. Если статус оплаты должен автоматически попадать в 1С:Бухгалтерию, CRM или систему складского учёта, объём работ увеличивается за счёт настройки обмена данными между системами — это отдельный пласт задач, который стоит обсуждать вместе с подключением самой оплаты, а не после того, как оплата уже работает изолированно.
В-четвёртых, состояние самого сайта. Если магазин на 1С-Битрикс давно не обновлялся или изначально был собран с нарушением стандартной архитектуры модуля интернет-магазина, часть времени уйдёт не на саму интеграцию оплаты, а на приведение существующего кода в состояние, пригодное для безопасного добавления нового обработчика платёжной системы.
Закладывать в план стоит не только разработку, но и время на взаимодействие с банком и Kaspi — это внешний процесс, который агентство не может ускорить своими силами, и его лучше начинать параллельно с разработкой, а не после её завершения.
На что обратить внимание при внедрении оплаты
Тестовый режим не заменяет реальную тестовую оплату. Прежде чем переводить магазин в боевой режим, стоит провести несколько настоящих транзакций на небольшую сумму: успешную оплату, отклонённую оплату и, по возможности, возврат средств. Это вскрывает ошибки, которые не видны на синтетических тестах.
Обработка статусов заказа должна быть однозначной. Заказ, который завис в промежуточном статусе «ожидает оплаты» из-за сбоя на стороне платёжной системы, требует чёткого регламента: через сколько часов менеджер должен связаться с клиентом, кто отвечает за ручную сверку с банком или Kaspi при спорной ситуации. Это стоит прописать ещё до запуска, а не изобретать на ходу при первой жалобе клиента.
Отдельная тема — безопасность хранения реквизитов. Правильно спроектированная интеграция не хранит на сервере магазина полные номера карт и другие чувствительные данные: эта ответственность лежит на стороне банка или платёжного сервиса, а сайт работает только с токенами и статусами операций. Если подрядчик предлагает «упростить» интеграцию, сохраняя платёжные данные напрямую в базе сайта, это повод насторожиться и уточнить, какому стандарту безопасности соответствует такое решение.
Не стоит забывать и про мобильную версию сайта. Значительная доля оплат в Казахстане проходит с телефона, часто прямо из приложения Kaspi или через переход по ссылке из мессенджера. Форма оплаты и статус заказа должны корректно отображаться на маленьком экране, а редирект в платёжное приложение и обратно на сайт — работать без зависаний.
Полезно иметь план на случай недоступности платёжной системы. У любого банка и любого платёжного сервиса случаются технические перерывы. Если на сайте подключён только один способ оплаты, в момент сбоя магазин физически не может принимать заказы. Второй независимый способ оплаты — это не избыточность, а запас прочности бизнеса на случай внешних сбоев, которые владелец сайта не контролирует.
Частые вопросы
Сколько времени занимает подключение платёжной системы к сайту на 1С-Битрикс?
Техническая часть, настройка обработчика платёжной системы и тестовые платежи, обычно занимает от нескольких дней до недели. Дольше всего длится согласование с банком или Kaspi: оформление документов, договора и проверка сайта, что зависит уже не от разработчика, а от регламента конкретного банка или сервиса.
Можно ли подключить сразу несколько способов оплаты: и Halyk ePay, и Kaspi Pay?
Да, архитектура модуля оплаты 1С-Битрикс изначально рассчитана на несколько одновременно работающих обработчиков платёжных систем. Можно показывать покупателю оба варианта или ограничивать доступность способа оплаты по региону, сумме заказа или типу клиента.
Нужно ли отдельно дорабатывать сайт, если магазин уже работает на готовом платёжном модуле с маркетплейса, а бизнес-процессы усложнились?
Часто да. Готовые модули покрывают типовой сценарий оплаты, но не умеют, например, различать оптовых и розничных клиентов или синхронизировать статус оплаты с учётной системой. В таких случаях обработчик платёжной системы дорабатывается под конкретные правила бизнеса.
Что происходит, если клиент оплатил заказ через Kaspi, но не вернулся на сайт?
При корректно настроенной интеграции статус заказа обновляется на основании серверного уведомления от платёжной системы, а не только по факту возврата клиента в браузер. Поэтому оплата фиксируется независимо от того, закрыл ли покупатель вкладку сайта сразу после оплаты в приложении.
Подходит ли Kaspi Pay для любых товаров и услуг?
Нет, ряд категорий, например табачная и алкогольная продукция и некоторые виды услуг, подпадает под ограничения. Это стоит уточнить у Kaspi на этапе подключения бизнес-аккаунта, до того как проектировать интеграцию под конкретный каталог.