Как проверить оплату на сайте перед запуском магазина

Успешная оплата скрывает другие поломки

Запуск магазина после единственной успешной оплаты оставляет покупателю все ошибки, которые подрядчик не попробовал воспроизвести: отмену на платёжной странице, отказ банка, задержку ответа и повторное нажатие, пока сайт молчит. Эти ситуации можно разобрать заранее. Рассмотрим магазин с оплатой банковской картой через ЮKassa. Испытания проходят на тестовых заказах, а исполнитель показывает результат и покупателю, и сотруднику магазина. Готовность оценивают по обоим экранам. Если проверку проводит только разработчик, владелец может не заметить, что сотрудник отдела продаж ищет оплату в другом месте. Участие сотрудника помогает связать испытание с обработкой покупки после запуска.

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

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

Ошибка: испытание приняли за реальную покупку

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

В ЮKassa для испытаний используется тестовый магазин с собственными реквизитами доступа. В объекте его платежа признак test имеет значение true. Владельцу не нужно читать программный запрос: исполнитель может показать этот признак в журнале рядом с номером заказа и объяснить, как такие покупки исключены из обычной работы.

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

Цена на платёжной странице не совпала с корзиной

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

В простой приёмке полезны разные составы: одна позиция, несколько товаров, доставка за плату и уменьшение цены. Они отличаются источником итоговой суммы. Разница помогает найти ошибку расчёта и объяснить её магазину.

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

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

Переход обратно на сайт ошибочно приняли за успех

Переход обратно на сайт говорит о движении покупателя между страницами, поэтому нельзя отмечать оплату только по открытию страницы благодарности: человек способен вернуться после отказа или закрыть вкладку до того, как магазин узнает результат операции. Решает состояние платежа. В процессе ЮKassa успешное завершение обозначено succeeded. Отмена обозначена canceled. Исполнитель показывает, как магазин получает эти состояния.

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

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

Отказ банка превратился в тупик

Сообщение об ошибке легко написать так, что покупатель не поймёт, сохранился ли заказ и что он может сделать дальше, поэтому приёмка отказа включает не только техническую причину, но и путь продолжения с тем же составом покупки. В справке неуспешных платежей отказ после непрохождения аутентификации обозначен 3d_secure_failed. Код нужен специалисту для разбора. Покупателю объясняют действие обычными словами.

Сырой программный код — плохое сообщение для витрины: он перекладывает объяснение на человека, который пришёл купить товар. Лучше сохранить номер заказа, показать, что оплата не завершилась, и дать подходящий путь следующей попытки после выяснения состояния.

Для испытания отказов используются специальные тестовые карты из документации ЮKassa. Исполнитель выбирает данные под нужную причину, а владелец оценивает экран: сохранились товары, понятен результат и доступно продолжение.

Покупатель закрыл вкладку: кто обновит заказ?

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

На демонстрации можно завершить тестовую оплату и прекратить путь в браузере до открытия страницы магазина. Затем сотрудник открывает заказ обычным способом и оценивает состояние без участия покупателя.

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

Повторное действие создало лишнюю операцию

При медленном ответе покупатель нажимает кнопку ещё раз или обновляет страницу, поэтому испытание включает повтор с тем же заказом: магазин оценивает, не появились ли лишние операции и сохранилась ли связь с первой попыткой. Повтор не всегда новая покупка. В формате взаимодействия ЮKassa описана идемпотентность — обработка повторного запроса как исходного, если переданы те же данные и тот же ключ операции. Защита действует в течение 24 часов после первого запроса. Разработчик показывает, как магазин сохраняет этот ключ, а новое действие покупателя отделяет от повтора прежнего запроса.

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

Повтор уведомления также относится к испытанию. ЮKassa ждёт подтверждение получения с кодом HTTP 200, а при другом ответе продолжает доставку в течение 24 часов. Это условие доставки уведомлений, поэтому одно и то же событие не должно повторно запускать отгрузку или отправлять одинаковые письма.

Сначала установите судьбу первой попытки, потом предлагайте новую оплату. Иначе магазин рискует попросить деньги повторно, пока успешный исход ещё не дошёл до его экрана.

Исправления принимаются по той же покупке

Запись о сбое полезна, когда исполнитель понимает исходный состав и может повторить действие, поэтому отчёт связывает номер заказа с ожидаемым исходом, увиденным сообщением и фактическим состоянием операции. Отказ испытывают повторно после правки. Сотрудник может перепутать несколько попыток одного покупателя, если замечание содержит лишь общую сумму и рассказ по памяти. Лучше сохранить адресную запись по операции: по ней видно, какое поведение исправляют и чем подтвердится результат. Технические подробности остаются в закрытом отчёте, а владелец получает понятный итог по своей покупке.

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

Тест кассового обмена в ЮKassa имитирует взаимодействие со сторонней онлайн-кассой: данные не уходят в кассу и ОФД. Это ограничение испытаний означает, что результат песочницы нельзя записать как получение покупателем реального фискального документа.

Оцените путь, который оборвался до конца

До передачи магазина в работу владелец открывает результаты испытаний и выбирает сценарий с прерванным путём, чтобы понять, что увидел покупатель, что получил сотрудник и какое действие позволило продолжить покупку после отказа. Исходный код для этого не нужен. Сохранённые экраны и связанная операция отвечают на вопросы о состоянии денег и заказа, а запись о повторной демонстрации объясняет, что изменилось после исправления. Если этих сведений нет, приёмку продолжают на выбранном исходе: общее сообщение об успешном тестировании не поможет отделу разобрать такой же вопрос после запуска.

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

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