Временный резерв слота: как связать онлайн-запись и оплату без дублей

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

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

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

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

В ЮKassa платёж может находиться в состояниях pending, waiting_for_capture, succeeded или canceled. Состояние waiting_for_capture относится к двухстадийному сценарию: средства авторизованы и ожидают списания. Оно не тождественно succeeded. Возвращение клиента на страницу сайта также само по себе не устанавливает итог операции.

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

Клиент может дважды нажать кнопку, потерять соединение или открыть платёж в другой вкладке. Идемпотентность означает, что повтор одной и той же операции не создаёт новый результат. В API ЮKassa для этого используется Idempotence-Key: повтор с тем же ключом и параметрами возвращает результат исходного запроса в пределах установленного провайдером срока, сейчас это 24 часа.

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

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

Условный пример: резерв закончился в 12:10, в 12:11 слот подтвердил другой клиент, а в 12:12 пришло уведомление об успешном платеже первой попытки. Нельзя автоматически восстановить первую бронь поверх второй. Финансовое событие нужно сохранить и направить в отдельный процесс разрешения конфликта с ответственным и уведомлением клиенту.

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

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

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