Протоколы Internet


SET и другие системы осуществления платежей - часть 48


/p>

Структура сообщения RegFormReq представлена в таблице 4.6.2.18.

Таблица 4.6.2.18

. Структура RegFormReq

RegFormReq

EXH(CA, RegFormReqData, PANOnly)

RegFormReqData

{RRPID, LID-EE, Chall-EE2,[LID-CA], RequestType, Language, [Thumbs]}

PANOnly

Структуру смотри в табл. ниже

RRPID

ID пары запрос/отклик

LID-EE

Копируется из CardCInitRes

Chall-EE2

Вызов ЕЕ, имеющий целью обновление подписи СА

LID-CA

Копируется из CardCInitRes

RequestType

Смотри табл. 4.6.2.19

Language

Предпочтительный язык последующего текста

Thumbs

Списки сертификатов (включая корневой), CRL и BrandCRLIdentifier, хранимых в данный момент владельцем карты

Поля данных PANOnly

Имя поля

Описание

PAN

Номер платежной карты владельца

EXNonce

Случайное число, используемое для маскирования PAN

Таблица 4.6.2.19

. Значения кодов RequestType

Тип запроса

Только сертификат подписи

Только сертификат шифрования

Оба сертификата

Начальный запрос владельца карты

1

2*

3*

Запрос обновления владельца карты

10

11*

12*

* указывает на значения, зарезервированные для будущего использования

Когда центр ССА получает ReqFormReq, он выполняет следующие шаги для проверки корректности сообщения.

Шаг

Действие

1

Извлечь RegFormReq из входного сообщения

2

Заполнить PAN из данных, которые подлежат шифрованию. Это делается после удаления заполнителя.

3

Из данных RegFormReqData запомнить RequestType, RRPID, LID-EE, Chall-EE2, LID-CA, список оттисков (Thumbs) и код языка.

4

Проверить, что RRPID, полученный из цифрового конверта сообщения соответствует одному коду из RegFormReqTBE. Если соответствия нет, возвращается сообщение об ошибке с ErrorCode равным unknownRRPID

После верификации RegFormReq CCA генерирует RegFormRes следующим образом. Если верификация запроса прошла успешно, присылается регистрационная форма, уведомление о политике, URL платежной системы и логотип карты. В случае неудачи сообщается причина и опционно URL и адрес e-mail, откуда может быть получена более детальная информация. Процедура формирования RegFormRes описана ниже.

Шаг

Действие

1

Сформировать RegFormTBS в соответствии со следующей процедурой:

  • Скопировать RRPID, RequestType, LID-EE, список оттисков и Chall-EE2 из RegFormReqData
  • Если в CardCInitRes имеется LID-CA, скопировать его, в противном случае сформировать LID-CA для данного запроса.
  • Сгенерировать новый Chall-CA
  • Если BrandCRLIdentifier не специфицирован в списке оттисков, полученном в CardCInitReq, заполнить поле randCRLIdentifier.
  • Если регистрационная форма владельца карты доступна для PAN, Language, RequestType, сформировать RegFormData в виде:

  1. Заполнить шаблон RegTemplate и PolicyText, соответствующие RequestType, PAN и Language

  1. Включить RegFormID и RegFieldSeq. В случае обновления поле RegFieldSeq может быть опущено.
  2. Опционно добавляется URL для отображения логотипа платежной системы или карты.

  • CertReq должно быть зашифровано с помощью ключа, отличного от того, который использовался в случае RegFormReq. Внести CAEThumb с оттиском, отличным от посланного в CardCInitRes.
    • Если подходящей регистрационной формы для владельца карты нет, сформировать структуру ReferralData:

        1. Заполнить поле причины информацией об отказе обслуживания, которая будет отображена владельцу карты.
        2. Опционно записать в поле ReferralLoc почтовый адрес и/или URL, где пользователь может получить дополнительную информацию о причине отказа обслуживания.

        2

        Подписать результат шага 1 (то есть данные RegFormTBS), установить contentType для SignedData равным id-set-content-RegFormTBS.

        3

        Сформировать цифровой конверт сообщения и послать владельцу карты RegFormRes

        <


        Начало  Назад  Вперед



        Книжный магазин