Интеграция сайта с платежными системами
Подключаю онлайн-оплату к сайтам на 1С-Битрикс и другим платформам. Настраиваю создание платежа, проверку уведомлений, изменение статуса заказа, возвраты и передачу данных в CRM или 1С.
Услуга нужна, если:
Разберу текущий процесс и предложу решение без лишних функций и сложностей.
Что входит в услугу
Состав работ уточняется после знакомства с задачей, системой и командой.
Анализ текущего сценария оплаты
Проверяю CMS, оформление заказа, выбранного платёжного провайдера, статусы, возвраты и требования к внешним системам.
Проектирование платёжного сценария
Определяю создание платежа, проверку суммы, возврат пользователя, серверные уведомления, повторную оплату и изменение статусов заказа.
Подключение платёжной системы
Настраиваю совместимый модуль или реализую интеграцию через API выбранного провайдера.
Обработка уведомлений и статусов
Проверяю входящие события, сопоставляю их с заказом и защищаю сценарий от повторного выполнения одной операции.
Возвраты и фискализация
При необходимости подключаю согласованные сценарии полного или частичного возврата и передачу данных в поддерживаемую систему фискализации.
Тестирование и запуск
Проверяю успешную оплату, отказ, повторную попытку, дубли уведомлений, возвраты и взаимодействие с CRM или 1С.
Интеграция платёжной системы с сайтом
Подключаю онлайн-оплату к сайтам на 1С-Битрикс и другим платформам: от готового платёжного модуля до индивидуальной интеграции через API.
Настраиваю не только кнопку «Оплатить», а весь платёжный сценарий: создание операции, проверку суммы, обработку уведомлений, изменение статуса заказа, повторную оплату, возвраты и передачу данных во внешние системы.
Когда сайту нужна онлайн-оплата
- покупатель должен оплачивать заказ сразу после оформления;
- компания продаёт услуги с фиксированной или рассчитанной стоимостью;
- менеджеры вручную отправляют клиентам реквизиты или ссылки;
- платёж нужно автоматически связать с конкретным заказом или заявкой;
- требуется индивидуальная ссылка на оплату;
- после оплаты заказ должен автоматически переходить в нужный статус;
- необходимы возвраты или повторная попытка оплаты;
- нужны регулярные платежи или подписочная модель.
Какие способы оплаты можно подключить
Возможности, комиссии и ограничения зависят от договора с выбранным платёжным провайдером. Перед разработкой проверяется документация и доступность необходимых сценариев.
Как выбирается платёжный провайдер
Комиссия — только один из критериев. Для интеграции важны также технические возможности и удобство дальнейшей эксплуатации.
Провайдер самостоятельно проверяет компанию, сайт и соответствие своим условиям обслуживания.
Как проходит оплата на сайте
Создание заказа
Сайт сохраняет товары, услуги, стоимость и необходимые данные покупателя.
Создание платежа
Сервер передаёт провайдеру сумму, валюту, номер заказа и необходимые параметры.
Оплата
Покупатель переходит на защищённую форму или использует платёжный виджет.
Уведомление
Платёжный сервис отправляет сайту серверное событие о состоянии операции.
Проверка
Проверяются подпись или токен, идентификатор платежа, заказ и сумма.
Обновление заказа
После подтверждённого события заказ переводится в согласованный статус.
Следующие действия
При необходимости запускаются чек, CRM-сценарий, передача в 1С или уведомление.
Почему нельзя доверять только странице «Оплата прошла»
Возврат пользователя на страницу успешной оплаты не является надёжным подтверждением поступления денег.
Покупатель может закрыть страницу раньше, соединение может прерваться, а URL страницы результата иногда можно открыть вручную.
Источником результата используется проверенное уведомление платёжного провайдера или запрос текущего состояния операции через его API.
Статусы платежа и заказа
Заказ и платёж — разные сущности. Заказ уже может существовать, пока связанная с ним платёжная операция ещё ожидает действий клиента.
Для проекта заранее определяется, какой статус платёжного сервиса какому состоянию заказа соответствует.
Если провайдер отправил одно событие несколько раз, сайт не должен повторно менять заказ, списывать остаток, начислять бонусы или создавать дублирующие документы.
Одностадийная или двухстадийная оплата
Одностадийная
После подтверждения покупателем операция сразу переходит в предусмотренное провайдером состояние оплаты.
Подходит для сценариев, где заказ можно сразу передавать в дальнейшую обработку.
Двухстадийная
Сначала сумма авторизуется, а окончательное списание подтверждается отдельно.
Такой сценарий может использоваться, если перед списанием нужно проверить наличие товара или возможность выполнения заказа.
Конкретная логика и доступное время подтверждения зависят от условий выбранного платёжного провайдера.
Готовый модуль или интеграция через API
Готовый модуль
Подходит для стандартного интернет-магазина с типовой корзиной и оформлением заказа.
- быстрее подключается;
- использует штатную структуру CMS;
- проще обновлять при нормальной поддержке разработчика модуля;
- ограничен предусмотренными сценариями.
Интеграция через API
Используется для нестандартного оформления заказа или индивидуальной логики.
- собственные формы;
- личный кабинет;
- нетиповые статусы;
- подписки;
- CRM и 1С;
- другие специфические процессы.
Как формируется сумма платежа
Источником стоимости может быть корзина интернет-магазина, тариф, заказ менеджера или результат онлайн-калькулятора.
Нельзя доверять стоимости, которую браузер передал из JavaScript или скрытого поля формы: клиентские данные можно изменить до отправки запроса.
Онлайн-касса и электронные чеки
Приём платежа и формирование фискального документа — связанные, но разные процессы.
Технически можно передавать состав заказа, суммы и другие согласованные параметры в поддерживаемое кассовое решение.
Ставки налогов, предмет и способ расчёта, момент формирования чека и другие учётные параметры определяются заказчиком совместно с бухгалтерией или оператором кассового решения.
Возвраты
При поддержке со стороны провайдера можно реализовать полный или частичный возврат из административной панели или внутренней системы.
Проверка платежа
Определяется операция и доступная сумма возврата.
Создание возврата
Сайт передаёт запрос платёжному сервису.
Сохранение результата
Фиксируются идентификатор и состояние операции.
Обновление заказа
Изменяется соответствующий статус сайта.
Техническое создание возврата не означает мгновенное поступление денег покупателю: дальнейший срок зависит от банка, провайдера и способа оплаты.
Повторные платежи и подписки
Подписочная модель — отдельный платёжный сценарий, который сложнее обычной разовой оплаты.
- согласованный сценарий сохранения платёжного способа;
- токен провайдера вместо хранения реквизитов карты;
- расписание списаний;
- обработка успешной и неуспешной операции;
- повторные попытки по заданным правилам;
- отключение подписки;
- возврат и завершение услуги.
Если провайдер поддерживает повторные платежи, для дальнейших операций используется предоставленный им идентификатор или токен.
Безопасность платёжной интеграции
При использовании защищённой страницы или платёжного виджета провайдера сайт обычно не работает напрямую с полными реквизитами банковской карты.
Журнал операций и контроль ошибок
Для разбирательства спорных ситуаций сохраняются технические данные, позволяющие связать заказ с соответствующей платёжной операцией.
- номер заказа;
- идентификатор платежа;
- сумма и валюта;
- время создания и изменения;
- полученный статус;
- результат обработки уведомления;
- безопасный код или описание ошибки;
- история возвратов.
Если платёжный сервис повторно отправляет событие, обработчик должен корректно принять его без повторного выполнения уже завершённой операции.
Интеграция оплаты с CRM и 1С
После подтверждения оплаты можно автоматически запускать дальнейшие процессы.
Сайт, платёжный сервис, CRM и 1С не должны независимо менять один бизнес-статус по разным правилам.
Для учётного обмена можно отдельно настроить интеграцию сайта с 1С, а работу с обращениями — интеграцию сайта с CRM.
Как проходит подключение
Сбор требований
Определяем CMS, модель продаж, способы оплаты и необходимые сценарии.
Проверка провайдера
Анализирую модуль, API, уведомления, возвраты и другие возможности.
Проектирование
Сопоставляем платежи, заказы, статусы и внешние системы.
Тестовое подключение
Настраиваю модуль или API с тестовыми параметрами магазина.
Проверка сценариев
Тестирую оплату, отказ, повторные события и возвраты.
Рабочие реквизиты
После проверки подключаются параметры рабочего магазина.
Контрольная операция
Проверяем реальную оплату и при необходимости сценарий возврата.
Запуск
Онлайн-оплата становится доступна, первые операции контролируются по журналам.
Какие сценарии проверяются
Что потребуется для оценки
- адрес сайта и используемая CMS;
- описание продаваемых товаров или услуг;
- выбранный платёжный провайдер или требования к нему;
- необходимые способы оплаты;
- текущий сценарий оформления заказа;
- требования к отмене и возвратам;
- используемая касса или схема фискализации;
- необходимость интеграции с CRM и 1С;
- сценарий повторных платежей, если они нужны;
- тестовые доступы после согласования проекта.
От чего зависят сроки и стоимость
Комиссия за платежи, услуги кассы, оператор фискальных данных, платные модули и сторонние сервисы оплачиваются заказчиком отдельно.
Нужно подключить оплату к сайту?
Пришлите адрес сайта, название платёжного провайдера и кратко опишите текущий сценарий заказа. Я проверю, можно ли использовать готовый модуль или требуется индивидуальная интеграция.
Ориентировочный бюджет
Показываю порядок цен заранее. Точная оценка зависит от объёма работ, интеграций и состояния проекта.
Подключение готового платёжного модуля
от 30 000 ₽Интеграция через API с обработкой статусов и возвратов
от 50 000 ₽Онлайн-оплата с фискализацией, CRM или 1С
от 70 000 ₽Что получает заказчик
Не просто набор настроек или работ, а понятный результат для ежедневной работы.
Подключённую онлайн-оплату
Рабочий платёжный модуль или API-интеграцию с выбранным провайдером.
Связь платежа с заказом
Каждая операция сопоставляется с конкретным заказом, заявкой или другим объектом сайта.
Автоматические статусы
После подтверждённого платёжного события заказ переводится в согласованное состояние.
Защиту от повторной обработки
Повторное уведомление от провайдера не запускает одну и ту же бизнес-операцию второй раз.
Сценарии ошибок и возвратов
Настроенную обработку отказа, повторной оплаты и полного или частичного возврата в согласованном объёме.
Журнал платёжных событий
Техническую историю ключевых операций для проверки статусов и разбора ошибок.
Виталий Николаев
Веб-разработчик и специалист по автоматизации бизнеса
Профессионально занимаюсь разработкой с 2018 года. Соединяю сайт, CRM, аналитику и внутренние процессы в единую систему, которую можно поддерживать и развивать.
Сначала цели, сценарии и архитектура — затем реализация.
Вы общаетесь со специалистом, который принимает решения и пишет код.
Остаюсь на связи, анализирую результат и развиваю решение.
и автоматизации
проектов
и внедрений
по рекомендации
Кейсы по этой услуге
Показываю не абстрактные обещания, а реализованные проекты и решённые бизнес-задачи.
Разработка выгрузки товаров на различные маркетплейсы
Автоматическая выгрузка товаров на Wildberries, Ozon и Яндекс.Маркет. Интеграция с 1С и централизованное управление остатками позволили синхронизировать данные и расширить точки продаж.
Смотреть кейс →
Автоматизация бизнеса
Интеграция битрикс24 для инженерной компании
Для инженерной компании выполнено внедрение и настройка Битрикс24 с адаптацией CRM под особенности проектной деятельности. Были автоматизированы продажи, работа с заявками и взаимодействие между подразделениями. В результате компания получила единое пространство для работы с клиентами, проектами и внутренними процес…
Смотреть кейс →
Внедрение CRM
Частые вопросы
Сколько стоит подключение онлайн-оплаты к сайту?+
Подключение готового совместимого модуля начинается от 30 000 ₽. Интеграция через API с индивидуальной логикой, возвратами, фискализацией и внешними системами оценивается выше.
Какие платёжные системы можно подключить?+
Можно работать с российскими банками и платёжными агрегаторами, которые предоставляют готовый модуль для CMS или документированный API. Конкретный сервис выбирается с учётом способов оплаты, договора и технических возможностей.
Можно ли подключить оплату банковскими картами?+
Да, если выбранный платёжный провайдер поддерживает карточные платежи для вашего типа бизнеса.
Можно ли подключить СБП?+
Да, если СБП доступна в тарифе и договоре выбранного провайдера.
Можно ли принимать оплату по ссылке?+
Да. Для конкретного заказа можно формировать индивидуальную ссылку или отдельную страницу оплаты, если такой сценарий поддерживается провайдером.
Нужно ли менять банк?+
Не обязательно. Если ваш банк предоставляет подходящий интернет-эквайринг или API, можно использовать его. В противном случае можно рассмотреть другого платёжного провайдера.
Кто заключает договор с платёжной системой?+
Договор с банком или платёжным сервисом заключает заказчик. Провайдер самостоятельно проверяет компанию, сайт и соответствие своим условиям обслуживания.
Можно ли использовать готовый модуль?+
Да. Для типового интернет-магазина это обычно предпочтительный вариант, если модуль поддерживает текущую версию CMS и необходимые сценарии.
Когда нужна интеграция через API?+
API требуется для нестандартного оформления заказа, собственного личного кабинета, сложной логики статусов, подписок, интеграции с CRM или 1С и других сценариев, которых нет в готовом модуле.
Как сайт узнаёт, что платёж действительно прошёл?+
Платёжный провайдер отправляет серверное уведомление или предоставляет API для проверки статуса. После проверки подписи, идентификатора, суммы и других параметров сайт обновляет состояние заказа.
Можно ли считать оплату успешной, если пользователь попал на страницу «Оплата прошла»?+
Нет. Возврат пользователя на страницу результата сам по себе не является подтверждением оплаты. Статус заказа должен меняться по проверенному серверному уведомлению или данным API провайдера.
Что происходит, если пользователь закрыл страницу оплаты?+
Заказ остаётся в соответствующем состоянии ожидания. Если платёж завершился, серверное уведомление может прийти независимо от того, вернулся пользователь на сайт или нет.
Что происходит при отказе банка или отмене оплаты?+
Сайт сохраняет заказ и получает доступный статус операции. Пользователю можно предложить повторить оплату или выбрать другой способ.
Можно ли повторно оплатить заказ?+
Да. Можно реализовать повторное создание платёжной операции для заказа, который ещё не был успешно оплачен.
Что будет, если платёжная система отправит уведомление дважды?+
Обработчик проектируется так, чтобы повторное уведомление не выполняло уже завершённую операцию второй раз.
Можно ли автоматически менять статус заказа после оплаты?+
Да. После подтверждённого платёжного события заказ можно перевести в заранее согласованный статус и запустить дальнейшую обработку.
Можно ли настроить полный возврат?+
Да, если API и договор с провайдером поддерживают возвраты. Возврат можно инициировать из административной панели или внутренней системы.
Можно ли сделать частичный возврат?+
Да, если платёжный провайдер поддерживает частичные возвраты. Перед отправкой операции контролируется доступная для возврата сумма.
Возврат сразу поступает клиенту?+
Не обязательно. Сайт инициирует операцию возврата, а фактический срок зачисления зависит от провайдера, банка и способа оплаты.
Можно ли настроить двухстадийную оплату?+
Да, если выбранный провайдер поддерживает такой режим. Сначала сумма авторизуется, а окончательное списание подтверждается после проверки заказа.
Когда нужна двухстадийная оплата?+
Она может быть полезна, если перед списанием необходимо подтвердить наличие товара, возможность оказания услуги или другие условия заказа.
Можно ли принимать оплату результата онлайн-калькулятора?+
Да. Но итоговая сумма должна рассчитываться или проверяться на сервере. Нельзя доверять стоимости, которую браузер передал из JavaScript или скрытого поля.
Можно ли подключить онлайн-кассу?+
Можно настроить техническую передачу данных в поддерживаемую кассу, облачный сервис фискализации или соответствующий механизм платёжного провайдера.
Кто определяет данные для чека?+
Ставки налогов, предмет и способ расчёта, момент формирования чека и другие учётные параметры определяет заказчик совместно с бухгалтерией или оператором кассового решения.
Можно ли формировать чек при возврате?+
Если используемая схема фискализации этого требует и поддерживает, можно настроить передачу данных для соответствующего документа возврата.
Можно ли настроить регулярные платежи или подписку?+
Да, если платёжный провайдер предоставляет такой функционал. Сценарий подписки, повторных попыток, отмены и уведомлений проектируется отдельно.
Будут ли данные банковской карты храниться на сайте?+
Полные реквизиты карты на сайте хранить не требуется. Для повторных платежей при поддержке провайдера используется предоставленный им токен или идентификатор платёжного способа.
Можно ли сохранить способ оплаты клиента?+
Только через предусмотренный платёжным провайдером механизм и при соблюдении его требований к повторным платежам и согласию пользователя.
Можно ли передавать информацию об оплате в CRM?+
Да. После подтверждения платежа можно изменить сделку, создать задачу, уведомить менеджера или выполнить другой согласованный CRM-сценарий.
Можно ли передавать статус оплаты в 1С?+
Да, если для проекта предусмотрен соответствующий обмен между сайтом и 1С. При этом заранее определяется, какая система отвечает за состояние оплаты и заказа.
Можно ли одновременно связать оплату с CRM и 1С?+
Да. Важно заранее определить роли систем и последовательность обмена, чтобы сайт, CRM и 1С не изменяли один статус по противоречащим друг другу правилам.
Как защищаются секретные ключи платёжной системы?+
Секретные ключи хранятся на серверной стороне и не должны попадать в публичный JavaScript, HTML или клиентскую часть сайта.
Проверяется ли подлинность уведомлений?+
Да. Используется предусмотренный провайдером механизм проверки подписи, токена или другого параметра аутентификации уведомления.
Ведётся ли журнал платёжных операций?+
Для диагностики можно сохранять номер заказа, идентификатор платежа, сумму, время, статус и результат обработки. Секретные и лишние конфиденциальные данные в журнал не записываются.
Что происходит, если API платёжного сервиса временно недоступно?+
Сценарий зависит от этапа операции. Можно сохранять заказ в ожидании, повторять отдельные запросы, фиксировать ошибку и уведомлять ответственного вместо того, чтобы считать платёж успешным.
Можно ли протестировать оплату без реальных денег?+
Большинство платёжных провайдеров предоставляют тестовый режим. Сначала интеграция проверяется на тестовых реквизитах, после чего подключаются рабочие параметры.
Какие сценарии тестируются перед запуском?+
Проверяются успешная оплата, отказ, отмена пользователем, повторная попытка, повторное уведомление, неверная подпись, несоответствие суммы, возвраты и работа предусмотренных внешних интеграций.
Гарантирует ли интеграция успешное прохождение каждого платежа?+
Нет. Операция может быть отклонена банком, платёжным сервисом или самим пользователем по причинам, не связанным с работой сайта.
Что потребуется для оценки работ?+
Нужны адрес сайта, CMS, описание сценария заказа, выбранный платёжный провайдер или требования к нему, необходимые способы оплаты, возвраты, фискализация и список интеграций с CRM, 1С или другими системами.
Связанные услуги
Соберу комплексное решение из нескольких направлений, если этого требует задача.
Полезно перед началом работ
Разбираю выбор решений, распространённые ошибки и практику внедрения.
Эффективность рассылок клиентам: Email, ВКонтакте, WhatsApp или Telegram
Какие каналы рассылок лучше работают для торговой компании: Email, ВКонтакте, WhatsApp или Telegram?
Разбираем преимущества каждого варианта, персонализацию сообщений, аналитику и интеграцию Wazzup с Битрикс24. Читать статью →
Россия и Казахстан развивают сотрудничество: какие цифровые решения нужны бизнесу
Форум сотрудничества России и Казахстана в Омске открывает новые возможности для бизнеса. Разбираемся, какие цифровые решения помогают компаниям выстраивать совместную работу: сайт, CRM, интеграция с 1С, личные кабинеты и автоматизация обмена данными. Читать статью →
Собственный интернет-магазин или маркетплейс: почему бизнесу опасно зависеть от одной площадки
Маркетплейсы дают быстрый доступ к аудитории, но делают продавца зависимым от чужих правил, комиссий, складов и алгоритмов. Разбираемся, почему собственный интернет-магазин снижает риски, помогает сохранять клиентскую базу и превращается в долгосрочный актив бизнеса. Читать статью →