Интегрированные сети 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: |
| 3 | Если в сообщение включен BrandCRLIdentifier, запомнить CRL. |
| 4 | Обработать AuthResPayload |
| 5 | Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата |
| 6 | Если BatchStatus присутствует, обработать и запомнить данные. |
| 7 | Обработать AuthResBaggage: Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken |
| 8 | Если присутствует PANToken, записать его в безопасную локальную память |
| 9 | Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку. |
Алгоритм обработки AuthResPayload представлен ниже.
| Шаг | Действие |
| 1 | Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется. |
| 2 | Обрабатать CapResPayload: Если делался запрос оплаты (capture), будет возвращен CapResPayload |
| 3 | Если имеется CurrConv, запомнить его для переадресации владельцу карты |
| 4 | Обработать AuthCode, AuthAmt и ResponseData: |
Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется 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 будет использоваться для авторизации покупок при последующих частичных поставках.
