Интеграция сайта с платежными системами

Интеграция платёжной системы с сайтом

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

Настраиваю интернет-эквайринг для сайтов на 1С-Битрикс, других CMS и индивидуально разработанных платформах. Можно подключить готовый платёжный модуль либо реализовать интеграцию через API.

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

Когда сайту нужна онлайн-оплата

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

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

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

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

В качестве провайдера могут рассматриваться ЮKassa, интернет-эквайринг Т-Банка, Robokassa, CloudPayments и другие сервисы. Фактическая возможность подключения, комиссия и способы оплаты проверяются перед началом работ непосредственно по условиям выбранного оператора.

Как выбирается платёжный провайдер

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

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

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

Как проходит оплата на сайте

1. Создание заказа. Сайт фиксирует товары, услуги, стоимость и данные, необходимые для дальнейшей обработки.
2. Создание платежа. Сервер сайта передаёт провайдеру сумму, валюту, идентификатор заказа и другие параметры.
3. Переход к оплате. Покупатель открывает защищённую страницу или виджет платёжного сервиса.
4. Подтверждение операции. Пользователь выполняет действия, предусмотренные выбранным способом оплаты.
5. Уведомление сайта. Провайдер отправляет серверный запрос с новым статусом платежа.
6. Проверка уведомления. Сайт проверяет подпись, идентификатор, сумму и допустимость изменения статуса.
7. Обновление заказа. Только после подтверждённого уведомления заказ отмечается как оплаченный.
8. Информирование покупателя. Пользователь видит результат, получает чек или другое предусмотренное сообщение.

Почему нельзя доверять только странице «Оплата прошла»

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

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

Статусы платежа и заказа

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

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

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

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

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

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

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

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

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

Готовый модуль или интеграция по API

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

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

Индивидуальная интеграция

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

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

Оплата товаров, услуг и расчётов из калькулятора

Источником суммы может быть корзина интернет-магазина, фиксированный тариф, выставленный менеджером счёт или результат онлайн-калькулятора.

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

Если результат является предварительным и требует проверки, сначала создаётся заявка, а ссылка на оплату формируется только после подтверждения менеджером.

Онлайн-касса и электронные чеки

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

В зависимости от модели бизнеса и применимых требований может использоваться:

• собственная или арендованная онлайн-касса;
• облачный сервис фискализации;
• решение платёжного провайдера для передачи чеков;
• интеграция кассы с CMS или учётной системой.

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

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

Возврат оплаты

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

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

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

Регулярные платежи и подписки

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

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

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

Безопасность платёжной интеграции

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

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

Журнал операций и контроль ошибок

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

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

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

Интеграция оплаты с CRM и 1С

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

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

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

Как проходит подключение платёжной системы

1. Сбор требований. Определяем модель продаж, CMS, способы оплаты и сценарии возврата.
2. Выбор провайдера. Проверяем доступные методы, готовые модули, тарифы и требования подключения.
3. Заключение договора. Заказчик регистрирует магазин и предоставляет полученные тестовые параметры.
4. Проектирование. Сопоставляем статусы платежа и заказа, определяем уведомления и фискализацию.
5. Тестовая интеграция. Подключаю модуль или API и выполняю операции в тестовом режиме.
6. Проверка сценариев. Тестируются успешная и неуспешная оплата, повторное уведомление, отмена и возврат.
7. Подключение рабочих реквизитов. После приёмки тестов устанавливаются параметры рабочего магазина.
8. Контрольный платёж. Выполняется небольшая реальная операция и при необходимости возврат.
9. Запуск. Оплата становится доступна покупателям, а первые операции контролируются по журналам.

Какие сценарии проверяются

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

Что потребуется для оценки

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

Что получает заказчик

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

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

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

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

Установка совместимого модуля для стандартного интернет-магазина и разработка собственного платёжного сценария через API — разные по объёму задачи.

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

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