Интегрированные сети ISDN
Авторизация платежей
Рисунок 4.6.2.17. Авторизация платежей
Процесс авторизации проходит через три состояния. Во время обработки заказа от владельца карты продавец авторизует транзакцию. Программа продавца формирует и цифровым образом подписывает авторизационный запрос, который включает в себя сумму платежа, подлежащую авторизации, идентификатор транзакции из OI и некоторые другие данные. Запрос затем шифруется с использованием нового случайного симметричного ключа, который в свою очередь шифруется общедоступным ключом расчетного центра. Это тот самый ключ, который использовал владелец карты для шифрования цифрового конверта с платежными инструкциями. Запрос авторизации и платежные инструкции владельца карты передаются в расчетный центр.
Когда расчетный центр получает авторизационный запрос, он дешифрует цифровой конверт запроса и извлекает из него симметричный ключ. Этот ключ используется для дешифрования текста запроса. Далее верифицируется сертификат подписи продавца срок его действия, а также цифровая подпись.
После этого расчетный центр дешифрует цифровой конверт платежных инструкций (PI), откуда извлекается симметричный ключ и информация о счете клиента. Ключ используется для дешифрования PI. Используя общедоступный ключ владельца карты и дайджест OI (включенный в PI), проверяется цифровую подпись, чтобы убедиться, что PI не модифицированы и что они подписаны с использованием секретного ключа владельца карты.
Расчетный центр проверяет, что идентификатор транзакции, полученный от продавца, соответствует идентификатору, присланному в PI. При успешном завершении этих проверок расчетный центр формирует и отсылает через финансовую сеть авторизационный запрос эмитенту карты.
При получении отклика авторизации от эмитента расчетный центр генерирует и подписывает цифровым образом авторизационный отклик, который содержит отклик эмитента и копию сертификата подписи расчетного центра. Этот отклик может также включать в себя платежный маркер (capture token) с данными, которые будут нужны расчетному центру для обработки платежного запроса.
Платежный маркер вставляется в отклик только в случае, если этого требует банк продавца (Получатель).
Отклик шифруется с помощью вновь сформированного секретного симметричного ключа, который в свою очередь шифруется общедоступным ключом продавца. После шифрования отклик посылается продавцу.
Когда программа продавца получает авторизационный отклик из расчетного центра (РЦ), она дешифрует цифровой конверт и извлекает оттуда симметричный ключ, посредством которого дешифруется текст отклика. Продавец верифицирует сертификат подписи расчетного центра, а посредством общедоступного ключа РЦ и его цифровую подпись.
Продавец запоминает авторизационный отклик и платежный маркер для последующего использования при обработке платежных запросов. Далее продавец может осуществлять доставку товаров или услуг, оговоренных в заказе.
Обмен AuthReq/AuthRes возможен как для исключительно авторизованных транзакций, так и транзакций оплаты. Пара запрос/отклик автортизации предоставляет механизм авторизации сделки. В запросе авторизации продавец посылает подписанные и зашифрованные данные о покупке, а также инструкцию PI, полученную от владельца карты. Так как каждая из секций содержит хэш OD и количества (Amount), расчетный центр может проверить то, что владелец карты и продавец договорились о заказе и сумме, которые следует авторизовать. Так как PI включает данные платежной карты, необходимые для авторизации, расчетный центр может выполнить авторизацию, используя существующую финансовую сеть платежной карты.
Когда продавец заранее знает, что заказ будет выполняться по частям (несколько поставок), он осуществит несколько шагов AuthReq (по одному для каждой части). Продавец устанавливает в первом AuthReq значение SubsequentAuthInd равным TRUE, что представляет собой указание на авторизацию выполнения первой части заказа. Расчетный центр пришлет в отклике AuthRes значение AuthToken. Продавец будет вынужден выполнить дополнительные запросы AuthReq для реализации последующих этапов выполнения заказа.
В каждое последующее сообщение AuthReq продавец должен включать значение AuthToken из предшествующего отклика расчетного центра. В последнем AuthReq продавец установит значение SubsequentAuthInd равным FALSE. Когда продавец обнаруживает, что заказ будет выполняться поэтапно после отправки AuthReq, он должен послать AuthRevReq, чтобы согласовать число дополнительных авторизаций, и установить SubsequentAuthInd = TRUE, для получения AuthToken в последующих откликах AuthRes. Алгоритм формирования AuthReq представлен ниже.
| Шаг | Действие |
| 1 | Сгенерировать AuthTags (см. табл. ниже) |
| 2 | Сгенерировать HOD2 путем хэширования OD, PurchAmt, ODSalt, ODExtensions и, если имеется, InstallRecurData. Расчетный центр сравнит его значение с полученным в PI. |
| 3 | Сгенерировать AuthReqPayload (см. табл. ниже) |
| 4 | Опционно для одновременной авторизации и резервирования заказа: Может так случиться, что банк продавца не может выполнить одновременно авторизацию и платеж для данного заказа даже при CaptureNow=TRUE. В этом случае AuthCode=captureNotSupported укажет на то, что производится только авторизация. Продавец может послать позднее запрос CapReq, чтобы выполнить платеж для данного заказа. |
| 5 | Включить CheckDigest с вычисленными продавцом H(OIData) и HOD2. H(PIData) копируется продавцом из PReq. Это поле опускается, если запрос AuthReq представляет последовательную авторизацию, базирующуюся на присланном из расчетного центра коде AuthToken. |
| 6 | Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, хранимых продавцом. Продавец должен внести в сообщение оттиски, которые могут потребоваться позднее для верификации подписи и сертификатов расчетного центра. |
| 7 | Осуществить EncB-инкапсуляцию |
| 8 | Включить сертификаты подписи и шифрования отправителя и всей цепи сертификации вплоть до сертификата платежной системы. |
| 9 | Поместить сообщение в цифровой конверт и отправить адресату |
/p> Процедура формирования AuthTags показана в таблице ниже.
| Шаг | Действие |
| 1 | Заполнить поле AuthRRTags (см. табл. 4.6.2.52) |
| 2 | Заполнить поле TransIDs. Если это последовательная авторизация и определено PaySysID, занести его значение в поле PaySysID. |
| 3 | Если это многоэтапный платеж и банк продавца задал для авторизации значение AuthRetNum, скопировать AuthRetNum из предыдущего AuthRes |
| Шаг | Действие |
| 1 | Если планируется обработка последовательных авторизаций для покупки и это не последняя авторизация, установить SubsequentAuthInd равным TRUE, в противном случае FALSE. |
| 2 | Если продавец и владелец карты договорились о рекуррентных или поэтапных платежах, заполнить поле InstallRecurData |
| 3 | Установить AuthReqAmt равным числу авторизаций |
| 4 | Опционно присвоить CardSuspect соответствущее значение, если продавец имеет какие-то подозрения относительно владельца карты. |
| 5 | Если при некотором платеже необходимы данные MerchData, добавить их в сообщение. |
| 6 | Сформировать MarketSpecAuthData, если это диктуется платежной системой карты или типом покупки. |
| 7 | Если политика платежной системы карты требует наличия AVSData, записать в это поле информацию, предоставленную владельцем карты. |
| 8 | Если политика платежной системы карты требует наличия SpecialProcessing, сгенерировать его значение. |
| 9 | Если продавец требует информацию о типе платежной карты, установить RequestCardTypeInd = TRUE. |
