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

         

Структура AuthResPayload



Таблица 4.6.2.67. Структура AuthResPayload



AuthResPayload

{AuthHeader, [CapResPayload], [ARsExtensions]}

AuthHeader

{AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]}

CapResPayload

Присылается, если CaptureNow

имеет значение TRUE в AuthReq. См. табл. 4.6.2.71.

ARsExtensions

Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика.

AuthAmt

Копируется из AuthReqPayload.AuthReqAmt

AuthCode

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

ResponseData

{[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]}

BatchStatus

См. табл. 4.6.2.53.

CurrConv

{CurrConvRate, CardCurr}

AuthValCodes

{[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]}

RespReason

Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется)

CardType

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

AVSResult

Числовой код отклика адресной верификационной службы

LogRefID

Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса)

CurrConvRate

Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты.

AuthReqAmt

Код валюты владельца карты в стандарте ISO 4217

ApprovalCode

Код одобрения, присваиваемый транзакции эмитентом

AuthCharInd

Числовое значение, которое указывает условия, при которых выполнена авторизация.

ValidationCode

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

MarketSpecDataID

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

Список возможных значений кода AuthCode приведен ниже

approved Запрос авторизации удовлетворен
unspecifiedFailure Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке.
declined Запрос авторизации отклонен
noReply Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента.
callIssuer Эмитент запрашивает телефонный вызов от продавца
amountError Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.)
expiredCard Срок действия карты истек
invalidTransaction Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым.
systemError Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные.
piPreviouslyUsed Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром).
recurringTooSoon Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром).
recurringExpired Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром)
piAuthMismatch Дата в PI от владельца карты не согласуется с данными в OD от продавца.
installRecurMismatch InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца.
captureNotSupported Расчетный центр не поддерживает платеж (capture).
signatureRequired Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы.
cardMerchBrandMismatch Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра.
<
Обработка продавцом отклика AuthRes производится следующим образом.

Шаг Действие
1 Получить отклик из входного сообщения
2 Извлечь запись транзакции и сравнить с AuthTags:
  • Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID

  • Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID.
  • 3 Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
    4 Обработать AuthResPayload
    5 Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата
    6 Если BatchStatus присутствует, обработать и запомнить данные.
    7 Обработать AuthResBaggage:
  • Запомнить CapToken, если это поле присутствует

  • Если имеется AcqCardMsg, запомнить его для отправки владельцу карты

  • Запомнить AuthToken, если имеется, для последующей авторизации.

  • Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken
    8 Если присутствует PANToken, записать его в безопасную локальную память
    9 Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку.

    Алгоритм обработки AuthResPayload представлен ниже.

    Шаг Действие
    1 Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется.
    2 Обрабатать CapResPayload:
  • Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension

  • Обработать CapCode с целью определения результата

  • Обработать SaleDetail в соответствии с политикой платежной системы карты

  • Для успешной оплаты заказа, записать CapCode и CapAmt.

  • Если делался запрос оплаты (capture), будет возвращен CapResPayload
    3 Если имеется CurrConv, запомнить его для переадресации владельцу карты
    4 Обработать AuthCode, AuthAmt и ResponseData:
  • Для определения результата обрабатывается AuthCode.

  • Запомнить AuthCode и AuthAmt для получения успешного результата.

  • Запомнить ValidationCode для успешного исхода, если это поле имеется.

  • Запомнить AuthValCode, если имеется.

  • Запомнить AVSResult, если имеется.

  • Запомнить LogRefID, если имеется.
  • <


    Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode.
    Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0).
    При этом код отклика не переписывается.
    Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode.
    Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode.
    Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации.
    Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture).Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE. Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках.

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