SABSUS

ПЛАТЕЖИ · СОСТОЯНИЯ · ИСПОЛНЕНИЕ

Авторизация и списание платежа: какие состояния должен понимать заказ

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

Редакция SABSUS · · Источники проверены 9 октября

Сначала определите, что означает «оплачено»

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

В Square Payments API отложенное списание позволяет получить APPROVED без списания источника платежа. Отдельное завершение переводит платёж в COMPLETED, отмена — в CANCELED. Это модель конкретного провайдера, а не универсальное соответствие названий всех платёжных систем. Square: Delayed Capture.

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

Разделите четыре события

Авторизация подтверждает одобрение операции в пределах условий провайдера. Capture, или завершение списания, относится к отдельному этапу. Settlement и выплата продавцу отражают дальнейшее движение средств. Возврат после успешного списания — ещё одна операция со своим состоянием и подтверждением.

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

Создайте собственный словарь: «ожидаем результат», «авторизовано до указанного срока», «списание подтверждено», «авторизация отменена или истекла», «требуется разбор». Рядом сохраняйте исходный статус провайдера и время его проверки. Неизвестный результат должен оставаться видимым, а не автоматически превращаться в отказ.

Храните крайний срок конкретной операции

Удержание ограничено во времени. В Square поле delayed_until показывает момент автоматического действия, а delay_action определяет, что произойдёт по достижении порога. Документация описывает разные допустимые сроки и поведение. Для рабочего решения используйте данные конкретной операции и проверенную настройку, а не универсальное «карта удерживается неделю». Square: порог отложенного списания.

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

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

Учебный пример: заказ успевает и заказ опаздывает

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

Заказ готов к подтверждённому этапу списания в среду в 16:00. До предельного момента остаётся 18 часов. Уполномоченный процесс завершает исходную попытку и получает подтверждённое списание 300. В отчёте поступлений по этой операции учитывается 300, а не 300 авторизации плюс 300 списания.

Позже согласован возврат 50. Пока существует только запрос, чистое подтверждённое движение остаётся 300, а возврат 50 показывается как ожидающее действие. После подтверждения возврата чистое движение по включающему оба события периоду составляет 300 − 50 = 250. Выплата на банковский счёт может отличаться из-за комиссии, сроков и других подтверждённых событий; здесь она не рассчитывается.

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

Отмена авторизации и возврат требуют разных маршрутов

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

Перед действием проверяйте актуальный объект провайдера. Square для CompletePayment описывает проверку ожидаемой версии платежа; при изменившейся версии запрос может завершиться ошибкой несовпадения. Это пример защиты от устаревшего состояния, которую нужно проверить в собственной интеграции. Square: Complete payment.

Не обещайте клиенту точное время освобождения удержания по одной внутренней отметке. Команда может сообщить подтверждённое действие и предоставить сведения провайдера, но отображение в банке клиента и фактическая доступность средств требуют собственного подтверждения.

Что делать при потере ответа

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

Повтор webhook также не является вторым платежом. Square предупреждает о возможной повторной доставке уведомлений и отсутствии гарантии их порядка. Square: Webhooks overview. Поэтому позднее уведомление об авторизации не должно откатывать уже подтверждённое списание в прежнее состояние.

В тестовом примере приходят три уведомления об одной попытке: одно об одобрении и два одинаковых о завершении. Ожидаемый результат — один платёж на 300 и одна связь с заказом. Число сообщений равно трём, число бизнес-операций — одному. Считать платёжные события по количеству полученных HTTP-запросов нельзя.

Свяжите состояние с разрешённым действием команды

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

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

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

Приёмочный чек-лист

  1. Одобрение без capture не отображается как подтверждённое окончательное списание.
  2. Крайний срок и автоматическое действие читаются из проверенных данных операции.
  3. Перенос исполнения за срок авторизации создаёт видимый вопрос ответственному.
  4. Завершение исходной попытки учитывается один раз, без сложения с авторизацией.
  5. Отмена до списания и возврат после него идут по разным допустимым маршрутам.
  6. Потеря ответа вызывает сверку исходного результата до нового денежного действия.
  7. Поздний или повторный webhook не создаёт второй платёж и не ухудшает подтверждённое состояние.
  8. Изменение суммы заказа требует проверки платёжных условий и полномочий.
  9. Клиентское сообщение соответствует доказанному этапу, а не предполагаемой доступности денег.

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

Короткие ответы

Авторизовано означает, что деньги уже на счёте продавца?

Нет. Авторизация, завершённое списание и банковская выплата относятся к разным этапам.

Срок удержания одинаков для всех карт?

Не следует это предполагать. Проверяйте способ, условия провайдера и срок конкретной операции.

Можно повторить оплату после тайм-аута?

Сначала установите результат первоначальной попытки. Новое действие требует известного состояния и предусмотренного основания.

Источники

Источники проверены 9 октября 2026 года. Суммы, сроки и тестовые сценарии являются учебными.