Покупатель нажал «Оплатить». Кнопка осталась прежней, страница несколько секунд молчит. Он нажимает снова, потому что не понимает, сработало ли первое действие. Для человека это одна покупка. Сайт может получить два запроса.
Такую ситуацию полезно проверять до запуска рекламы. Причём отдельно на каждом участке: создание заказа, обращение к платёжному сервису, получение результата и передача покупки в исполнение. Защита одного участка не закрывает остальные.
Ниже пять проверок, которые владелец магазина может согласовать с разработчиком. Все повторные действия выполняйте в тестовом режиме платёжного провайдера. Для рабочего магазина порядок проверки реальными платежами должен быть отдельно согласован с ответственными за оплату и учёт.
1. Что происходит сразу после первого нажатия
Кнопка должна объяснить состояние действия. Например, текст «Открываем страницу оплаты» сообщает, что запрос принят и нужно подождать. Если ничего не меняется, повторное нажатие выглядит естественным способом проверить, работает ли сайт.
Попросите разработчика показать сценарий с искусственной задержкой ответа в тестовой среде. Нажмите кнопку и наблюдайте за страницей. Сохраняется ли состав заказа, видно ли ожидание, можно ли случайно отправить форму повторно. Запишите поведение, которое команда считает правильным.
Отключение кнопки после нажатия полезно для интерфейса. При этом сервер, который принимает запрос, должен самостоятельно распознавать повтор. Посетитель может обновить страницу, открыть вторую вкладку или вернуться к старому экрану. В этих случаях состояние одной кнопки уже ничего не решает.
Проверьте сообщение после задержки. Если сайт ещё не знает результат, слово «Ошибка» слишком мало объясняет покупателю. Сообщение должно описывать доступное действие: подождать, обновить статус заказа или обратиться в поддержку с номером. Кнопка повторной оплаты допустима только в согласованном состоянии заказа.
Есть и обратная проблема. Кнопка может навсегда остаться заблокированной после сетевого сбоя. Тогда человеку придётся искать другой путь. Согласуйте, как интерфейс выходит из ожидания и откуда получает достоверный статус. Эта часть работы входит в разработку интерфейса на React и требует связи с серверной логикой.
2. Сколько заказов создаётся при двух запросах
Начните проверку с базы заказов. В тестовом примере покупатель приобретает одну лампу с доставкой. Повторное нажатие в рамках того же действия должно приводить к согласованному результату, который можно проверить по номеру заказа. Если появляются два независимых заказа, поддержке придётся выяснять намерение клиента вручную.
Разработчик должен определить, что сайт считает одной попыткой оформления. Обычно для этого нужен устойчивый идентификатор действия и сохранённый результат его обработки. Конкретная схема зависит от устройства магазина. На приёмке важен наблюдаемый результат, включая одновременные запросы.
Попросите показать два сценария. В первом повтор приходит после завершения первого запроса. Во втором оба запроса поступают почти одновременно. Проверка только последовательного повтора может пропустить ошибку конкурентной обработки, когда два процесса одновременно решили создать новый заказ.
В журнале теста сохраните идентификаторы запросов и полученных заказов. Они позволят связать действия браузера с записями на сервере. В техническом журнале не должны оказаться данные банковской карты или секреты платёжного сервиса. Для поиска достаточно согласованных служебных идентификаторов.
Отдельно обсудите новую покупку того же товара. Клиент вправе оформить второй заказ намеренно. Защита от повтора должна отличать повторную доставку старого запроса от нового подтверждённого действия. Простая проверка одинакового состава корзины и телефона может заблокировать законную повторную покупку.
Сходные ошибки возникают при обмене с другими системами. В разборе настройки API есть полезный контекст о границах интеграции. Для оплаты формулируйте требование через конкретную попытку заказа и её результат.
3. Как магазин повторяет запрос платёжному сервису
Даже один заказ может получить несколько платёжных попыток. Например, магазин отправил запрос, связь оборвалась до получения ответа, и код отправил его заново. Платёжный сервис должен понять, что повтор относится к той же операции, если его API поддерживает такой механизм.
Это свойство называют идемпотентностью. При повторе действия сервис возвращает прежний результат и не создаёт новую операцию. Документация ЮKassa описывает ключ Idempotence-Key: при повторе с тем же ключом и данными сервис распознаёт исходный запрос. В документации также указан срок действия такого поведения. Его надо учитывать в логике повторов.
На приёмке спросите разработчика, где хранится ключ попытки и когда создаётся новый. Если новый ключ появляется при каждом сетевом повторе, механизм не защищает исходную операцию. Если один ключ случайно используют для разных покупок, запросы перестают соответствовать своему назначению.
Для другой платёжной системы проверяйте её правила отдельно. Например, Stripe описывает собственное поведение повторных запросов, включая сохранение результата первого обращения и проверку совпадения параметров. Названия полей и условия разных провайдеров нельзя переносить механически.
Сам магазин тоже хранит связь между заказом и платёжной попыткой. Ключ провайдера не заменяет эту запись. Поддержка должна понимать, к какому заказу относится полученный результат, даже если покупатель закрыл браузер до возвращения на сайт.
Проверьте вариант с изменившейся корзиной. Если после неудачной попытки клиент добавил товар, состав и сумма стали другими. Разработчик должен определить, требуется ли новая попытка и как завершается предыдущая. Это правило стоит описать до написания кода, чтобы интерфейс и сервер одинаково понимали действие покупателя.
4. Сколько раз выполняется заказ после подтверждения
Оплата и исполнение заказа должны иметь отдельные наблюдаемые состояния. Подтверждение платежа может запустить письмо, резерв товара или выдачу цифрового доступа. Повторная обработка одного подтверждения способна повторить эти действия, даже если деньги списались один раз.
Попросите разработчика показать обработку повторного уведомления в тестовой среде. У одного подтверждённого заказа должен остаться согласованный единственный результат исполнения. Если письмо допускает повторную отправку вручную, такое действие должно отличаться от случайного повторения всей обработки.
Уведомления от платёжной системы называют вебхуками. Сервис отправляет их на адрес магазина, чтобы сообщить об изменении состояния. ЮKassa описывает формат и проверку входящих уведомлений. Разработчик должен проверять подлинность и актуальность сведений способом, который поддерживает выбранный провайдер.
Страница «Спасибо за покупку» в браузере сама по себе не должна быть основанием для выдачи товара. Покупатель может закрыть её, обновить или открыть сохранённую ссылку. Магазину нужен подтверждённый результат на сервере и проверка связи с конкретным заказом.
Составьте небольшую таблицу последствий подтверждения.
| Действие магазина |
Что проверить при повторе |
| Изменение состояния заказа |
История не создаёт новый заказ |
| Передача на склад |
Повтор не создаёт вторую отгрузку |
| Выдача доступа |
Покупатель получает согласованное право один раз |
| Уведомление менеджеру |
Сообщение связано с прежним номером заказа |
Для каждого действия определите владельца проверки. Разработчик видит серверные записи, менеджер подтверждает карточку заказа, склад проверяет задание на сборку. Один скриншот успешной оплаты не показывает весь этот маршрут.
Техническую часть входящих уведомлений можно обсудить вместе с организацией собственных вебхуков. В обоих случаях полезно сохранять идентификатор события и результат обработки, чтобы повтор можно было распознать и объяснить.
5. Что видят покупатель и поддержка при неопределённом результате
После обрыва связи магазин может продолжать уточнять состояние платежа. В браузере покупатель при этом видит только ожидание ответа. Покупатель опасается повторного списания. Поддержка должна быстро найти заказ и понять, что проверять дальше.
Согласуйте понятное сообщение. Например, «Проверяем оплату заказа. Его номер сохранён в личном кабинете». Такое сообщение подходит только тогда, когда кабинет действительно содержит заказ и умеет показывать состояние. Текст интерфейса обязан соответствовать работающей функции.
Если кабинета нет, предложите доступный канал связи и покажите номер обращения. Не просите клиента присылать полный номер карты или секретные данные. Для первоначального поиска обычно нужны номер заказа и сведения, предусмотренные внутренним порядком поддержки. Конкретный набор согласуйте с ответственными за обработку обращений.
Сотрудник поддержки должен видеть связь заказа с платёжными попытками. Отдельные записи «ожидается», «успешно» и «отменено» полезны только при понятном происхождении. Если интерфейс поддержки показывает один общий значок, попросите добавить доступ к истории для уполномоченного сотрудника.
При подтверждённом дублировании действуйте по процедуре магазина и платёжного провайдера. Сначала установите, какие операции реально прошли. Далее ответственный сотрудник определяет, какие исправления нужны по принятой в компании процедуре, и сообщает клиенту результат. Автоматический возврат на основании одного сообщения покупателя может создать ещё одну ошибку.
Для поиска технических расхождений нужен контроль ошибок. В материале о наблюдении за веб-приложением разобрана общая организация сигналов. В платёжном процессе полезен отдельный сигнал о заказах, которые слишком долго остаются без определённого результата. Порог ожидания согласуйте с разработчиком с учётом особенностей сервиса.
Как записать результат проверки
Для каждого сценария сохраните исходное состояние заказа, последовательность действий и ожидаемый результат. После теста приложите номера созданных записей и фактическое состояние. Это позволит повторить проверку после изменения корзины, интерфейса или платёжного модуля.
В короткий набор приёмки включите несколько случаев.
- Два быстрых нажатия в одной вкладке.
- Возвращение к заказу после обновления страницы.
- Потеря ответа на запрос создания платежа.
- Повторная обработка подтверждения.
- Новая покупка с тем же составом корзины.
Дополните этот набор проверкой прав доступа. Покупатель, который открыл ссылку на собственный заказ, должен видеть только разрешённые ему сведения. Вторая вкладка другого пользователя помогает проверить, что номер заказа сам по себе не открывает чужую карточку. Этот сценарий согласуйте с разработчиком на тестовых аккаунтах.
Проверьте также возврат покупателя из платёжного окна без завершения операции. Корзина может остаться на месте, но сайт должен показать фактическое состояние прежней попытки. Согласуйте, когда человек может выбрать другой способ оплаты. Если два способа открыты одновременно в разных вкладках, серверу всё равно потребуется связать результаты с одним заказом и предотвратить повторное исполнение.
Этот случай удобно воспроизвести двумя тестовыми вкладками. Сначала откройте оплату, затем вернитесь к заказу и начните доступное повторное действие. Зафиксируйте состояние обеих попыток и то, что увидел менеджер. Проверку завершайте только после того, как результаты обеих попыток определились.
У каждого успешного теста должно быть проверяемое основание. Надпись на экране дополняется состоянием заказа на сервере и записью платёжной попытки. Если один из участков недоступен проверяющему, назначьте сотрудника, который подтвердит его отдельно.
Feature IT может разработать интерфейс заказа и связать его с серверной проверкой состояния. Для обсуждения подготовьте схему текущей оплаты и один воспроизводимый сценарий повтора. По нему легче определить границы доработки и условия её приёмки.
Читайте также
