Интегрированные сети ISDN
Обработка платежных запросов
Рисунок 4.6.2.18. Обработка платежных запросов
После завершения обработки заказа владельца карты продавец осуществляет запрос платежа. Между запросами авторизации и запросом платежа может быть достаточно большая задержка.
Программа продавца генерирует платежный запрос, снабженный цифровой подписью. Этот запрос содержит итоговую сумму транзакции, ее идентификатор из OI и другую информацию о транзакции. Запрос шифруется с использованием вновь сформированного симметричного ключа, который в свою очередь шифруется с привлечением общедоступного ключа расчетного центра. Запрос платежа и опционно платежный маркер (capture token), если таковой был включен в авторизационный отклик, пересылаются в расчетный центр. В общем случае в одном сообщении может быть заключено несколько платежных запросов.
Когда расчетный центр получает запрос платежа, он дешифрует цифровой конверт, извлекает из него симметричный ключ и дешифрует с его помощью текст платежного запроса. Далее посредством общедоступного ключа продавца верифицируется его цифровая подпись. Расчетный центр дешифрует платежный маркер (если таковой имеется) и использует платежный запрос и маркер для формирования клирингового запроса, который направляется эмитенту карты через платежную систему кредитной карты.
После этого расчетный центр генерирует платежный отклик, снабженный цифровой подписью. Этот отклик содержит в себе копию сертификата подписи расчетного центра. Отклик шифруется с использованием нового симметричного ключа и переправляется продавцу.
Когда продавец получает платежный отклик из расчетного центра (РЦ), он дешифрует цифровой конверт, извлекает из него симметричный ключ и с его помощью дешифрует полученный текст отклика. Далее верифицируется сертификат подписи расчетного центра и цифровая подпись РЦ. Продавец запоминает платежный отклик для последующего использования при контроле платежей, поступающих из его банка.
Пары запросов CapReq/CapRes предоставляют механизм завершения ранее авторизованного денежного платежа.
Размер платежа определяется на фазе обмена авторизационными сообщениями. Продавец не должен посылать запрос CapReq для ранее успешно прошедших платежей. Возможно осуществление платежей с помощью пар сообщений, выходящих за пределы протокола SET. Формирование запроса CapReq продавцом осуществляется следующим образом.
| Шаг | Действие |
| 1 | Заполнить поле CapRRTags |
| 2 | Опционно заполнить поля AuthReqData и AuthResPayload. Процедура опускается, если информация содержится в CapToken |
| 3 | Рекомендуется заполнить MThumbs всех сертификатов для расчетного центра, куда посылается это сообщение, для CRL и для BrandCRLIdentifier |
| 4 | Заполнить один или более CapItem в CapSeq следующим образом. Для каждого CapItem: |
| 5 | Заполнить CapTokSeq с помощью CapToken из соответствующих сообщений AuthRes, полностью тождественных с CapItem в CapSeq. Если CapToken для транзакции отсутствует, заносится нуль. |
| 6 | В дополнительные позиции инкапсуляции EncBX заносятся PANToken, если продавец получил PANToken |
| 7 | Опционно заполняется CRqExtensions |
| 8 | Если включено PANToken, использовать EncBХ-инкапсуляцию |
| 9 | Если PANToken не включено, использовать EncB-инкапсуляцию |
| 10 | Вложить сообщение в цифровой конверт и послать владельцу карты |
| Шаг | Действие |
| 1 | Занести в поле CapDate текущее значение даты |
| 2 | Занести в CapReqAmt сумму выплаты |
| 3 | Скопировать AuthResPayload из соответствующего AuthRes |
| 4 | Опционно заполнить CPayExtensions |
