Телекоммуникационные технологии


         

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


br>

Поля данных 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 в виде:


  • Заполнить шаблон 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
    <

    Содержание  Назад  Вперед