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

Структура PReq для PReqDualSigned и PreqUnsigned



Таблица 4.6.2.59. Структура PReq для PReqDualSigned и PreqUnsigned

OIData {TransIDs, RRPID, Chall-C, HOD, ODSalt, [Chall-M], BrandID, BIN, [ODExtOIDs], [OIExtensions]}
TransIDs Копируется из PInitRes, если имеется
RRPID ID пары запрос/отклик
Chall-C Копируется из соответствующего PInitReq (см. табл. 4.6.2.55)
HOD DD(HODInput)



Связывает OIData с PurchAmt без копирования PurchAmt в OIData, что может привести к проблемам с конфиденциальностью

ODSalt Копируется из HODInput
Chall-M Вызов продавца владельцу карты относительно свежести подписи
BrandID Выбранная владельцем карты платежная система
BIN Идентификационный номер банка из номера счета владельца карты (первые 6 цифр)
ODExtOIDs Список объектных идентификаторов из ODExtensions
OIExtensions Данные в расширении к OI должны относиться к обработке заказа продавцом. Информация заказа незашифрованна, по этой причине здесь не должно быть конфиденциальной информации.
HODInput {OD, PurchAmt, PurchAmt, [InstallRecurData], [ODExtensions]}
OD Описание заказа (Order Description). Обмен этой информацией происходит между владельцем карты и продавцом (не регламентируется SET). Здесь могут содержаться данные о качестве товара, размере, цене, адресе поставки и т.д.
PurchAmt Число транзакций, как это определено владельцем карты. Значение должно соответствовать PIHead (табл. 4.6.2.40).
ODSalt Новое значение Nonce, сгенерированное владельцем карты, чтобы препятствовать атакам на HOD.
InstallRecurData См. табл. 4.6.2.41
ODExtensions Данные в этом расширении OD должны относиться к обработке заказа продавцом. Эта информация должна быть известна независимо владельцу карты и продавцу.

При получении PReq продавец производит следующие действия.

Шаг Действие
1 Извлекает PReq из входного сообщения
2 Если получено PReqDualSigned, производит проверку подписи;

  • Извлекает OIData и HPData из OIDualsigned

  • Формирует HOIData в виде дайджеста OIData

  • Формирует PI-TBS в виде объединения HPOData из пункта А и HOIData из пункта В.

  • Генерирует подпись с помощью оператора SO, используя сертификат владельца карты (параметр s) и PI-TBS из пункта С (параметр t).

  • Сравнивает подпись из пункта D с PISignature. Если они не тождественны, послает сообщение Error c ErrorCode равным signatureFailure и останавливает обработку PReq.

  • Переходит к выполнению пункта 4.

    		•
    3 Если получено PReqUnsigned, проверяет, что сертификат платежной системы (Cert-PE) допускает PReqUnsigned. Если нет, то:

      1. Возвращает сообщение PRes c CompletionCode=signatureDequired (необходима подпись)

      2. Останавливает обработку PReq
    4 Производит обработку TransIDs:

    Проводит поиск транзакций, базирующихся на XID.

    Если запись такой транзакции найдена

    Сравнивает LID-C и LID-M с записью. Если соответствия нет:

  • Возвращает сообщение Error c ErrorCode = unknownLID

  • Останавливает обработку PReq

    • В противном случае сверяет Chall-M с записью. Если соответствия нет, то:

  • Присылает сообщение Error c ErrorCode = challengeMismatch

  • Останавливает обработку PReq

    • В противном случае

  • Формирует новую запись транзакции

  • Спасает LID-C, PReqDate и Language

  • Опционно формирует LID-M

    		•
    5 Проверяет, что BrandID в сертификате владельца карты соответствует BrandID в PInitReq и/или OIData. Если соответствия нет, то:

  • Присылает сообщение PRes c completionCode = orderRejected (заказ отклонен)

  • Останавливает обработку PReq

    		•
    6 Запоминает Chall-C, чтобы вернуть его в последующем PRes
    7 Запоминает оставшиеся переменные из сообщения в базе данных
    8 Сверяет HOD c сформированным хэшем OD, PurchAmt, ODSalt, InstallRecurData (если имеется) и ODExtensions (если имеется)
    9 Начиная с этого момента, продавец может, если захочет, послать PRes владельцу карты, или ждать пока от расчетного центра не будет получено сообщение AuthRes
    <
    После обработки PReq продавец формирует отклик PRes согласно следующему алгоритму:

    Шаг Действие
    1 Сформировать PResData:
  • Заполнить поле TransIDs. Включить сюда все поля TransIDs, полученные от владельца карты или расчетного центра

  • Скопировать RRPID из PReq (или из InqReq)

  • Скопировать Chall-C из PReq (или из InqReq)

  • Если для текущего BrandCRLIdentifier не получены оттиски (или они устарели), заполнить поле текущим значением BrandCRLIdentifier

  • Сформировать PresPayloadSeq:


      1. Если запрос покупки включает в себя PurchAmt = 0, сформировать единичный PresPayload c CompletionCode = meaninglessRatio и с пустыми остальными полями. Перейти к пункту 2.

      2. Если расчетный центр отклонил заказ, сформировать PresPayload:

    1. Установить CompletionCode = orderReject

    2. Скопировать AcqCardMsg из AuthRes, если имеется.

    3. Перейти к пункту 2


        1. Если расчетный центр еще не посылал отклик на запрос авторизации продавца, сгенерировать PresPayload c CompletionCode = orderReceived и пустыми прочими полями. Перейти к пункту 2.

        2. Если это отклик на запрос InqReq, где транзакция не была найдена, сформировать PresPayload c CompletionCode = orderNotReceived и пустыми прочими полями. Перейти к пункту 2.

        3. Если расчетный центр откликнулся на запрос авторизации продавца, сформировать PresPayloadSeq, как это описано ниже
    2 Ввести Compose SignedData
    3 Вставить сообщение в цифровой конверт и послать владельцу карты

    Для каждой авторизации, которую провел продавец и которая не отменена, формируется PresPayload:

    Шаг Действие
    1 Если выполнена только авторизация:
  • Установить CompletionCode = authorizationPerformed

  • Сформировать Results, как это описано ниже, опуская CapStatus и CredStatusSeq.
    		•
    2 Если оплата (capture) выполнена:
  • Установить CompletionCode = capturePerformed

  • Сформировать Results, как это описано ниже, опуская CredStatusSeq
    		•
    3 Если кредитование осуществлено;
  • Установить CompletionCode = creditPerformed

  • Сформировать Results, как это описано ниже
    		•
    4 Опционно добавить любые PRsExtensions
    <


    Формирование поля Results производится согласно следующему алгоритму:

    Шаг Действие
    1 Скопировать AcqCardMsg из AuthRes, если этот отклик имеется
    2 Если позиция авторизована, сформировать AuthStatus:
  • Скопировать AuthDate из записи транзакции

  • Скопировать AuthCode из записи транзакции

  • Вычислить AuthRatio, как AuthReqAmt ? PurchAmt

  • Если в AuthRes присутствуют данные о конвертации валюты, скопировать их
    		•
    3 Если позиция оплачена, сформировать CapStatus:
  • Скопировать CapDate из записи транзакции

  • Скопировать CapCode из записи транзакции

  • Вычислить CapRatio, как CapReqAmt ? PurchAmt
    		•
    4 Сформировать CredStatusSeq как последовательность CredStatus для каждой выполненной и не отмененной кредитной операции. Сформировать CredStatus:
  • Скопировать CreditDate из записи транзакции

  • Скопировать CreditCode из записи транзакции

  • Вычислить CreditRatio, как CapRevOrCredReqAmt ?
    PurchAmt
    		•

    Структура данных сообщения PRes, формируемого продавцом, представлена в таблице 4.6.2.60.

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