Интегрированные сети ISDN
         

Условия формирования и использование поля TransID



Таблица 4.6.2.38. Условия формирования и использование поля TransID

Сообщение LID-C LID-M XID PaySysID
PInitReq R C1 N/P N/P
PInitRes ?



 ?

(C2)

 R N/P
PReq ?

 ?

 ?

(R3)

 N/P
PRes ?

 ?

(C2)

 ?

 C4
InqReq ?

 ?

 ?

 C5
InqRes ?

 ?

 ?

 C4
AuthReq ?

 ?

 ?

 N/P
AuthRes ?

 ?

 ?

 C6
AuthRevReq ?

 ?

 ?

 C
AuthRevRes ?

 ?

 ?

 ?
CapReq I I I I
CapRes I I I I
CapRevReq I I I I
CapRevRes I I I I
CredReq I I I I
CredRes I I I I
CredRevReq I I I I
CredRevRes I I I I
PCertReq N/P C N/P N/P
PCertRes N/P ?

 N/P N/P
BatchAdminReq I I I I
BatchAdminRes I I I I
CardCInitReq R N/P N/P N/P
CardCInitRes ?

 N/P N/P N/P
Me-AdCInitReq N/P C N/P N/P
Me-AdCInitRes N/P ?

 N/P N/P
RegFormReq ?

 ?

 N/P N/P
RegFormRes ?

 ?

 N/P N/P
CertReq ?

 ?

 N/P N/P
CertRes ?

 ?

 N/P N/P
CertInqReq ?

 ?

 N/P N/P
CertInqRes ?

 ?

 N/P N/P

R Поле является обязательным, генерируется отправителем сообщения и копируется в цифровой конверт.
C Наличие поля является условным. Оно может быть сформировано для этого сообщения и задублировано в цифровом конверте. В противном случае поле копируется из предыдущего сообщения.
N/P (Not Present) Отсутствует как в сообщении так и в цифровом конверте.
?

 Копируется из запроса или предыдущего сообщения, дублируется в цифровом конверте
I Может присутствовать в элементе информационной структуры сообщения, отсутствует в цифровом конверте.

Примечания:

        1. Копируется из процесса инициализации SET (если имеется)

        2. Если для данной транзакции нет предшествующего LID-M, продавец может сформировать его для данного сообщения.

        3. Если пара PinitReq/PinitRes отсутствует, то генерируется владельцем карты.

        4. Если послано после получения AuthRes с PaySysID

        5. Если послано после получения PRes с PaySysID

        6. Может быть сформировано расчетным центром для данного сообщения.

Алгоритм формирования TransID представлен ниже:



Шаг Действие
1 Если сообщение для данной транзакции получено раньше, следует запомнить все его поля.
2 Если это новая транзакция, сформировать все необходимые поля (см таблицу выше)
3 Заполнить любые опционные поля, которые могут быть сформированы данным объектом.

Обработка TransID зависит от типа сообщения.

Платежная инструкция

Платежная инструкция (PI) является одной из важнейших информационных структур SET. Она используется для передачи информации, необходимой для авторизации операции платежа владельца карты расчетному центру. Данная операция служит для инициализации транзакции с привлечением традиционной платежной карты. Данные шифруются владельцем карты и посылаются через продавца получателю (банку продавца – Acquirer). Эта информация не может быть прочитана продавцом.
Имеется три разновидности PI. Первые два формируются владельцем карты, третье – расчетным центром.

PIUnsigned Формируется владельцем карты без использования сертификата подписи. Используется в сообщениях PReqUnsigned.
Целостность данных обеспечивается за счет добавления хэша PI-данных, которые защищены в блоке OAEP. В данном механизме аутентификация отправителя не производится.
PIDualSigned Формируется владельцем карты, который владеет сертификатом подписи. Используется в сообщениях PreqDualSigned. Подпись владельца карты аутентифицирует отправителя и гарантирует целостность данных.
AuthToken Формируется расчетным центром. Продавец извлекает PI для дальнейшего вложения в AuthReq.

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

Платежная инструкция имеет структуру представленную в таблице 4.6.2.39.

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