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

Структура AuthReqPayload



Таблица 4.6.2.65. Структура AuthReqPayload



AuthReqPayload

{SubsequentAuthInd, AuthReqAmt, [AVSData],

[SpecialProcessing], [CardSuspect],

RequestCardTypeInd, [InstallRecurData],

[MarketSpecAuthData], MerchData, [ARqExtensions]}

SubsequentAuthInd

 Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки

AuthReqAmt

 Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие

AVSData

{[StreetAddress], Location}

Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET.

SpecialProcessing

 Числовое поле, указывающее тип запрошенной обработки

CardSuspect

 Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения

RequestCardTypeInd

 Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0).

InstallRecurData

 См. табл. 4.6.2.41.

MarketSpecAuthData

< MarketAutoAuth, MarketHotelAuth, MarketTransportAuth >

Специфические авторизационные данные рынка

MerchData

{[MerchCatCode], [MerchGroup]}

ARqExtensions

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

StreetAddress

 Адрес улицы владельца карты

MarketAutoAuth

{Duration}

MarketHotelAuth

{Duration, [Prestige]}

MarketTransportAuth

{}

В настоящее время нет авторизационных данных для этого сегмента рынка

MerchCatCode

 4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца.

MerchGroup

 Числовой код, идентифицирующий общую категорию продавца

Duration

 Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture).

Prestige

 Числовой тип приоритета, определяется платежной системы карты.
<
Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.

Шаг Действие
1 Извлечь запрос из транспортного сообщения
2 Дешифровать PI
3 Сравнить TransIDs из AuthTags и PIHead или AuthToken:
  • Проверить что коды XID идентичны

  • Проверить что коды LID-C идентичны

  • Если LID-M присутствуют в AuthTags и PIHead, сравнить их значения

    • Если хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch
    4 Если PI является AuthToken:
  • Обработать AuthToken

    • В противном случае, если PI подписаны:
  • Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch.

  • Проверить PANData

  • Запомнить данные из PANData

    • В противном случае, если PI не подписаны:
  • Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired

  • Верифицировать хэш в EXH

  • Запомнить данные из PANToken
    		•
    5 Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed
    6 Обработать PIHead:
  • Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами.

  • Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией.

  • Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch.

  • Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch

  • Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension

  • Запомнить данные от PIHead
    		•
    7 Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch.
    8 Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется.
    9 Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported
    10 Выполнить авторизацию через финансовую сеть платежной карты
    11 Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты
    12 Продолжить формирование сообщения AuthRes
    <


    Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.

    Шаг Действие
    1 Получить необходимые данные от авторизационного процесса
    2 Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса.
    3 Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел.
    4 Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра:
  • Вставить Cert-PE в цифровой конверт PKCS#4

  • Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
    		•
    5 Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса
    6 Заполнить поле PANToken, если это необходимо для сертификата продавца,
    7 Заполнить AuthResBaggage (опционно):
  • Опционно заполнить CapToken

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

  • Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE).

    • Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью.
    8 Опционно заполнить BatchStatus, как этого требует политика платежной системы карты.
    9 Если PANToken имеется, реализовать EncBX-инкапсуляцию
    10 Вставить сообщение в цифровой конверт и отправить владельцу карты

    Расчетный центр формирует AuthResPayload следующим образом.

    Шаг Действие
    1 Сгенерировать CapResPayload
    Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса
  • Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq.

  • Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported
    		•
    3 Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты.
    4 Заполнить ResponseData:
  • Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса.

  • Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса.

  • Занести в AuthCharInd значение, присланное авторизационным процессом
    		•

    Структура полей AuthRes представлена в таблице 4.6.2.66.

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