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

         

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


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
    <

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