Интернет-эквайринг позволяет принимать оплату онлайн. Но подключить кнопку и наладить работу магазина с платежами не одно и то же. Покупатель может закрыть вкладку после списания, уведомление может прийти повторно, а возврат потребует отдельной операции. Сайт должен правильно обработать каждый из этих случаев.
Мы в Гуси-Лебеди предлагаем начинать с простого вопроса: что должно произойти с заказом после оплаты? Ниже разберём выбор сервиса, подготовку сайта, подтверждение платежа и приёмку подключения. Примеры технических статусов приведены по документации ЮKassa. У другого провайдера названия и порядок работы могут отличаться.
Как выбрать интернет-эквайринг под свой сайт
Сначала опишите продажу, которую нужно обслужить. Для товара с известной ценой можно создавать платёж при оформлении заказа. Для услуги с индивидуальным расчётом удобнее сначала согласовать стоимость, затем отправить клиенту платёжную ссылку. Для заказа, который необходимо подтвердить по наличию, стоит рассмотреть оплату с предварительной авторизацией суммы, если выбранный сервис поддерживает такой сценарий.
Это разные задачи. Поэтому полезнее сравнивать предложения на примере вашего заказа, чем выбирать банк по самой заметной ставке на баннере.
Модуль, платёжная ссылка или API
Готовый модуль для CMS подходит, когда платформа и сценарий магазина поддерживаются провайдером. Перед установкой проверьте совместимость с вашей версией CMS, кто выпускает обновления и какие операции доступны: приём оплаты, возврат, двухстадийная оплата, передача данных для чека. Само наличие WordPress или Битрикс в списке интеграций ещё не отвечает на эти вопросы.
Платёжная ссылка полезна для согласованных заказов, оплаты консультаций и продаж через переписку. Однако нужно определить, как менеджер связывает ссылку с заказом и узнаёт об оплате. Если все операции остаются только в кабинете провайдера, магазин и CRM не обязательно получат нужный статус автоматически.
Интеграция по API нужна, когда готовое решение не покрывает процесс. Например, сумма уточняется после проверки заказа или платёж должен запускаться из личного кабинета. В этом случае отдельно проектируют создание платежа, обмен статусами, обработку ошибок и возвраты. Сравнить эти варианты полезно ещё до заказа разработки интернет-магазина: выбранный процесс влияет на устройство сайта.
Что сравнить в условиях провайдеров
| Критерий | Что выяснить до подключения |
|---|---|
| Способы оплаты | Какие способы доступны вашему бизнесу и выбранной интеграции, какие нужно подключать отдельно. |
| Полная стоимость | Комиссия по каждому способу, НДС, дополнительные сервисы, касса или отправка чеков, условия возврата комиссии. |
| Перечисление денег | На какой счёт поступает выручка, каков график, как обрабатываются выходные и удержания. |
| Работа с заказом | Поддержка авторизации суммы, полного и частичного возврата, доступные ограничения. |
| Поддержка интеграции | Совместимый модуль, актуальная документация, тестовая среда, уведомления и помощь при сбое. |
Не переносите условия одного сервиса на весь рынок. Например, Точка и Ozon Банк описывают подключение со своим расчётным счётом, а Яндекс Пэй указывает возможность использовать уже имеющийся счёт. Это нужно проверять в конкретном предложении, а не считать обязательным правилом для любого эквайринга.
Предпринимателям и самозанятым также важно проверить допустимый статус продавца. Формулировка «для бизнеса» не означает, что сервис работает со всеми категориями пользователей и товаров. Список документов, ограничения и срок рассмотрения заявки уточняйте у выбранного провайдера.
Что подготовить до подключения оплаты
Заявка в банк и установка модуля решают разные части задачи. Провайдер проверяет продавца и площадку, а разработчик настраивает обмен данными. Чтобы работа не остановилась посередине, заранее соберите информацию о компании, товарах и способе продажи.
На сайте должны быть понятны продавец, предмет покупки и условия заказа. В инструкции Альфа-Банка среди требований перечислены контактные данные, реквизиты, информация о товарах и доставке. Точка дополнительно описывает HTTPS с действующим сертификатом и перенаправление с HTTP. Полный перечень проверяйте по правилам того сервиса, куда подаёте заявку.
Полезно пройти собственную страницу глазами покупателя: можно ли узнать окончательную стоимость, найти условия возврата и связаться с продавцом? Если эти сведения находятся в разных местах, дайте на них понятные ссылки из оформления заказа.
Отдельно согласуйте чеки. Эквайринг отвечает за приём денег, а формирование и передачу фискальных документов требует выбранной схемы работы. У провайдеров встречаются интеграция с кассой и собственные сервисы отправки чеков. Применимость решения зависит от деятельности и условий подключения. До запуска согласуйте с бухгалтером и провайдером, кто формирует чек, какие данные получает и как обрабатывает возврат. Статья о настройке кнопки не заменяет такую проверку.
Для технической части подготовьте доступ к административной панели сайта, сведения о версии CMS и ответственном за поддержку. Рабочие ключи и пароли передавайте через согласованный защищённый канал. Не помещайте их в открытые задачи, текст страницы или письма покупателям.
Тестовые и рабочие настройки храните раздельно. В инструкции Альфа-Банка эти этапы описаны отдельно: сначала проверка интеграции, затем переход в рабочую среду. Поэтому успешный тест сам по себе не означает, что магазин уже принимает реальные платежи.
Как сайт должен узнавать об успешной оплате
Страница «Спасибо за покупку» удобна для клиента, но не должна быть единственным основанием для отметки «Оплачено». В сценарии Redirect ЮKassa возвращает пользователя на указанный адрес и при успешной оплате, и при проблеме. Кроме того, человек может вообще не вернуться в магазин.
Поэтому статус заказа нужно получать от платёжного сервиса. В описании процесса платежа ЮKassa используются состояния pending, waiting_for_capture, succeeded и canceled: ожидание действий, ожидание списания, успех и отмена. Авторизация суммы при двухстадийной оплате не равна завершённому списанию.
Разработчику стоит передать схему связи: номер заказа в магазине, идентификатор платежа у провайдера, сумма, валюта и разрешённое изменение статуса. Менеджер должен видеть, к какому заказу относится операция. Две разные попытки оплаты одного заказа также нужно различать.
Для чего нужны уведомления
Уведомление, или webhook, сообщает сайту об изменении операции без участия покупателя. Для ЮKassa можно подписаться, например, на успешную оплату и завершённый возврат. Адрес обработчика и события настраивают по инструкции выбранного сервиса.
Полученный запрос нельзя принимать за доказательство оплаты только потому, что в нём написано «успех». Нужно проверить его подлинность предусмотренным способом, сопоставить операцию с заказом и сохранить результат. ЮKassa описывает проверку актуального статуса объекта либо адреса отправителя в документации по уведомлениям.
Обработчик должен учитывать повторную доставку: одно событие не должно повторно выдавать цифровой товар, создавать вторую отгрузку или отправлять одинаковую задачу менеджеру. Для контроля полезно сохранять идентификатор обработанной операции и журнал изменения заказа.
Возврат клиента в браузере и подтверждение оплаты сервером выполняют разные функции. Первый помогает продолжить покупку, второе определяет, что делать с заказом.
Если подтверждение пока не получено, покажите понятное ожидание проверки и способ связаться с поддержкой. Не предлагайте человеку сразу платить повторно. Сначала установите состояние первой операции. Этот сценарий стоит включить в проверку оформления заказа вместе с мобильной версией и переходом в банковское приложение.
Возврат, отмена и сверка с заказами
Отключить кнопку оплаты, отменить заказ и вернуть деньги покупателю означают разные действия. Изменение заказа в CRM само по себе не выполняет финансовую операцию у провайдера.
В двухстадийном сценарии сначала уточните, было ли уже выполнено списание. Если сумма только авторизована, порядок отмены будет отличаться от возврата завершённой оплаты. Не выбирайте действие по одному статусу заказа: посмотрите состояние конкретного платежа.
В ЮKassa возврат создаётся для успешного платежа с его идентификатором и суммой. Он может быть полным или частичным, но частичный вариант поддерживается не всеми способами оплаты. Ограничения и причины неуспеха перечислены в инструкции по возвратам. Уведомление о созданном запросе ещё нужно отличать от подтверждения завершённого возврата.
Представим условный магазин: покупатель оплатил два товара и решил вернуть один. Менеджер выбирает исходный платёж, указывает возвращаемую сумму и ждёт результата операции. В заказе сохраняют, что именно возвращено, остаток оплаченной суммы и связь с финансовой операцией. Иначе следующий сотрудник может принять частичный возврат за полный.
Назначьте сотрудника с правом оформлять возвраты и согласуйте, кто проверяет результат. Покупателю сообщайте подтверждённое состояние, а срок поступления денег сверяйте с правилами провайдера. Не обещайте мгновенное зачисление на любую карту.
Для сверки сравнивайте оплаченные заказы, платежи, возвраты и перечисленную выручку по идентификаторам. Расхождение требует разбора: комиссия, график зачисления и возвраты могут влиять на сумму, но причину нужно подтверждать данными. Не списывайте любую разницу на «банк задержал деньги».
Как принять подключение и запустить реальные платежи
Просите показать не только успешную оплату. Хорошая приёмка отвечает на вопрос, что увидят покупатель и сотрудник магазина при каждом исходе. Проверки выполняют в тестовой среде по инструкции провайдера, с предусмотренными им тестовыми данными.
- Успешная оплата. Проверьте сумму, связь платежа с заказом и переход к согласованному действию: обработке, выдаче доступа или отгрузке.
- Отказ или отмена. Неуспешная операция не должна давать оплаченный заказ. Покупатель получает понятное сообщение и возможность продолжить.
- Закрытие вкладки. Обновление заказа должно работать и без возвращения покупателя на страницу магазина.
- Повторное уведомление. Уже обработанная операция не запускает действие с заказом ещё раз.
- Возврат. Проверьте доступные полные и частичные возвраты, их результат в кабинете провайдера и отражение в магазине.
- Мобильный путь. Откройте оплату на телефоне, проверьте переход в приложение при выбранном способе и возвращение в заказ.
Зафиксируйте результат каждой проверки: исходный заказ, платёж, ожидаемое и фактическое состояние. Если предусмотрены двухстадийная оплата или подписка, для них понадобится свой набор проверок. Не отмечайте эти функции проверенными по результату обычной покупки.
Перед рабочим запуском уточните, что заявка одобрена, договор оформлен, рабочая среда выбрана, а адреса уведомлений и возврата пользователя относятся к действующему сайту. Проверьте настройки чека и доступ сотрудника, который будет разбирать обращения. Реальные контрольные операции проводит уполномоченный владелец по согласованному порядку.
При передаче работы сохраните короткую инструкцию: где смотреть статус, как найти платёж по заказу, кто делает возврат, куда обращаться при расхождении и кто поддерживает модуль после обновления CMS. Для дальнейшей работы эти задачи можно включить в сопровождение сайта.
Мы в Гуси-Лебеди предлагаем считать подключение принятым, когда магазин правильно обрабатывает согласованные сценарии, а сотрудники умеют проверить оплату и помочь покупателю. Наличие кнопки остаётся только первым видимым шагом.