Приложение 1. USAePay Ключевые поля, возвращаемые API шлюза USAePay

Приложение 1. USAePay1
Ключевые поля, возвращаемые API шлюза USAePay
UMstatus
UMauthCode
UMavsResult
UMavsResultCode
UMcvv2Result
UMcvv2ResultCode
UMresult
UMerror
UMacsurl
UMpayload
1
Статус транзакции. Возможные значения: Approved, Declined, Verification
and Error.
Код авторизации
Результат AVS (Address Verification Service) в «человекопонятном» формате
Код AVS
CVV2 в «человекопонятном» формате
Код CVV2
Результат транзкции
Код ошибки в случае, если статус транзакции Declined
Адрес, на который надо перенаправить кардхолдера в случае, если
необходима его аутентификация (посылается если статус транзакции
Verification)
Аутентификационные данные, которые необходимо передать на адрес
аутентификации кардхолдера (посылается, если статус транзакции
Verification)
Материалы взяты с сайта http://www.usaepay.com
Приложение 2. WebMoney2
Конфигурируемые торговцем параметры Web-Merchant-Interface ЦПС WebMoney и их
описания
Название параметра
Result URL
Формат
255
символов
(case
sensitive)
Success URL
255
символов
(case
sensitive)
Метод вызова Success URL Fail URL
255
символов
(case
sensitive)
метод вызова Fail URL
-
Метод формирования
контрольной подписи
оповещения о платеже
-
Тестовый/Рабочий
-
2
Описание
URL (на веб-сайте продавца), на который сервис Web
Merchant Interface посылает HTTP POST или SMTPоповещение о совершении платежа с его детальными
реквизитами. Если продавец не определил этот URL, он
не будет оповещаться сервисом о совершенных
платежах.
URL должен начинаться с префикса "http://", "https://"
или "mailto:". В последнем случае оповещение будет
высылаться на e-mail, указанный после префикса,
например, при указании mailto:shop@address.com
оповещение будет выслано на e-mail shop@address.com).
При использовании префикса "http://" или "https://"
сервис посылает оповещение по портам 80 и 443
соответственно. Причем вызов Result URL выполняется
два раза. Первый раз непосредственно перед
выполнением платежа (для проверки работоспособности
веб-сайта продавца), второй раз – сразу после успешного
выполнения платежа (для передачи параметров
платежа). При первом вызове, если установлен флаг
Передавать параметры в предварительном запросе,
параметры предаются с использованием Формы
предварительного запроса. Если флаг не установлен,
вызов идет без параметров. При втором вызове
параметры передаются через Форму оповещения о
платеже.
URL (на веб-сайте продавца), на который будет
переведен интернет-браузер покупателя в случае
успешного выполнения платежа в сервисе Web Merchant
Interface. URL должен иметь префикс "http://" или
"https://".
Метод (POST, GET или LINK), который будет
использоваться при переходе на Success URL.
URL (на веб-сайте продавца), на который будет
переведен интернет-браузер покупателя в том случае,
если платеж в сервисе Web Merchant Interface не был
выполнен по каким-то причинам. URL должен иметь
префикс "http://" или "https://".
Метод (POST, GET или LINK), который будет
использоваться при переходе на Fail URL.
Алгоритм, который Web Merchant Interface использует
для контроля подлинности оповещения, высылаемого на
сайт продавца при выполнении платежа через сервис.
Поддерживается два варианта: MD5 и SIGN
(рекомендуется).
Флаг, устанавливающий режим обработки платежей в
Материалы взяты с сайта http://www.webmoney.ru
режимы:
Активность
Secret Key
Высылать Secret Key на
Result URL, если Result
URL обеспечивает
секретность
Позволять использовать
URL, передаваемые в
форме
Передавать параметры в
предварительном запросе
Высылать оповещение об
ошибке платежа на кипер
сервисе. В тестовом режиме Web Merchant Interface
имитирует выполнение платежей (реально платежи не
выполняются). По умолчанию выставляется тестовый
режим.
Флаг, разрешающий или запрещающий прием платежей
на кошелек продавца через сервис. Если флаг
установлен в состояние "Выкл.", Web Merchant Interface
во всех случаях будет сообщать покупателю о
невозможности выполнения платежа.
50 символов Строка символов, добавляемая к реквизитам платежа,
(case
высылаемым продавцу вместе с оповещением. Эта
sensitive)
строка используется для повышения надежности
идентификации высылаемого оповещения. Содержание
строки известно только сервису Web Merchant Interface и
продавцу!
Флаг, сообщающий сервису Web Merchant Interface о
том, что Secret Key должен быть добавлен к
высылаемому на веб-сайт продавца оповещению о
платежах в том случае, если канал обеспечивает
безопасную передачу на Result URL (используется
протокол SSL, то есть Result URL имеет префикс
"https://").
Если Result URL не использует SSL, то Secret Key
высылаться не будет, даже если флаг установлен.
Флаг, оповещающий Web Merchant Interface о том, что
Result URL, Success URL, метод вызова Success URL ,
Fail URL и метод вызова Fail URL могут быть
изменены в "Payment Request Form".
Флаг, сообщающий сервису Web Merchant Interface о
том, что в запросе, передаваемом на Result URL вебсайта продавца непосредственно перед попыткой
выполнения платежа, необходимо передать параметры
через Форму предварительного запроса. В случае, если
флаг не установлен, Предварительный запрос идет без
передачи параметров. Если флаг передачи параметров
установлен, веб-сайт продавца должен вернуть сторку
"YES" в ответе для того, чтобы сервис Web Merchant
Interface смог продолжить выполнение платежа. Если
веб-сайт продавца вернет что-либо другое - платеж
выполнен не будет, а ответ покупателю будет показано в
сообщении об ошибке.
Флаг, оповещающий Web Merchant Interface о том, что в
случае возникновения ошибки при выполнении платежа
необходимо послать оповещение на кипер продавца.
Параметры формы запроса платежа
Название
HTML Field Name
Кошелек
продавца
LMI_PAYEE_PURSE
Обязательный?
Да
Описание
Кошелек продавца, на который покупатель
должен совершить платеж. Формат - буква и
12 цифр.
Сумма платежа
LMI_PAYMENT_AMO Да
UNT
Внутренний
номер покупки
продавца
LMI_PAYMENT_NO
Назначение
платежа
LMI_PAYMENT_DESC Нет
Режим
тестирования
LMI_SIM_MODE
Нет
Нет
Замена Result
URL
LMI_RESULT_URL
Нет
Замена Success
URL
LMI_SUCCESS_URL
Нет
В настоящее время допускается
использование кошельков Z-,R-,E- и D-типа.
Сумма платежа, которую продавец желает
получить от покупателя. Сумма должна быть
больше нуля, дробная часть отделяется
точкой.
В этом поле продавец задает номер покупки
в соответствии со своей системой учета.
Несмотря на то, что параметр не является
обязательным, мы рекомендуем всегда
задавать его. Желательно использовать
уникальный номер для каждого платежа, что
позволит быстро получить относящуюся к
нему информацию через другие интерфейсы
системы WebMoney Transfer.
Номер должен представлять собой целое
число без знака не больше 2147483647.
Описание товара или услуги. Формируется
продавцом.
Если присутствует, добавляется в назначение
платежа в операцию перевода WM.
Максимальная длина - 255 символов.
Дополнительное поле, определяющее режим
тестирования. Действует только в режиме
тестирования и может принимать одно из
следующих значений:

0 или не отсутствует: Для всех
тестовых платежей сервис будет
имитировать успешное выполнение;

1: Для всех тестовых платежей
сервис будет имитировать
выполнение с ошибкой (платеж не
выполнен);

2: Около 80% запросов на платеж
будут выполнены успешно, а 20% не выполнены.
Это поле позволяет продавцу временно
изменить параметр "Result URL",
установленный продавцом на странице
настроек сайта Web Merchant Interface.
Если в настройках установлен флаг
"Позволять использовать URL,
передаваемые в форме", то передаваемое
значение заменяет значение параметра
"Result URL", установленное в настройках
на сайте Web Merchant Interface. В
противном случае всегда используется
значение, установленное в настройках на
сайте Web Merchant Interface.
Формат этого поля должен строго
соответствовать значению параметра "Result
URL".
Это поле позволяет продавцу временно
изменить параметр "Success URL",
установленный им на странице настроек
Замена метода
вызова Success
URL
LMI_SUCCESS_METH Нет
OD
Замена Fail URL LMI_FAIL_URL
Нет
Замена метода
вызова Fail URL
Нет
LMI_FAIL_METHOD
сайта Web Merchant Interface.
Если в настройках установлен флаг
"Позволять использовать URL,
передаваемые в форме", то передаваемое
значение заменяет значение параметра
"Success URL", установленное в настройках
на сайте Web Merchant Interface. В
противном случае всегда используется
значение, установленное в настройках на
сайте Web Merchant Interface.
Формат этого поля должен строго
соответствовать значению параметра
"Success URL".
Это поле позволяет продавцу временно
изменить параметр "Метод вызова Success
URL", установленный им на странице
настроек сайта Web Merchant Interface.
Если в настройках установлен флаг
"Позволять использовать URL,
передаваемые в форме", то передаваемое в
форме значение заменяет значение
параметра "Метод вызова Success URL",
установленное в настройках на сайте Web
Merchant Interface. В противном случае
всегда используется значение, установленное
в настройках на сайте Web Merchant
Interface.
Это поле должно принимать значение 0, 1
или 2, что соответствует значениям
параметра "Метод вызова Success URL" "GET", "POST" или "LINK".
Это поле позволяет продавцу временно
изменить параметр "Fail URL",
установленный им на странице настроек
сайта Web Merchant Interface.
Если в настройках установлен флаг
"Позволять использовать URL,
передаваемые в форме", то передаваемое в
форме значение заменяет значение
параметра "Fail URL", установленное в
настройках на сайте Web Merchant Interface.
В противном случае всегда используется
значение, установленное в настройках на
сайте Web Merchant Interface.
Формат этого поля должен строго
соответствовать значению параметра "Fail
URL".
Это поле позволяет продавцу временно
изменить параметр "Метод вызова Fail
URL", установленный им на странице
настроек сайта Web Merchant Interface.
Если в настройках установлен флаг
"Позволять использовать URL,
передаваемые в форме", то передаваемое в
форме значение заменяет значение
параметра "Метод вызова Fail URL",
установленное в настройках на сайте Web
Дополнительные параметры
продавца
Определяется
продавцом
Нет
Merchant Interface. В противном случае
всегда используется значение, установленное
в настройках на сайте Web Merchant
Interface.
Это поле должно принимать значение 0, 1
или 2, что соответствует значениям
параметра "Метод вызова Fail URL" "GET", "POST" или "LINK".
Все поля формы, не имеющие в названии
префикса "LMI_", обрабатываются сервисом
Web Merchant Interface автоматически и
передаются на веб-сайт продавца после
выполнения платежа.
Список параметров формы предварительного запроса
Название
Индикатор
предварительного
запроса
Кошелек продавца
HTML Field Name
LMI_PREREQUEST
Описание
1
LMI_PAYEE_PURSE
Сумма платежа
LMI_PAYMENT_AMOUNT
Внутренний номер
покупки продавца
LMI_PAYMENT_NO
Флаг тестового режима
LMI_MODE
Кошелек продавца, на который
покупатель совершил платеж. Формат буква и 12 цифр.
Сумма, которую заплатил покупатель.
Дробная часть отделяется точкой.
В этом поле передается номер покупки в
соответствии с системой учета продавца,
полученный сервисом с веб-сайта
продавца.
Указывает, в каком режиме выполнялась
обработка запроса на платеж. Может
принимать два значения:
WMId покупателя
LMI_PAYER_WM
Параметры продавца
Определяется продавцом

0: Платеж выполнялся в
реальном режиме, средства
переведены с кошелька
покупателя на кошелек продавца;

1: Платеж выполнялся в тестовом
режиме, средства реально не
переводились.
WM-идентификатор покупателя,
совершившего платеж.
Все поля, переданные с веб-сайта
продавца в "Форме запроса платежа",
не имеющие префикса "LMI_".
Параметры, передаваемые серверу торговца при оповещении о платеже
Название
Кошелек продавца
HTML Field Name
LMI_PAYEE_PURSE
Описание
Кошелек продавца, на который покупатель
Сумма платежа
LMI_PAYMENT_AMOUNT
Внутренний номер
покупки продавца
LMI_PAYMENT_NO
Флаг тестового
режима
LMI_MODE
Внутренний номер LMI_SYS_INVS_NO
счета в системе
WebMoney Transfer
Внутренний номер LMI_SYS_TRANS_NO
платежа в системе
WebMoney Transfer
Кошелек
покупателя
WMId покупателя
LMI_PAYER_PURSE
Контрольная
подпись
LMI_HASH
Дата и время
выполнения
платежа
LMI_SYS_TRANS_DATE
Secret Key
LMI_SECRET_KEY
Параметры
продавца
Определяется продавцом
LMI_PAYER_WM
совершил платеж. Формат - буква и 12 цифр.
Сумма, которую заплатил покупатель.
Дробная часть отделяется точкой.
В этом поле передается номер покупки в
соответствии с системой учета продавца,
полученный сервисом с веб-сайта продавца.
Указывает, в каком режиме выполнялась
обработка запроса на платеж. Может
принимать два значения:

0: Платеж выполнялся в реальном
режиме, средства переведены с
кошелька покупателя на кошелек
продавца;

1: Платеж выполнялся в тестовом
режиме, средства реально не
переводились.
Номер счета в системе WebMoney Transfer,
выставленный покупателю от имени
продавца в процессе обработки запроса на
выполнение платежа сервисом Web Merchant
Interface. Является уникальным в системе
WebMoney Transfer.
Номер платежа в системе WebMoney
Transfer, выполненный в процессе обработки
запроса на выполнение платежа сервисом
Web Merchant Interface. Является
уникальным в системе WebMoney Transfer.
Кошелек, с которого покупатель совершил
платеж.
WM-идентификатор покупателя,
совершившего платеж.
Контрольная подпись оповещения о
выполнении платежа, которая используется
для проверки целостности полученной
информации и однозначной идентификации
отправителя.
Алгоритм формирования описан в разделе
"Контрольная подпись данных о платеже".
Дата и время реального прохождения
платежа в системе WebMoney Transfer в
формате
"YYYYMMDD HH:MM:SS".
Значение Secret Key, известное только
продавцу и сервису Web Merchant Interface.
Это поле будет пустым, если параметр
"Result URL" не обеспечивает секретности
или не установлен флаг "Высылать Secret
Key на Result URL...", или параметр "Result
URL" изменен в форме.
Все поля, переданные с веб-сайта продавца в
"Форме запроса платежа", не имеющие
префикса "LMI_".
Приложение 3. RUpay3
Поля, передаваемые формой запроса платежа шлюзу ИПС
Название
HTML Field
Name
Обязательный?
Описание
Номер сайта
продавца
pay_id
Да
Номер сайта продавца, на который покупатель
должен совершить платеж.
Сумма платежа
sum_pol
Да
Сумма платежа, которую продавец желает
получить от покупателя. Сумма должна быть
больше нуля, дробная часть отделяется точкой.
Внутренний номер
покупки продавца
order_id
Нет
В этом поле продавец задает номер покупки в
соответствии со своей системой учета.
Несмотря на то, что параметр не является
обязательным, мы рекомендуем всегда задавать
его. Желательно использовать уникальный
номер для каждого платежа, что позволит
быстро получить относящуюся к нему
информацию через систему RUpay.
Назначение
платежа
name_service
Нет
Описание товара или услуги. Формируется
продавцом.
Максимальная длина - 255 символов.
Дополнительные
параметры
продавца
Определяется
продавцом
Нет
Все поля формы, имеющие в названии
префикса "user_field_", обрабатываются
системой Rupay автоматически и передаются на
сайт продавца.
Поля, передаваемые ЦПС при предварительном запросе:
Название
Индикатор
предварительного
запроса
Номер сайта продавца
HTML Field Name
rupay_action
Описание
add
rupay_site_id
Внутренний номер
покупки продавца
rupay_order_id
Номер сайта продавца, на который покупатель
совершает платеж.
В этом поле передается номер покупки в
соответствии с системой учета продавца,
полученной системой с веб-сайта продавца.
3
Материалы взяты с сайта http://rupay.com
Назначение платежа
rupay_name_service
Номер счета в системе
RUpay
rupay_id
Сумма платежа
rupay_sum
Имя покупателя
rupay_user
Email покупателя
rupay_email
Дата и время
выполнения платежа
rupay_data
Контрольная подпись
rupay_hash
Параметры продавца
Определяется
продавцом
В этом поле передается назначение платежа в
соответствии с системой учета продавца,
полученной системой с веб-сайта продавца.
Номер счета в системе RUpay, выполненный в
процессе обработки запроса на выполнение
платежа системой RUpay. Является уникальным в
системе RUpay.
Сумма, которую необходимо заплатить
покупателю. Дробная часть отделяется точкой.
Имя покупателя, выписавшего счет в системе
RUpay
Email покупателя, выписавшего счет в системе
RUpay
Дата и время реального прохождения платежа в
системе RUpay в формате
"YYYY-MM-DD HH:MM:SS".
Контрольная подпись оповещения о выполнении
платежа, которая используется для проверки
целостности полученной информации и
однозначной идентификации отправителя.
Все поля, переданные с веб-сайта продавца в
"Форме запроса платежа", имеющие префикс "
user_field_".
Поля, передаваемые ЦПС при оповещении о платеже:
Название
Индикатор запроса
Номер сайта
продавца
Внутренний номер
покупки продавца
HTML Field
Name
rupay_action
rupay_site_id
rupay_order_id
Сумма платежа
rupay_sum
Номер счета в
системе RUpay
rupay_id
Дата и время
выполнения
платежа
Статус платежа
rupay_data
rupay_status
Описание
Update
Номер сайта продавца, на который покупатель совершил
платеж.
В этом поле передается номер покупки в соответствии с
системой учета продавца, полученной системой с вебсайта продавца.
Сумма, которую заплатил покупатель. Дробная часть
отделяется точкой.
Номер счета в системе RUpay, выполненный в процессе
обработки запроса на выполнение платежа системой
RUpay. Является уникальным в системе RUpay.
Дата и время реального прохождения платежа в системе
RUpay в формате
"YYYY-MM-DD HH:MM:SS".
Статус платежа может иметь следующие значения:
1 - В ожидании
2 - В обработке
3 - Платеж зачислен
4 - Платеж аннулирован
6 - Оплата не поступила
Значение Секретный ключ, известное только продавцу
и системе RUpay.
Это поле будет пустым, если параметр "URL





Секретный ключ
rupay_secret_key
Контрольная
подпись
rupay_hash
Оповещение о платеже" не обеспечивает секретности.
Контрольная подпись оповещения о выполнении
платежа, которая используется для проверки целостности
полученной информации и однозначной идентификации
отправителя.
Приложение 4. Краткая справка по протоколам, используемым ПС
Протокол SET
Протокол SET (Secure Electronic Transaction) разрабатывался в начале 90-х годов
специально для обеспечения максимальной надежности и защищенности онлайновых транзакций
и планировался как глобальный стандарт для онлайн-платежей. Помимо компаний Visa и
MasterCard, выступивших инициаторами, в разработке также участвовали такие гиганты, как IBM
и GlobeSet. Основной идеей было обеспечение секретности и целостности передаваемых данных, а
также взаимная аутентификация всех участников транзакции. Решение опиралось на
использование цифровых сертификатов по стандарту X.509. По уровню безопасности эта схема
надежнее даже, чем обычная покупка по КК в магазине (например, торговец не получает никаких
реквизитов КК), но требует участия довольно сложной многоуровневой системы
сертифицирующих организаций.
Транзакция по SET происходит примерно следующим образом:
 Стороны запрашивают и получают сертификаты в соответствующем
сертификационном центре.
 Кардхолдер выбирает на сайте онлайнового магазина желаемый товар и посылает
торговцу заказ.
 Торговец в ответ предъявляет покупателю свой цифровой сертификат.
 Владелец карты предъявляет свой сертификат.
 Торговец направляет запрос платежному шлюзу с целью осуществления проверки.
Шлюз сравнивает информацию о кредитной карточке клиента с информацией
банка-эмитента.
 После проведения проверки платежный шлюз возвращает результат онлайнмагазину.
 Если проверка прошла успешно, программное обеспечение интернет-магазина
формирует запрос на авторизацию и перевод денежных средств и пересылает этот
запрос платежному шлюзу, а тот перенаправляет запрос к банку-эмитенту.
В дальнейшем, убедившись что получение сертификата клиентом довольно-таки
хлопотное дело, схема была несколько переделана. Клиент устанавливал у себя специальное ПО,
обычно разрабатываемое банком-эмитентом и называющееся «цифровым кошельком», что
избавляло клиента от необходимости получать персональный сертификат. Это также дало
определенный прирост производительности, однако система все равно оставалась достаточно
медленной. Низкая производительность, сложность получения сертификатов (реально пройти
сертификацию, в силу трудоемкости процесса, могли только крупные банки) заставили банки,
процессинговые центры и интернет-магазины обратиться к SSL-протоколу. А вскоре и сама VISA
объявила о том, что SET-протокол уже не отвечает современным требованиям безопасности и
надежности. В 2000 году VISA начала разработку нового протокола 3D Secure.
3D Secure
«3D» в названии протокола означает «3 Domain». Трехдоменная модель подразумевает
разделение аутентификации по транзакции на три области: Issuer Domain (домен эмитента),
Acquirer Domain (домен эквайера) и Interoperability Domain (межоперационный домен). Домен
эмитента включает в себя банк эмитент и сервер контроля доступа ACS (Access Control Server),
который проверяет возможность и осуществляет аутентификацию кардхолдера по 3D Secure, а
также сам кардхолдер, который осуществляет транзакцию через веб-браузер (или
соответствующий софт мобильного телефона или любого другого устройства). В домен эквайера
входят торговец или интернет-магазин, плагин на сервере торговца, отвечающий за
аутентификацию платежа, а также банк-эквайер, который взаимодействует с авторизирующей
системой VisaNet и передает серверу торговца результаты авторизации. Межоперационный домен
обеспечивает обмен данными между доменами эквайера и эмитента, в частности обмен
информацией между банками осуществляется при помощи VisaNet.
Схема типовой транзакции по протоколу 3D Secure выглядит следующим образом:
 После ввода покупателем данных о КК в форму на сайте магазина на сервере
торговца инициализируется упомянутый выше плагин. Плагин обращается к
серверу платежной системы – Visa Directory (Межоперационный домен), где
происходит подтверждение того, что данная торговая точка может участвовать в
3D-Secure транзакциях.
 Если подтверждение получено, сервер Visa Directory определяет адрес ACS банкаэмитента, выпустившего кредитную карту клиента, и также устанавливает, лежит
ли данная кредитная карта в диапазоне карт, для которых использование 3D Secure
разрешено эмитентом. Затем Visa Directory посылает запрос к серверу контроля
доступа, чтобы определить, можно ли провести аутентификацию по 3-D Secure для
данной КК (кардхолдер должен заранее заявить банку о своем желании совершать
покупки при помощи 3-D Secure). Ответ ACS через Visa Directory передается к
плагину на сервере веб-магазина.
 При положительном ответе ACS плагин на сервере интернет-магазина формирует
запрос на аутентификацию кардхолдера и устанавливает защищенное соединение
(используется SSL) с ACS, перенаправляя туда браузер клиента. Получив этот
запрос, ACS аутентифицирует клиента.
 Если аутентификация прошла успешно, то ACS подготавливает ответ, который
подписывается цифровым ключом эмитента. Фактически это означает принятие
банком-эмитентом ответственности на себя, и в случае возможного отказа
владельца карты от результатов транзакции, отвечать будет именно банк-эмитент, а
не торговая точка, как это обычно происходит. Ответ ACS, полученный и
подтвержденный плагином на сервере интернет-магазина, передается серверу
банка-эквайера и Visa Directory, которая хранит информацию об аутентификациях
для возможности разрешения спорных вопросов в будущем. Дальше плагин
сервера мерчанта формирует запрос на авторизацию для отправки его в платежную
сеть.
Варианты и методы аутентификации кардхолдера банком-эмитентом ограничены
фактически только фантазией. Наиболее распространена система паролей, однако возможны также
варианты использования цифровых кошельков или даже внешних устройств типа чип-карт.
SPA/UCAF
Система UCAF использует 23-байтное зашифрованное поле, которое передается от
кордхолдера, через торговую точку и эквайера, эмитенту. Доступа к шифру ни торговец, ни
эквайер не имеют, а эмитент проводит по этому полю авторизацию. Это позволяет гарантировать,
что сделка осуществляется реальным кардхолдером, и гарантирует оплату торговцу. Для
идентификации и защиты эмитента UCAF позволяет использовать для идентификации и защиты
эмитента целый ряд приложений, включая SPA и смарт-карты.
SPA (Secure Payment Application) представляет собой схему обеспечения безопасности,
которая использует преимущества инфраструктуры UCAF (Universal Cardholder Authentication
Field). SPA гарантирует легитимность использования КК при оплате путем использования
клиентом цифрового кошелька, который генерирует при каждой транзакции уникальный 32-х
байтный код AAV (Accountholder Authentication Value), описывающий конкретную сделку и таким
образом связывающий кардхолдера со сделкой, происходящей с определенным торговцем на
определенную сумму.
Фактически SPA предоставляет торговцу некий эквивалент подписи кардхолдера,
подтверждая, что эмитент проверил его еще до завершения транзакции.