Протокол IGRP

       

Обмен платежными документами



Рисунок .21. Обмен платежными документами

9.1.3.1. Принципы обработки сообщений

Получив сообщение платежного запроса, кассир должен проверить, авторизован ли данный платеж (смотри раздел 6). Он может затем:

  • сформировать и послать сообщение платежного обмена покупателю, если этого требует платежный протокол или
  • сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или
  • индицировать сбой, послав покупателю блок Cancel, содержащий компонент Status с атрибутом StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.4) равным: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument или Unspecified.

Получив платежное ообщение, Покупатель может:

  • сформировать и послать платежное сообщение Кассиру или
  • индицировать сбой, послав кассиру блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.2) равным: ConsCancelled или Unspecified.

Получив платежное ообщение, кассир может:



  • сформировать и послать платежное сообщение покупателю, если этого требует платежный протокол или
  • сформировать и послать сообщение платежного отклика, если протокольный платежный обмен завершен или
  • индицировать сбой, послав Покупателю блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодами CompletionCode (смотри раздел 7.16.2) равными: PaymtCancelled или Unspecified.

Получив платежное ообщение-отклик, Покупатель может:

  • сформировать и послать следующее сообщение транзакции соответствующей торговой роли. Это зависит от разновидности транзакции,
  • остановиться, так как транзакция завершена или
  • индицировать сбой, послав Продавцу блок Cancel, содержащий компонент Status с атрибутами StatusType = Payment, ProcessState = Failed и кодом CompletionCode (смотри раздел 7.16.1) равным: ConsCancelled или Unspecified.

Если покупатель получает сообщение, содержащее блок Cancel, тогда информация из сообщения IOTP должна быть доведена до сведения покупателя и не должны предприниматься никакие другие действия.


Если кассир получает сообщение, содержащее блок Cancel, тогда покупатель вероятно обратится в сетевой узел CancelNetLocn, специфицированный элементом торговой роли в компоненте Organisation для кассира, здесь он сможет предпринять некоторые дальнейшие действия.

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

9.1.3.2. Сообщение платежного запроса

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение может содержать:

  • блок платежного запроса и
  • опционный блок подписи
Блок платежного запроса (смотри раздел 8.7) состоит из:

  • следующих компонентов копируемых из блока отклика Offer, полученного в ходе предыдущего документального обмена предложения:
  - компонент Status
  - компонент Payment для выполняемого платежа
  • следующих компонентов блока TPO:
  - компоненты Organisation с ролями Продавец и Кассир, которые были пересланы в блоке платежного запроса;
  - компонент списка видов платежа, т.e. список видов платежа, указанный в атрибуте BrandListRef компонента Payment;
  • одного компонента выбора вида платежа, т.e. компонента выбора вида платежа, где атрибут BrandListRef указывает на список видов платежа. Этот компонент может быть:
  - скопирован из блока выбора вида платежа, если платеж предшествовал документальному обмену предложения, зависящего от вида платежа (смотри раздел 9.1.2.1) или
  - сформирован Покупателем. В этом случае он содержит код вида платежа, платежный протокол и вид валюты, выбранные из списка видов платежа (смотри раздел 9.1.2.2).
  • опционного компонента платежной схемы (смотри раздел 7.10), если это требуется для используемого способа платежа (смотри, если нужно, приложение для платежных методов).
  • нуль или более компонентов данных о торговой роли (смотри раздел 7.17).
Заметим, что:



  • если в блоке отклика Offer имеется более одного компонента Payment, тогда вторым платежем являет тот, что записан в блоке отклика Offer и который содержит атрибут StartAfter (смотри раздел 7.9), указывающий на компонент Payment предыдущего платежа;
  • Кассир, который должен быть сюда включен, идентифицируется компонентом выбора платежа (смотри раздел 7.8). Объясненеи того как идентифицируется Кассир смотри в разделе 6.3.1;
  • компонент списка видов платежей определяется атрибутом BrandListRef компонента o Payment;
  • компонент выбора вида платежа берется из блока отклика Offer, где имеется атрибут BrandListRef (смотри раздел 3.5), который идентифицирует компонент списка видов платежей.
Блок подписи (запрос платежа)

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

9.1.3.3. Сообщение платежного обмена IOTP

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя блок платежного обмена.

Блок платежного обмена (смотри раздел 8.8) включает в себя:

  • один компонент платежной схемы (смотри раздел 7.10), который содержит специфические данные метода платежа. Подробности по платежному методу смотри в приложении.
9.1.3.4. Платежное сообщение отклика

Помимо блока ссылок транзакции (смотри раздел 3.3), это сообщение включает в себя:

  • платежный блок отклика
  • опционный блок подписи
Платежный блок отклика (смотри раздел 8.9) включает в себя:

  • один компонент платежной расписки (смотри раздел 7.11), которая содержит специфические данные для платежной схемы, которые позволяют, если нужно, проконтролировать платеж;
  • один компонент платежной схемы (смотри раздел 7.10), который, если требуется, содержит специфические данные метода платежа. Подробности смотри в приложении;
  • опционный компонент накладной (Payment Note) (смотри раздел 7.12);
  • нуль или более компонентов данных о торговой роли (смотри раздел 7.17).
Блок подписи (платежный отклик)



Если предоставлена подписанная платежная расписка, что индицируется атрибутом SignedPayReceipt= True компонента Payment, тогда блок Signature должен содержать компонент Signature, который содержит элементы дайджеста следующих видов:

  • блок ссылок транзакции (смотри раздел 3.3) для сообщения IOTP, которое содержит первый вариант блока платежного отклика,
  • Id-компонент транзакции (смотри раздел 3.3.1) в блоке ссылок транзакции, который однозначно идентифицирует транзакцию,
  • компонент платежной расписки из блока платежного отклика,
  • компонент накладной (Payment Note) из блока платежного отклика,
  • другие компоненты, на которые ссылается атрибут PayReceiptNameRefs (если имеется) компонента платежной расписки,
  • компонент Status из блока платежного отклика,
  • любой компонент данных о торговой роли в блоке платежного отклика и
  • все компоненты Signature, содержащиеся в блоке платежного запроса (если имеются).
9.1.4. Обмен документами при доставке

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

  • Покупатель запрашивает доставку путем формирования сообщения запроса доставки. При этом используется информация предыдущего IOTP-сообщения транзакции и затем посылает его Агенту доставки;
  • Агент доставки посылает сообщение отклика доставки покупателю. Это сообщение содержит детали отклика агента на запрос и опционно цифровую подпись.
Схема обмена сообщениями представлена на Рисунок .22.

1. Покупатель генерирует блок запроса доставки и посылает его агенту доставки, снабдив, если требуется, цифровой подписью
C a D Запрос доставки. IotpMsg: блоки Trans Ref; подписи; запроса доставки
2. Агент доставки проверяет компоненты Status и Order запроса доставки и опционно подпись, создает блок отклика доставки, посылает его покупателю.
C ? D Отклик доставки. IotpMsg: блоки Trans Ref; подписи; отклика доставки
3. Покупатель проверяет блок отклика доставки и опционный блок подпии. Опционно производит запись о транзакции на будущее.


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