Телекоммуникационные технологии
SET и другие системы осуществления платежей - часть 98
Сообщение PReq не обязательно следует за сообщениями PInitReq/PInitRes. Сообщение же PRes может быть прислано до выполнения авторизации и оплаты. Если владелец карты обладает сертификатом, то для обеспечения целосности и аутентичности сообщения выполняется двойная подпись.
PReq представляет собой наиболее сложное сообщение в протоколе. Оно состоит из двух частей: инструкции-заказа OI (Order Instruction) для продавца и платежной инструкции PI (Payment Instruction), которая проходит транзитом через продавца в расчетный центр. Эти две части принципиально должны подписываться независимо. Продавец получает описание заказа OD (Order Description) и PurchAmt. В PI включаются хэши OD и PurchAmt (HODINput). Расчетный центр проверяет, что хэш передан покупателем (владельцем карты) через продавца и равен хэшу, выданному продавцом в AuthReq. Некоторые владельцы карт могут не иметь сертификатов. Сообщения от таких владельцев не будут подписаны, вместо этого PIHead связывается с OIData. Целостность таких сообщений обеспечивается следующими мерами:
- C PI используется OAEP
- В блок OAEP включается H(PIHead) (вместе с PANData)
- С PIHead используется H(OIData)
- Расчетным центром производится сравнение H(OIData), присланного продавцом, с H(OIData) из PIHead.
Владелец карты формирует сообщение PReq следующим образом (эти действия предпринимаются как для PReqUnsigned так и для PreqDualSigned).
| Шаг | Действие | ||
| 1 | Извлечь PurchAmt и OD | ||
| 2 | Сформировать OIData следующим образом: | ||
| a) | Если имел место обмен PInitReq/ PInitRes: | Скопировать TransIDs из PInitRes | |
| В противном случае: | Для формирования TransIDs владелец карты сгенерирует PreqDate (текущие дата/время), LID-C и XID | ||
| b) | Сформировать новый RRPID, запомнить его значение для сверки с откликом продавца | ||
| Если имел место обмен PInitReq/PInitRes: | Скопировать Chall-c из PInitRes | ||
| В противном случае: | Сформировать новый Chall-C | ||
| c) | Сформировать новый ODSalt | ||
| d) | Сформировать HODInput посредством следующей процедуры:
| ||
| e) | Сформировать HOD с HODInput из пункта 2 d | ||
| f) | Если имел место обмен PInitReq/ PInitRes: | Скопировать Chall-M из PInitRes и не заполнять BrandID | |
| В противном случае: | Не заполнять Chall-M Записать BrandID, указав предпочтительный тип карты | ||
| g) | Произвести записьв поле BIN с HODInput из пункта 2d | ||
| h) | Если HODInput из шага 2.d имеет какие-то расширения OIExtensions, внести ODExtOIDs со всеми OID в ODExtensions. ODExtOIDs будут перечислены в том же порядке, что и расширения ODExtensions, таким образом продавец сможет вычислить тот же самый хэш | ||
| i) | Опционно: добавить любые расширения OIExtensions. | ||
| 3 | Сформировать PIHead следующим образом: | ||
| a) | Скопировать TransIDs, вычисленные в пункте 2.а | ||
| b) | Сгенерировать Inputs согласно процедуре:
| ||
| c) | Скопировать MerchandID из сертификата продавца в PInitRes, или из CD-ROM-каталога | ||
| d) | Скопировать InstallRecurData из пункта 2.d.4 (если имеется) | ||
| e) | Сформировать TransStain, как HMAC, используя XID в качестве данных и CardSecret - в качестве ключа. Если владелец карты не имеет сертификата, использовать CardSecret, заполненный нулями. | ||
| f) | Записать SWIdent, который получен из локальных данных. Это значение будет соответствовать коду в цифровом конверте сообщения | ||
| g) | Если присутствует туннельное расширение Cert_PE, сформировать AcqBackInfo следующим образом: | ||
| h) | Опционно добавить любые PIExtensions | ||
| 4 | Сформировать PANData | ||
| 5 | Сгенерировать PU-OIData c L-оператором, используя PIHead из пункта 3 (параметр t1) и OIData из пункта 2 (параметр t2) | ||
| 6 | Используя результат пунктов 2, 3 и 4, сгенерировать PreqDualSigned, если владелец карты имеет сертификат или PreqUnsigned, если сертификата нет. | ||
