Истёкшее время оплаты: как обновлять заказ и резерв товара

Отсчёт закончился, а деньги ещё идут

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

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

Где возникает ошибка

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

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

Что видит сотрудник

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

Три срока, которые нельзя смешивать

У заказа, платёжной операции и резерва разные часы. Магазин определяет, как долго готов держать товар и предлагать оплату, а платёжный сервис ограничивает действия со своей операцией, поэтому фраза «ссылка действует час» требует уточнения: какая ссылка, с какого момента и что произойдёт после истечения. Универсального срока для всех способов нет.

В документации ЮKassa время подтверждения оплаты различается по способам. Если оно истекло, операция отменяется с причиной expired_on_confirmation, а для новой попытки создают новый платёж. Это не означает, что магазин обязан автоматически создать новый заказ. Связь между заказом и попытками оплаты организует интеграция. Историю предыдущей попытки полезно сохранить.

Ожидание, подтверждение и списание

ЮKassa различает pending, waiting_for_capture, succeeded и canceled. Первое состояние связано с ожиданием действий или завершения необходимых этапов, второе — с авторизованными деньгами, ожидающими списания при двухстадийной оплате. Succeeded и canceled являются финальными состояниями операции. Для владельца магазина главное различие в том, ожидаются ли деньги, удержаны ли они или платёж уже завершён. По этим названиям сотрудник находит этап, который предстоит уточнить у разработчика или платёжного сервиса.

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

Срок резерва — решение магазина

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

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

Судьба заказа и резерва после истечения срока

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

Окончательный отказ и ещё неизвестный результат

Если платёж завершился отменой, можно применить описанное магазином правило: снять резерв, закрыть старую возможность оплаты и предложить повторное оформление при наличии товара. Если ответ ещё не окончательный, состояние неопределённости нельзя прятать под сообщением «оплата не прошла». Покупатель может уже видеть списание или удержание в банке. Ему нужен статус ожидания уточнения. Сотруднику — задача на сверку.

В инструкции по уведомлениям ЮKassa предусмотрены события payment.succeeded, payment.canceled и payment.waiting_for_capture. Магазин получает их на сервер. Возврат покупателя на страницу после оплаты не является единственным каналом сведений. Человек может не вернуться вообще. Поэтому результат заказа связывают с подтверждёнными данными сервиса, а не с показом страницы благодарности.

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

Одновременные действия

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

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

Поздняя оплата и повторная попытка

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

Понятное сообщение вместо тупика

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

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

Новый платёж к прежнему заказу

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

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

Как принять спорные варианты

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

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

Цена неопределённого статуса

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

Что происходит без связанного процесса

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

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

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