Вернуться к статьям Покупатель нажимает «Оплатить», деньги списываются с карты, а заказ остаётся в статусе ожидания оплаты. В другом случае платёж не проходит, и покупателю непонятно, можно ли повторить попытку или заказ уже оформлен.
Интеграция интернет-магазина с эквайрингом затрагивает сайт, платёжную страницу, состояние заказа и действия сотрудников при спорных ситуациях. До разработки нужно описать маршрут платежа: создание заказа, переход к оплате, получение результата, отмену, повторный запрос и обработку задержанных подтверждений.
Как устроена интеграция интернет-магазина с эквайрингом
Обычный сценарий начинается в корзине. Покупатель указывает данные, выбирает способ получения и переходит к оплате. Сайт создаёт заказ и передаёт в платёжный контур сумму, идентификатор заказа и другие данные, предусмотренные проектом. После завершения операции заказ получает результат по согласованному каналу обмена.
Сообщение в браузере не может быть единственным основанием для изменения состояния заказа. Покупатель может закрыть вкладку, потерять соединение или вернуться на сайт позже. Поэтому в требованиях фиксируют:
- момент создания заказа;
- состояния до подтверждения оплаты;
- данные для связи заказа с платёжной операцией;
- источник окончательного результата;
- сообщения для успешной, отменённой и неуспешной оплаты.
Для проверки сценария нужны примеры реальных заказов: с доставкой, самовывозом, скидкой, несколькими товарами или нестандартным составом. Они показывают, какие значения участвуют в платёжном запросе, а какие остаются внутри сайта.
Сценарии оплаты и повторных попыток
У заказа могут быть разные пути: немедленная оплата, отложенный платёж, возврат к оплате из личного кабинета или повторная попытка после отказа. Для каждого пути задают условия перехода между состояниями.
Повторная попытка не должна создавать второй независимый заказ без установленного правила. В проекте определяют, сохраняется ли исходный заказ, создаётся ли новая платёжная операция, когда прежняя попытка считается завершённой и что происходит, если заказ уже нельзя передать в обработку.
Отдельно описывают изменение заказа после перехода к оплате. Если сотрудник поменял состав, доставку или сумму, ранее созданный запрос может перестать соответствовать текущему заказу. Нужно выбрать правило: запретить изменения, сформировать новый запрос или передать заказ на ручную проверку.
Какие данные передаются при подключении эквайринга
Состав данных зависит от сценария и условий конкретного подключения. Заранее определяют источник каждого значения: суммы, номера заказа, состава покупки, контактов покупателя и сведений о доставке, если они участвуют в обмене.
Для согласования удобно подготовить таблицу обмена. В ней для каждого поля указывают название, источник, направление передачи, формат, обязательность и обработку пустого значения. Так до запуска выявляются вопросы об округлении суммы, промокодах или заказах без отдельных контактных данных.
В платёжный контур не передают сведения без понятной задачи. Также нужно определить, где хранится технический идентификатор операции и как сотрудник сопоставляет его с конкретным заказом при обращении покупателя.
Статусы заказа после оплаты и отмены
Статусы нужны для конкретных действий. Сотрудник должен отличать заказ, по которому покупатель начал оплату, от подтверждённого платежа, отменённой операции и случая с неизвестным результатом.
Логика статусов отвечает на практические вопросы: допускается ли резервирование товара, можно ли передавать заказ в сборку, нужно ли связаться с покупателем, разрешена ли повторная оплата. Статус «оплачен» не устанавливают только по возвращению покупателя на страницу успешной оплаты. Его меняют после получения результата по согласованному каналу обмена.
Требования к оплате относятся к CMS сайта: оформлению заказа, хранению состояний и отображению информации покупателю. Внутренний порядок работы сотрудников описывают отдельно, не подменяя им правила сайта.
Ошибки оплаты и неопределённые результаты
Ошибка может возникнуть на стороне покупателя, платёжной страницы или обмена между системами. Покупатель отменил операцию, платёжная страница вернула отказ либо сайт не получил результат из-за временного сбоя связи. Один статус «не оплачено» для этих ситуаций не подходит: действия по ним различаются.
Для каждого случая определяют четыре элемента: сообщение покупателю, состояние заказа, запись для сотрудника и способ восстановления сценария. Если итог операции неизвестен, повторную оплату не предлагают до проверки результата. Иначе можно получить несколько операций по одному заказу.
В журнале диагностики предусматривают идентификатор заказа, идентификатор операции, время события, технический ответ и понятную причину для разбора. В записи включают только данные, необходимые для поиска ошибки.
Уведомления и действия сотрудников
Сообщение после оформления должно совпадать с фактическим состоянием. Подтверждённая оплата, заказ в ожидании результата и отменённая операция требуют разных формулировок. При отмене покупателю нужно сообщить, сохранён ли заказ и предусмотрена ли повторная попытка.
Для сотрудников составляют отдельный порядок разбора спорных ситуаций: проверить идентификаторы, сопоставить сумму, установить результат операции и изменить состояние по утверждённому правилу. Ручная смена статуса без проверки создаёт риск передать в обработку неоплаченный заказ или повторно отправить запрос на оплату.
Проверка интеграции эквайринга перед запуском
Проверку строят на наборе сценариев, а не на одной успешной оплате. Проверяют успешную операцию, отказ, отмену покупателем, закрытие браузера, повторный переход к оплате, задержанное подтверждение, изменение заказа и недоступность внешнего контура.
По каждому сценарию фиксируют ожидаемое состояние заказа, текст для покупателя, запись в журнале событий и действия сотрудника. Повторная обработка одного и того же подтверждения не должна повторно менять заказ, создавать новые операции или отправлять дублирующие сообщения.
Часто задаваемые вопросы
- Что происходит, если покупатель оплатил заказ, но не вернулся на сайт?
Результат оплаты должен поступить по согласованному техническому каналу, а не зависеть только от перехода на страницу сайта. В требованиях указывают состояние такого заказа и порядок разбора неразрешённых случаев.
- Можно ли разрешить повторную оплату одного заказа?
Да, если определены условия завершения первой попытки, правило создания нового запроса и защита от одновременной оплаты разными способами. Этот путь проверяют отдельным сценарием.
- Почему нельзя сразу ставить статус «не оплачен», если сайт не получил ответ?
Отсутствие ответа не означает отказ. Операция могла завершиться, но подтверждение не поступило на сайт. Такой заказ выделяют для проверки, не запуская новую оплату автоматически.
- Какие данные нужны разработчику для интеграции?
Нужны путь покупателя, примеры заказов, список состояний, правила отмены и повторной оплаты, состав передаваемых данных, доступы к тестовой среде при её наличии и ответственный за спорные операции.
- Как исключить передачу неоплаченного заказа в обработку?
Для каждого состояния устанавливают наблюдаемые правила: допускаются ли сборка и отгрузка, кто может изменить статус вручную и какие данные нужно проверить перед изменением. Затем правила проверяют на тестовых заказах.