Допустимые комбинации документальных обменов
Рисунок .31. Допустимые комбинации документальных обменов
1) Если первое сообщение IOTP транзакции содержит запрос аутентификации, то:
| a) Транзакция IOTP содержит документальный обмен аутентификации (смотри раздел 9.1.1). (Замечание 1) | ||
| b) Если последнее сообщение документального обмена аутентификации содержит блоки TPO и отклика предложения, тогда: | ||
| i) Транзакция IOTP включает документальный обмен предложения, независимый от вида платежа (смотри раздел 9.1.2.2). (Замечание 2) | ||
| c) В противном случае, если последнее сообщение аутентификационного обмена содержит блок TPO, но не содержит блока отклика предложения, тогда: | ||
| i) Сообщение IOTP содержит документальный обмен предложения, зависимый от вида платежа (смотри раздел 9.1.2.1). (Замечание 2) | ||
| d) В противном случае (сообщение состояния аутентификации документального обмена не содержит ни блока TPO ни блока отклика предложения). | ||
| i) Транзакция IOTP содержит только документальный обмен аутентификации. (Замечание 3) |
2) В противном случае (отсутствие запроса аутентификации в первом сообщении IOTP):
| e) Транзакция IOTP не включает в себя документальный обмен аутентификации (Замечание 2) | ||
| f) Если первое сообщение содержит блок отклика предложения, тогда: | ||
| i) Транзакция IOTP содержит документальный обмен предложения, независимый от вида платежа (Замечание 2) | ||
| g) В противном случае (отсутствие блока отклика предложения в первом сообщении): | ||
| i) Транзакция IOTP включает документальный обмен предложения, зависимый от вида платежа (Замечание 2) |
3) Если блок отклина предложения присутствует в каком-либо сообщении IOTP, тогда:
| h) Если блок отклика предложения содержит компонент доставки, тогда: | |||
| i) Если атрибут DelivAndPayResp компонента доставки равен “Истинно”, то компонент доставки делается равной “Истинно”, тогда: | |||
| (1) Транзакция IOTP состои из документальных обменов платежа и доставки (смотри раздел 9.1.5) (Замечание 4) | |||
| ii) В противном случае (атрибут DelivAndPayResp компонента доставки делается равным “Ложно”) | |||
| (1) Транзакция состоит из документального обмена платежа (смотри раздел 9.1.3), за которым следует обмен доставки (смотри раздел 9.1.4) (Замечание 4) | |||
| i) В противном случае (блок отклика предложения не содержит компонента доставки ) | |||
| i) если блок отклика предложения содержит только один компонент платежа, тогда: | |||
| (1) Транзакция IOTP содержит только один документальный обмен платежа (Замечание 5) | |||
| ii) если блок отклика Offer содержит компонент платежа, тогда: | |||
| (1) Транзакция IOTP включает в себя два документальных платежных обмена. Атрибут StartAfter компонента платежа используется для индикации того, какой платеж происходит первым. (Замечание 6) | |||
| iii) если блок отклика Offer не содержит ни одного или имеет более двух платежных компонентов, то имеет место ошибка | |||
| 4) В противном случае (отсутствие блока отклика Offer) имеет место ошибка. |
Некоторые платежные методы могут выполнять аутентификацию в ходе платежного обмена. В этом случае информация, необходимая для выполнения аутентификации будет включаться в компоненты платежной схемы.
В этом примере приложение IOTP не будет уверено, что аутентификация состоялась, так как компоненты платежной схемы, которые содержат аутентификационную информацию, не отличимы о других компонентов платежной схемы.
9.2. Инфраструктурные транзакции
Инфраструктурные транзакции разработаны, для поддержки запросов, прошла ли транзакция успешно или работает ли корректно некоторая торговая роль. Существует два типа таких транзакций:
- транзакция запроса состояния транзакции, которая предоставляет информацию о статусе существующей или уже завершившейся транзакции;
- транзакция Ping, которая позволяет одному приложению определить, работает ли соответствующее приложение другой торговой роли и проверить, могут ли обрабатываться подписи.
Базовая транзакция запроса состояния предоставляет информацию о состоянии существующей или завершившейся транзакции IOTP. Базовая транзакция запроса состояния использует следующие торговые блоки:
- торговый блок информационного запроса (смотри раздел 8.12),
- торговый блок информационного отклика (смотри раздел 8.13)
- опционный блок подписи (смотри раздел 8.16).
- чтобы помочь возобновить прерванную транзакцию и определить текущее состояние одной из других торговых ролей,
- определить продавцу, завершен ли платеж, доставка и т.д.. Например, покупатель может объявить, что платеж произведен, но нет платежной расписки, подтверждающей это утверждение. Если продавец делает запрос кассиру, то он может определить, произведена или нет соответствующая проплата.
Одна торговая роль может послать запрос любой другой торговой роли в любое время.
Программа, которая поддерживает торговую роль покупателя 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 a2 | Информационый запрос. IotpMsg: блоки TransRef; подписи (опционный); информационого запроса |
| 2. | Вторая торговая роль проверяет цифровую подпись (если она присутствует). Если получатель хочет среагировать, тогда торговая роль проверяет состояние транзакции, объекта запроса, используя IotpTransId в ID-компоненте блока ссылок транзакции, посылает сообщение первой торговой роли, после чего процесс останавливается |
| 1 ? 2 | Информационный отклик. IotpMsg: блоки TransRef; информационного отклика; подписи (опционный) |
| 3. | Первая торговая роль проверяет блок информационного отклика и опционную подпись, выполняет необходимые действия и останавливается. Это может включать отображение статусной информации конечному пользователю. |
