Кратко

  • RFC 3538 присваивал значения 20, 40, 60, 80 и 100 созданию или обработке последовательных сообщений SET внутри моста IOTP. Это были вехи интерфейса, а не доли завершённого коммерческого результата.
  • При 100 сообщение PRes могло означать одобренную авторизацию либо успешное списание. CompletedOK позднее мог перейти в Failed после отмены, а расчёт и доставка оставались за пределами доказанного.

На операционной панели заполнена полоса. Что теперь известно? Запрос авторизован, сумма списана, банки провели расчёт, склад передал товар, отмена стала невозможна? Интерфейсы охотно объединяют эти вопросы словом «завершено». RFC 3538, опубликованный в июне 2003 года как Informational, отвечал уже: мост между SET и IOTP обработал последний элемент собственной последовательности.

IOTP предлагал общую рамку электронной торговли, оставляя конкретным платёжным схемам место внутри Payment API. Дополнение описывало перенос сообщений Secure Electronic Transaction через IOTP 1.0. Замороженные источники не подтверждают масштаб внедрения, реальную транзакцию или измеренный сбой. Исторический смысл в том, что локальное наблюдение не получило власть над всей сделкой.

Раздел 8.12 задаёт пять отметок. После создания или обработки первого SET Initiation Response PercentComplete равен 20. PinitReq соответствует 40, PinitRes — 60, PReq — 80, PRes — 100. Consumer и Payment Handler видят создание и обработку с разных сторон. Число сообщений инициации может меняться, но первому ответу всё равно назначается 20. Значит, шкала не измеряет равные объёмы работы и не прогнозирует время; она отмечает выбранные этапы интерфейса.

Последняя отметка имеет два коммерческих смысла. Успешный PRes может содержать authorizationPerformed с одобренным AuthCode либо capturePerformed с успешным CapCode. Авторизация разрешает продолжение, а списание относится к другому моменту. Общий конверт и общий показатель не превращают их в одно событие. Без кода полоса не говорит, что именно произошло.

Машина состояний также ограничивает финальность. На стороне Payment Handler операция может достичь CompletedOK. Но при отмене платежа ChangeProcessState или CancelPayment допускает переход CompletedOK -> Failed. Состояние выражает взгляд компонента в определённый момент. Удаление истории перехода создаёт необратимость, которой не было.

Проверка квитанции делает границу ещё заметнее. CheckPayReceipt специально не проверяет Payment Receipt Information и возвращает общий ответ при корректном запросе. Такое разделение обязанностей API допустимо. Недопустимо называть структурную корректность подтверждением коммерческого факта. Допустимый конверт, распознанная квитанция и подтверждённое утверждение — разные свидетельства.

Доставка остаётся за мостом оплаты. Для физических товаров RFC советует не использовать IOTP Delivery Exchanges. Можно указать адрес запроса, а проверку кредитной авторизации между обработчиками выполнить вне IOTP. Для цифровых товаров рекомендована авторизация в реальном времени. Окончание платёжных сообщений не перемещает посылку и не доказывает получение контента.

Запросы и ошибки сохраняют ту же границу. SET Inquiry Initiation исключён, а сообщения запроса помещаются в данные IOTP. Техническая ошибка моста получает HardError, коммерческий отказ идёт другим путём. Без происхождения корректно переданный отказ выглядит поломкой, а исправный транспорт — успешной продажей.

Существующая статья о RFC 3354 владеет требованиями IOTP v2 и различием композиции и коммерческой авторизации. Статья о RFC 3504 владеет исправлениями, идентичностью, запросами и общей границей оплаты, расчёта и доставки. У RFC 3538 иной материал: пять значений, два смысла PRes, ограниченная проверка квитанции и отмена после «завершения».

Устойчивое правило требует назвать знаменатель каждого прогресса. Следует сохранять точное сообщение, создавшего или обработавшего его участника, completion code и последующие переходы. Тогда 100 становится полезным доказательством. Без происхождения число заимствует уверенность у событий, которых оно не измеряло.

Источники