Протокол для работы с кредитными картами CyberCash

         

Базовая транзакция запроса состояния транзакции IOTP


Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:

  • торговый блок информационного запроса (смотри раздел 8.12),

  • торговый блок информационного отклика (смотри раздел 8.13)

  • опционный блок подписи (смотри раздел 8.16).

Запросы состояния транзакции IOTP могут производиться по разным причинам. Например:

  • чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,

  • определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.

Запросы о базовых транзакциях IOTP Ping (смотри раздел 9.2.2) игнорируются.

Одна торговая роль может послать запрос любой другой торговой роли в любое время. Программа, которая поддерживает торговую роль покупателя IOTP может не делать:

  • не подписать цифровым образом отклик, если это запрашивается, при условии, что она не способна сделать это, или

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

Базовыми требованиями являются:

  • Покупатель должен послать блок статусного запроса торговой роли только после следующих событий:

 - Продавцу, после отправки блока выбора TPO,
 - Кассиру, после отправки блока платежного запроса,
 - Агенту доставки, после отправки блока запроса доставки,
  • другие торговые роли должны послать блок информационного запроса состояния транзакции покупателю только после получения сообщения от покупателя и до отправки окончательного отклика покупателю ;

  • не существует ограничений на посылку информационных запросов для любых других торговых ролей помимо покупателя.

Ошибки в запросах состояния транзакции могут быть отнесены к следующим трем классам:

  • Рабочие ошибки (смотри раздел 4.2) в исходных сообщениях-запросах.

  • Технические ошибки (смотри раздел 4.1) - как IOTP, так и специфических для определенных платежных схем es - в исходных IOTP-сообщениях.

  • Технические ошибки в сообщении, содержащем сам блок информационного запроса.

Рабочие ошибки в исходных сообщениях

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

Технические ошибки в исходных сообщениях

Возврат блока информационного отклика, содержащего компонент Status.
Компонент Status должен содержать атрибут ProcessState равный ProcessError. В этом случае в качестве отклика посылается блок Error, указывающий, где в исходном сообщении была найдена ошибка. Технические ошибки в блоке информационного запроса Возврат сообщения Error. То есть, возврат блока Error, содержащего код ошибки (смотри раздел 7.21.2), который описывает природу ошибки в сообщении информационного запроса. Сообщения информационого запроса транзакции На рис. .32 рассмотрен процесс реализации базовой транзакции информационого запроса.

1.Первая роль решает сделать запрос о транзакции IOTP, например, нажав кнопку запроса в приложении IOTP. Это вызовет генерацию блока информационого запроса и посылку его соответствующей торговой роли.
1 а2Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса
2.Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается
1 Я 2Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный)
3.Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю.
Рис. .32. Базовая транзакция статусного запроса Блок ссылок транзакции Торговая роль, делающая информационный запрос, должна использовать Id-компонент (смотри раздел 3.3.1), где атрибуты IotpTransId и TransTimeStamp имеют те же значения, что и в Id-компоненте исходной транзакции, объекта запроса. Атрибут IotpTransID в этом компоненте выполняет роль ключа при запросе записей, которые ведет торговая роль. Значение ID-атрибута Id-компонента должно быть отличным от любых других в исходной транзакции (смотри раздел 3.4.1). Если требуются текущие статусные данные, компонент MsgId, и конкретный ID-атрибут для компонента MsgId должен отличаться от любых других в сообщениях, посланных торговой роли.


Блок информационного запроса (смотри раздел 8.12) содержит следующие компоненты:
  • один компонент типа информационного запроса (смотри раздел 7.18). Он идентифицирует, относится ли запрос к предложению, платежу или доставке.
  • нуль или один компонент платежной схемы (смотри раздел 7.10). Это нужно для инкапсуляции специфических платежных сообщений.
Блок подписи (информационный запрос) Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен, чтобы определить, авторизован ли этот запрос. Если присутствует блок подписи информационного запроса (смотри раздел 8.12), то он содержит следующие компоненты:
  • один компонент Signature (смотри раздел 7.19)
  • один или более компонентов сертификата, если таковые нужны.
Блоки информационного отклика должны формироваться, только если транзакция авторизована. Цифровые подписи информационного запроса ставятся только в том случае, если получатель ожидает получение подписанных запросов. В данной версии IOTP это требует предварительного согласования. Это означает, что:
  • Покупатели вряд ли будут генерировать запросы, снабженные подписью, но если они это сделают, это не будет считаться ошибкой;
  • другие торговые роли могут согласовать применение цифровых подписей, если это требуется. Например, Кассир может потребовать, чтобы информационный запрос был подписан Продавцом.
С другой стороны, если исходная транзакция, к которой относится запрос, реализована через безопасный канал (напр., [SSL]), тогда разумно предположить, что, если отправитель информационного запроса знает Id-компонент исходного сообщения (включая, например, временную метку), то запрос является подлинным. Блок отклика INQUIRY (смотри раздел 8.13) содержит следующие компоненты:
  • один компонент Status (смотри раздел 7.16). Этот компонент содержит статусную информацию о запрашиваемой транзакции,
  • нуль или один компонент платежной схемы. Этот компонент содержит инкапсулированные платежные сообщения, специфические для выбранной схемы оплаты.
Блок SIGNATURE (отклик информационного запроса) Если в сообщении, содержащем блок информационного запроса, присутствует блок подписи, тогда он может быть проверен получателем на предмет корректности информационного отклика. Если блок подписи информационного отклика присутствует (смотри раздел 8.13), он содержит следующие компоненты:
  • один компонент Signature (смотри раздел 7.19)
  • один или более компонентов Certificate, если они нужны.
Цифровые подписи информационного отклика могут использоваться, только если получатель ожидает прихода подписанных откликов.В данной версии IOTP tэто предполагает предварительное согласование применение цифровых подписей. Это означает, что:
  • Покупатели вряд ли будут формировать отклики с подписями, хотя, если они это сделают, это не будет ошибкой;
  • другие торговые роли могут договориться о том, что подпись необходима. Например, продавец может потребовать присылки подписанного информационного отклика от кассира.


Содержание раздела