3D Secure — что это такое, для чего нужен и как работает

3D Secure – протокол авторизации при оплате товаров и услуг через интернет с помощью банковской карты. 3DS-авторизация включает подтверждение платежа с помощью кода безопасности. Она заменяет собой ввод PIN-кода для онлайн-платежей

При оплате в обычном магазине вы вставляете карту в терминал и вводите PIN-код. В интернет-магазинах достаточно ввести номер, срок действия, имя, указанное на карте, и CVC (трехзначный код на обратной стороне). Деньги моментально списываются со счета и поступают продавцу.

Такой способ авторизации несет в себе риски для владельца карты и продавца: мошеннику достаточно узнать реквизиты, чтобы украсть деньги. Исключить такие ситуации можно с помощью 3D Secure . Протокол использует большая часть интернет-сервисов и магазинов, где предполагается оплата картой.

3DS-авторизация (то есть авторизация по протоколу 3D Secure ) проходит в два этапа:

• На первом этапе вы вносите реквизиты (номер, срок действия, код CVC и имя), после чего вас перенаправляют на страницу платежной системы
• На втором этапе вы указываете код безопасности

Как правило, код безопасности отправляют в виде SMS или push-уведомления (если установлен мобильный банк и у него есть такая функция). Его никому нельзя сообщать, а срок действия ограничивается несколькими минутами. С помощью такого кода можно совершить одну транзакцию. Второй вариант — постоянный код безопасности, который клиент банка устанавливает самостоятельно или получает при выпуске карты. Его нужно запомнить.

Протокол 3D Secure используют непосредственно продавцы, его установка добровольна. Если в интернет-магазине не будет двухэтапной авторизации, банк все равно проведет транзакцию. Поэтому очень важно держать карту при себе, не высылать ее реквизиты или фото чужим людям и не размещать данные в открытом доступе. Единственное место, где вы можете указывать эти данные – на странице оплаты на сайте продавца.

Каждая платежная система имеет свои технологии обеспечения безопасности платежей, основанные на стандарте 3D Secure. У Визы это Verified by Visa, у МастерКарда — MasterCard SecureCode, у МИРа — MirAccept. Эти технологии построены по схожему принципу и отличаются только картами, с которыми они работают.

Виталина Слепухова

Одна из ведущих журналистов проекта. В кредитной сфере с 2008 года. Имеет высшее образование по специальности «Банковское дело». Публикуется в интернет-издании газеты Коммерсантъ. Большой опыт в финансовой сфере помогает ориентироваться на рынке микрофинансовых и банковских услуг и видеть самые важные события.

[email protected]

(13 оценок, среднее: 4.4 из 5)

что это такое, и как перейти на новый протокол без лишних затрат

Рассматриваем, как перейти на новый протокол 3‑D Secure 2.0, не затрачивая на это много ресурсов. А главное, как не потерять в конверсии и не навредить проходимости платежей во время переходного периода.

К концу 2021 года все банки ЕС будут применять новые правила безопасности для интернет-платежей внутри Еврозоны (и подлежат большим штрафам, если этого не сделают). Онлайн-бизнес, который не перейдет на протокол 3DS2, столкнется с серьезной потерей конверсии. Количество отказов по платежам без аутентификации 3DS2 уже сейчас быстро возрастает. Скоро все онлайн-платежи по картам, не прошедшим аутентификацию 3DS2, будут отклоняться эмитентами без рассмотрения.

Mastercard планирует вывести прежний протокол безопасности 3DS1 из эксплуатации в октябре 2022 года. VISA уже в октябре 2021.

Что такое 3DS2?

Техническая суть новшеств – в изменении некоторых программных кодов и автоматических параметров оповещений и запросов на платежный сервер и далее, для проверки и одобрения эмитенту.

Новый протокол формирует два пути прохождения платежей: frictionless flow и challenge flow. В первом случае система верифицирует знакомое устройство пользователя и одобряет платеж без подтверждения SMS-паролем. Во втором случае банковская система сомневается в аутентификации плательщика, и требует предоставить пароль или биометрическую информацию. Она перенаправляет пользователя на ACS-страницу банка-эмитента для ввода одноразового SMS-пароля.

Сервер Управления Доступом (ACS) ответственен за управление процессами аутентификации между покупателем и эмитентом, и гарантирует проведение платежных транзакций для торговца. Система сравнивает собранные данные с предыдущими (историческими) данными о транзакциях держателя карты для вывода значения риска мошенничества, соответствующего новой транзакции.

Что значит введение нового протокола 3DS2 для бизнеса?

Для онлайн-бизнеса и потребителей введение нового протокола 3DS2 на основе стандарта строгой аутентификации SCA означает гарантию безопасности, бесшовности и высокой конверсии платежей. Эмитентам карт для подтверждения каждой операции автоматически отправляется набор параметров о держателе карты и его устройстве, «цифровой отпечаток» плательщика. Если программа проверки «узнает» держателя карты, то обычной процедуры подтверждения платежа одноразовым SMS-паролем не потребуется. Большинство транзакций будет успешно совершаться в одну стадию.

Важно и то, что 3DS2-аутентификация (как и 3DS1) возлагает ответственность за возможный неправомерный платеж на эмитента и снимает ее с онлайн-бизнеса. Еще более значима для бизнеса и поддержка 3DS2 платежей в мобильных приложениях.

Как перейти на новый протокол 3DS 2.0: варианты — от сложного к простому

Для самостоятельного перехода на новую конфигурацию онлайн-бизнесу потребуется команда IT-специалистов и несколько недель работы (в зависимости от существующей схемы платежей на сайте).

Но есть способ лучше. Единичные платежные провайдеры научили свою платежную платформу проводить платежи с поддержкой 3-D Secure 2.0 самостоятельно. Со стороны бизнеса не требуется никаких доработок сайта, а платежная схема для онлайн-продавца и пользователя остается такой же, как и для 3‑D Secure 1.

Так, внутри ECOMMPAY этот сервис называется Proxy 3DS, а в документации значится как базовая схема аутентификации. Это своеобразный «переходник» между ядром нашей платформы (Core) и сервером управления доступом (Access Control Server или ACS).

Proxy 3DS – бесплатный сервис. Он уже работает для существующих клиентов ECOMMPAY и по умолчанию включается, если интеграция с сайтом идет через API (host2host). При подключении через платежную страницу вся обработка платежей, включая 3DS-аутентификацию, как и раньше, идет на стороне платежного провайдера.

Как работает 3DS 2.0 через Proxy 3DS на практике: разные сценарии

Если банк-эмитент держателя карты поддерживает протокол 3-D Secure 2.0, то платежная платформа в ответ на запрос формирует оповещение в привычном формате 3‑D Secure 1, но в качестве URL-адреса вместо ACS будет указан адрес нашего сервиса Proxy 3DS.

При перенаправлении пользователя на Proxy 3DS возможны два сценария:

• frictionless flow — отображение скрытого для пользователя окна (iframe) и обмен данными с ACS в фоновом режиме. Другими словами, Frictionless Flow позволяет эмитентам одобрить транзакцию, не требуя ручного ввода данных от владельца карты.

• challenge flow — перенаправление пользователя на ACS-страницу банка-эмитента для ввода подтверждающей информации (например, одноразового пароля).

Выполняться может как один из этих сценариев, так и два сценария последовательно. Выбор за эмитентом.

Как перейти на 3-D Secure 2 в одно действие?

Proxy 3DS работает по базовой схеме аутентификации. Сервис поддерживает протокол 3-D Secure 2 на основе предыдущей версии без доработок, но требует дополнительных перенаправлений пользователя.

Расширенная схема оптимизирована под особенности протокола 3-D Secure 2.0 и исключает промежуточные перенаправления. Однако, она предполагает, что торговый сайт уже умеет работать со схемами frictionless и challenge flow.

Для максимально легкого перехода на расширенный вариант сервиса наша команда реализовала обратную совместимость между схемами аутентификации. От системного администратора сайта требуется самостоятельно изменить только один параметр в одном из запросов. Подробности – в нашей документации.

Переход платежных систем и банков по всему миру на новый протокол 3DS2 – вопрос самого ближайшего будущего. Но в условиях, когда не все банки-эмитенты даже в ЕС осуществили этот переход, любой онлайн-бизнес может столкнуться с неожиданным снижением конверсии или частым отказами по транзакциям какого-либо эмитента. Proxy 3DS – оптимальный инструмент для переходного периода в европейской системе безопасности онлайн-платежей.

Клиенты ECOMMPAY, которые интегрируют платежный шлюз через API, работают с 3-D Secure 2 через Proxy 3DS. Это избавляет их от многочисленных доработок для поддержки новой версии протокола.

Чтобы узнать, как упростить переход на новый протокол, свяжитесь с нашими экспертами!

Почему карта не проходит 3DS аутентификацию

Часто при покупках онлайн жизнь покупателю омрачают разные технические заморочки. Одна из частых ситуаций – сбои в обработке платежей с пластиковых карт, в частности статус “Ваша карта не прошла 3DS-аутентификацию, либо отклонена платежной системой”. Обычно это уведомления выглядит так, хотя у некоторых банков могут быть свои обозначения, как у ВТБ: threedsservertransid.
Например, такая ошибка частенько выскакивает при оплате на Авито.

Рассмотрим возможные причины такого отказа.

3Ds аутентификация – то же самое, что и 3-D Secure

Во-первых, определимся с терминологией. 3Ds аутентификация (она же 3D-secure) это по сути двухфакторная авторизация, двойное действие при подтверждении платежа.

От обычной оплаты в “один клик” 3д-секуре отличает то, что в этапах оплаты появляется еще один шаг – ввод кода на специальной странице вашего банка, который выпустил карту.

3D Secure – это когда при оплате в интернете Вам приходит SMS от Вашего банка, и Вы вводите полученный код в специальном окне.

Код может быть как постоянным, придуманным вами на этапе включения опции 3D-secure в личном кабинете или интернет-банкинге, так и одноразовым, который приходит в СМС или берется из карты кодов банка (всё это зависит от конкретной банковской сети, у разных брендов свои правила на этот счёт).

Данная опция включается при заключении договора обслуживания в банке или самостоятельно клиентом через интернет-банк. Вот как это выглядит в моём кабинете (но у каждого банка структура настроек отличается, и у вас всё может быть по-другому).

Карта Восточный Банк

• Онлайн-заявка
• Доставка курьером
• Современная бакновская карта

Карта Восточный Банк

Карта Тинькофф Банк

• Доставка курьером
• Онлайн оформление
• Без проблем с 3ds авторизацией

Карта Тинькофф Банк

Карта Банк Открытие

• Кэшбэк на покупки и топливо
• Бесплатная доставка
• Без проблем с 3-ds авторизацией

Карта Банка ОткрытиеВключение 3-D- secure

Самых частых причин, по которым карта не проходит и появляется статус “карта не прошла 3D-аутентификацию, либо отклонена платежной системой”, всего три:

1.  Банальная – на карте недостаточно средств
2. Тоже распространенная – для вашей карты не активирована услуга “3ds-авторизация”
3. И третья причина – неправильной пароль для этапа 3ds-authentication
   Дело в том, что пароль для расчетов онлайн человек обычно активирует сразу при оформлении карты, но используется редко. А вот другие пароли используются или часто, или даже ежедневно – вход в интернет-банк и т.д.

Поэтому в момент оплаты пользователь видит незнакомое (не часто используемое для 3ds-secure) окно для ввода пароля, но по привычке или не имея под рукой нужного пароля – еще раз вводит пароль для интернет-банка.
Пароль неверный, не для этого этапа, и происходит отказ в обслуживании пластиковой карты.Решения данной проблемы, исходя из вышеизложенных причин, тоже очевидны:

• зайдите в интернет-банкинг, проверьте наличие средств на карте и заодно убедитесь, что опция 3Д-секьюре включена
• держите пароль для 3ds-авторизации под рукой перед оплатой, и не путайте его с другими паролями (доступа в личный кабинет банка, и т.д.)

Если же решение не найдено – стоит копнуть глубже: проверить лимиты карты на выполнение суточных операций по сумме, на полный запрет интернет-транзакций или платежей в иностранных магазинах.

3D Secure 2.0 для безопасных интернет-покупок » Мнения экспертов

Сергей Парфёнов, технический директор ООО «Фаззи Лоджик Лабс», о необходимости перехода на 3D Secure 2.0 и новых возможностях протокола.

3DSecure. Исторический экскурс

Протокол 3D Secure появился 20 лет назад на фоне бурного роста интернета и электронной коммерции, когда все участники рынка (торгово-сервисные предприятия, платежные системы, банки и потребители) оказались остро заинтересованы в росте возможностей интернет-торговли. 3D Secure был призван снизить риск мошенничества при онлайн-платежах платежными картами, которые появились еще в «доинтернетную» эпоху и не предоставляли почти никаких средств для защиты при интернет-платежах.

Первой на рынок вышла компания Visa со своим брендом Verified by Visa. Услуги на базе стандарта 3D Secure были вскоре предложены и другими крупнейшими платежными системами: Mastercard SecureCode, Discover ProtectBuy, J/Secure, American Express SafeKey.

В настоящее время стандарт поддерживается и развивается консорциумом EMVCo как EMV 3D Secure.

3DSecure 1.0 vs 2.0

Очевидно, что с момента появления идет постоянное развитие протокола 3D Secure. Так, например, в версии 1.0 протокола 3D Secure в процесс покупки был добавлен один шаг: перенаправление на веб-сайт эмитента для аутентификации владельца карты с помощью статических или одноразовых паролей. Плюсы такого решения:

• для владельца карты – защита от мошенничества путем хищения реквизитов карты;
• для ТСП – перенос ответственности за мошеннический платеж (Liability Shift) на эмитента.

Все это должно было повысить привлекательность электронной коммерции, но на практике из-за ряда недостатков протокола ожидаемого роста рынка не произошло, а в некоторых странах в момент включения 3D Secure 1.0 объем операций даже упал.

Основная причина – дополнительная сложность для пользователя: лишнее перенаправление в браузере (которое часто могло завершаться просто ошибкой загрузки страницы), необходимость помнить одноразовый пароль (большая часть банков-эмитентов использовала именно такой способ аутентификации). Многим пользователям, столкнувшись с такими трудностями, проще было не завершать текущую покупку, а либо использовать карту другого эмитента, либо покупать у другого продавца.

К другим недостаткам 1.0 можно отнести следующие моменты:

• поддержка только браузерного интерфейса. Особенно это ухудшает удобство пользователя в мобильных приложениях;
• стиль страницы, на которую перенаправляется пользователь, полностью отличается от сайта продавца, что вызывает у пользователя вполне законное подозрение в фишинге;
• аутентификация на основе оценки риска практически невозможна из-за недостаточного количества данных, пересылаемых мерчантом.

3D Secure 2.0 призван устранить болевые точки версии 1.0 и значительно повысить как привлекательность технологии в целом для участников рынка, так и

качество оценки легитимности транзакции и необходимости ее аутентификации.

С учетом этих задач в 3D Secure 2.0 сделаны следующие изменения:

• добавлена поддержка различных устройств и каналов. Новые мобильные SDK позволяют проводить аутентификацию непосредственно в мобильном приложении, без необходимости перенаправления на сайт эмитента;
• вместо статических паролей используются более удобные методы аутентификации, такие как биометрия и токены;
• значительно увеличено количество передаваемых для аутентификации данных, что позволяет качественно проводить Risk-Based-Authentication (RBA).

Рис. 1. Сравнение протоколов 3DS 2.0 c 3DS 1.0

3DS 2.0 становится необходим и в связи с новыми законодательными требованиями в европейских (и некоторых АТР-странах) странах (даже при наличии контрагента вне данной страны) на дополнительную аутентификацию.

Главное нововведение 3D Secure 2.0 – Frictionless Flow, возможность проводить транзакцию без дополнительных действий по аутентификации со стороны пользователя. Если по итогам RBA транзакция признана низкорисковой, то эмитент разрешает продавцу проводить транзакцию без дополнительных запросов пользователю.

• По оценке Visa, 95% транзакций можно проводить без дополнительной верификации покупателя.
• Для клиентов это значительно повышает удобство. Большую часть регулярных платежей можно будет проводить без необходимости подтверждения по одноразовому паролю.
• Банки смогут значительно сэкономить на SMS-оповещениях.

Оценка риска 3DS 2.0 транзакции на стороне эмитента

При оценке риска транзакции на стороне эмитента важно не ошибиться и не пропустить мошенническую транзакцию без дополнительной аутентификации, т. к. в этом случае вся ответственность за возврат средств ложится на эмитента. Важно использовать как можно больше информации о транзакции, ее контексте, профиле клиента, продавца и т. п. В том числе – из других каналов обслуживания.

Рис. 2. Эволюция протокола 3DS

До появления 3DS 2.0 оценка риска многих карточных транзакций была недостаточно качественной, в частности, при CNP-транзакциях (card not present) зачастую просто не хватало информации, чтобы оценить все аспекты риска. Чаще всего были доступны лишь финансовые аспекты транзакции.

Для нашей компании «Фаззи Лоджик Лабс», которая развивает кросс-канальную систему выявления и предотвращения мошеннических транзакций в режиме реального времени Smart Fraud Detection, доступность данных 3DS 2.0 позволяет предоставлять кредитным организациям более эффективную оценку интернет-покупок (Risk-Based Authentication).

С использованием данных операции, полученных благодаря 3DS 2.0, появляется возможность использовать в оценке риска и анализе транзакций:

• типичные параметры для операций в интернет-банке и мобильном приложении о клиентских устройствах и их местоположении, скорости перемещения устройств,
• важные для профилирования операций в электронной коммерции данные, которые раньше было затруднительно получить, например, данные о платеже.

Построение сквозного кросс-канального профиля клиентских устройств и платежных операций пользователя при выполнении интернет-покупок и при работе в системах ДБО банка позволяет существенно повысить качество оценки риска.

Появляются следующие возможности:

• в режиме реального времени строить более точные профили объектов, вовлеченных в операции различных каналов, а также связей между различными объектами: клиентами, мерчантами, IP-адресами, реквизитами и геолокацией клиентских устройств, получателями платежа.
• определять кросс-канальные регулярные платежи, типовые характеристики используемых устройств, скорость перемещения – по их IP;
• сверять транзакцию с реквизитами и устройствами известных мошеннических операций, проведенных в других банковских каналах;
• ранжировать операции от наименее рискованных до наиболее рискованных путем присвоения оценки риска каждому событию, позволяя операторам системы форсировать дополнительную аутентификацию операций – как на основе риска, так и на основе дополнительных условий на параметры операций.

Верификация интернет-покупки

Процедура проведения платежной транзакции с использованием протокола 3DS 2.0 представлена на рис. 3.

Рис. 3. Процедура проведения платежной транзакции с использованием протокола 3DS 2.0

Протокол 3D Secure 2.0 позволяет не только оценить риск, но помочь в выборе механизма более всего подходящей дополнительной аутентификации, исключив по возможности каналы, которые могут оказаться скомпрометированы.

При этом задачами антифрод-решения Smart Fraud Detection являются:

• оценка риска операции, позволяющая снизить количество интернет-операций, требующих верификации, и не пропустить потенциально мошенническое действие;
• ранжирование риска для операций для каждого возможного способа аутентификации с учетом «доверия» к способу верификации и его «стоимости» для эмитента.

Таким образом:

• операция может быть продолжена с наименее рискованным методом верификации или без него;
• для клиентов повышается удобство в выполнении регулярных платежей без необходимости подтверждения их одноразовым паролем или другим средством аутентификации;
• банки смогут значительно сэкономить на SMS-рассылках.

Резюме

Переход на 3DS 2.0 объективно необходим на фоне принципиального изменения ландшафта платежей, включая повсеместное использование мобильных устройств, непредсказуемые изменения поведения пользователей (например, из-за пандемии), гораздо более высокие требования к удобству использования, стабильности и быстродействию платежных инструментов, а также недопустимость усложнения процесса покупок (friction) из-за чрезвычайно высокой конкуренции в сегменте интернет-продаж.

3-D Secure (3DS): как работает механизм и почему его использование является важным при приеме платежей через вебсайт?

Сегодняшнюю серию блога о приеме платежей через вебсайт команда Finance Business Service хочет посвятить одному из важных аспектов процесса безопасного эквайринга платежных карт – 3-D Secure. Мы глубоко убеждены, что каждый из нас, кто хотя бы раз в своей жизни совершал оплату товаров и услуг в сети Интернет, уже заочно знаком с этим механизмом. Тем не менее, для лучшего понимая схемы его работы и необходимости практического использования, вашему вниманию предлагается следующий материал. Он будет полезен не только для держателей банковских карт (покупателей), но и для владельцев онлайн-бизнеса.

Что такое 3-D Secure?

3-D Secure (Three-Domain Secure) – это протокол защиты, используемый для авторизации платёжного средства (банковской карты) при совершении CNP-оплаты (Card Not Present Payment) за товары и услуги. Впервые данный механизм был задействован оператором платёжных карт Visa, вследствие чего появилась система безопасности Verified by Visa. Чуть позже этому примеру последовал оператор MasterCard и внедрил свой собственный протокол MasterCard Secure Code. Для того, чтобы понять, гарантирует ли тот или иной вебсайт дополнительный уровень защиты интернет-платежей, необходимо обратить внимание на наличие специальных логотипов операторов Visa и MasterCard на его страницах.

Поскольку технология 3-D Secure является технологией повышенной безопасности, она создает ещё одну ступень аутентификации пользователей для подтверждения онлайн-платежей, осуществляемых при помощи платёжных карт. В свою очередь, это позволяет бизнесу (к примеру, интернет-магазину) и его банку-эквайеру убедиться в том, что операции действительно проводятся держателями карт, а не мошенниками.

Схема работы 3-D Secure

Для того, чтобы понять, как работает 3-D Secure, нужно вспомнить алгоритм действий обычного покупателя, например, при оплате онлайн-заказа на вебсайте.

• В большинстве случаев покупатель формирует свой заказ в «Корзине» и выбирает способ оплаты «Банковской картой Visa или MasterCard», после чего система переправляет его на форму для внесения реквизитов платёжной карты.
• В этой форме обычно требуется внесение следующих данных: номер банковской карты, срок её действия, CVV2/СVC2-код и имя держателя.
• После заполнения платёжных реквизитов, подключается протокол безопасности 3-D Secure, при помощи которого покупателю отправляется SMS-оповещение с уникальным паролем для подтверждения операции. Этот пароль всегда одноразовый и действует достаточно короткий промежуток времени (от 30 секунд до 5 минут). Особенность подобного SMS-оповещения заключается в том, что покупатель получает уведомление на свой мобильный телефон, который привязан к банковской карте, или же в приложении мобильного банкинга, для входа в который также требуется аутентификация паролем, отпечатком пальца (Touch ID) или фейс-сканером (Face ID).
• Корректное и своевременное введение пароля из SMS-оповещения в форме оплаты на вебсайте разрешает банку безопасное списание денежных средств со счёта покупателя.

Стоит отметить, что 3-D Secure авторизация проходит по трём доменам:

• домену банка-эквайера, который обслуживает интернет-магазин;
• домену банка-эмитента, который выпустил платёжную карту покупателя;
• домену платёжной системы.

Отсюда, собственно говоря, и возникло название Three-Domain Secure. Вся передаваемая информация по платежу сохраняется на домене банка-эмитента, а интернет-магазин не имеет к ней никакого доступа. Но интернет-магазин может хранить часть информации по реквизитам банковской карты, если покупатель даёт своё согласие. Обычно это происходит после нажатия кнопки «Запомнить карту» на вебсайте для ускоренного проведения транзакций в дальнейшем.

Необходимость практического использования 3-D Secure

Несмотря на очевидное преимущество 3-D Secure, не все интернет-торговцы и банки поддерживают данную технологию, так как она не является обязательной. Результаты исследований, проводимых в США, показывают, что ввиду применения 3-D Secure аутентификации, количество «брошенных корзин» в онлайн-магазинах существенно возрастает. Это останавливает мошенников на пути осуществления fraud-платежей. Тем не менее очень часто покупатели критикуют рассматриваемый механизм безопасности из-за неудобства и необходимости заполнения дополнительной формы с кодом авторизации.

По нашему мнению, в использовании 3-D Secure видится реальная практическая необходимость, поскольку пароль из SMS-оповещения является своеобразной гарантией надлежащего владения банковской картой. Кроме этого, поддержка стандарта 3-D Secure продавцом (онлайн-магазином) нивелирует его ответственность в случае попытки проведения несанкционированного платежа. Таким образом бизнес перекладывает бремя ответственности на банк-эмитент, который выпустил ту или иную платёжную карту.

Тем не менее механизм 3-D Secure постепенно устаревает. Недобросовестные покупатели (мошенники) приспособились перехватывать SMS-оповещения банков, тем самым получая доступ к чужим кодам аутентификации. В свою очередь, это наталкивает на мысль о том, что существующие протоколы безопасности требуют модернизации.

Ошибка при проведении 3DS-аутентификации: что это такое

Ошибка при проведении 3DS-аутентификации – проблема, встречающаяся в момент оплаты товаров и услуг в сети. Для ее решения необходимо знать нюансы подтверждения данных.

Особенности аутентификации

3DS-аутентификация – уникальная система защиты данных банковских карт от совершения финансовых операций без согласия держателя.

Для оплаты покупок в интернет-магазинах нужно указывать следующую информацию:

• номер и срок действия карты, указанный на лицевой стороне;
• код с оборотной стороны карты – CVV (CVC).

Если для карты подключена дополнительная защита 3DS-Secure, то пользователю при оплате онлайн следует пройти еще одну процедуру, направленную на противодействие потенциальным мошенникам. Одноразовые пароли поступают в виде смс-сообщения на номер держателя карты. Ввод данных осуществляется на официальной странице одного из банков: ПАО “Сбербанк России”, “ВТБ”, ” Альфа-Банк” и другие.

После прохождения 3DS-аутентификации происходит оплата с учетом последующей переадресации покупателя на сайт продавца. Транзакция не может быть осуществлена без данной операции, ни при каких обстоятельствах.

Плюсы и минусы технологии

Метод защиты 3DS-аутентификации имеет очевидные преимущества и недостатки. В целях самостоятельной оценки работоспособности технологии следует ознакомиться с возможными рисками.

Плюсы	Описание
Безопасность транзакций	Клиенты всех финансовых организаций заинтересованы в индивидуальном сохранении доступа к денежным средствам. В подавляющем большинстве случаев пароли действуют исключительно для единичных операций.
Удобство покупок	Применение одноразовых кодов автоматически освобождает покупателей от необходимости повторного ввода платежных данных.
Простота пользования	Технология доступна для всех категорий лиц, даже для тех, кто проводит электронные транзакции в первый раз.
Массовость	Большинство точек интернет-магазинов поддерживают подключение к 3D-Secure. Продавцы используют технологию в целях защиты клиентской информации и собственной репутации.

 

Среди наиболее весомых недостатков 3DS-аутентификации пользователи выделяют:

• невозможность проверки чистоты операций – многие пользователи сходятся во мнении, что технология позволяет обеспечить должную защиту только для магазинов, а не для клиентов.
• длительность переводов – на практике покупатели заинтересованы в снижении времени оплаты товаров и услуг в интернете. В 3D-Secure затрачивается больше времени на каждую транзакцию, чем в незащищенных вариантах;
• электронные платежи считаются более опасными для магазинов, чем офлайн-способы. Многие продавцы используют 3DS-аутентификацию исключительно для перенаправления ответственности на банки-эмитенты в случае участия мошенников.
• процесс покупки прекращается из-за длительности обработки данных. Товары остаются в виртуальных корзинах и больше не используются, что ограничивает возможность получения прибыли и подсчета активности потенциальных потребителей. По статистике более 50% покупателей бросают заполнение анкет именно в связи с применением защищенных протоколов.

Основные причины блокировки транзакции

В ряде случаев при попытке онлайн-оплаты на экране используемого устройства высвечивается сообщение: “Authentication failed: неверный CVV код”. Существует несколько причин появления такого уведомления:

1. Функция не была подключена при первоначальном взаимодействии с банком.
2. Истекло время платежного кода.
3. Задержка на серверах по банковской линии.
4. Эмитент отклонил аутентификацию – случается, если обслуживающая организация считает, что карта была украдена у пользователя.
5. Сбой во внутреннем функционале интернет-магазина.
6. Не пройдена авторизация в системе.
7. Недостаточность денежных средств на платежном счету.

При неудачной 3DS-аутентификации на экран выводится один из доступных кодов ошибки.

Код	Описание
05	Отказ без указания причины
17	Отклонение операции держателем карты
19	Техническая ошибка со стороны обслуживающего банка
51	Недостаточно средств
61	Превышение доступного лимита за одну операцию
62	Невозможность транзакции по причине блокировки карты
65	Превышение доступного количества операций
75	Превышение максимального количества неверно введенных паролей
91	Невозможность отправления запроса на обработку платежа по техническим причинам
95	Сбой связи с банком
Z3	Отсутствие онлайн-соединения. Отключение терминалом возможности приема средств в режиме офлайн.

 

3DS-аутентификация уязвима для вирусных атак. Если телефон, на который поступают сообщения с паролем, работает на операционной системе Android, то пользователям рекомендуется установить антивирусное приложение. Ряд вирусов направлены на инициирование карточных операций и кражу данных.

Специалисты не рекомендуют сохранять реквизиты карт в настольных браузерах. Мошенники могут получить информацию и им не будут нужны одноразовые коды, чтобы воспользоваться чужими деньгами.

Порядок исправления проблемы некорректной аутентификации

Если на экране при оплате появилась надпись “Ваш платеж был отклонен”, то поводов для паники нет. Защитные алгоритмы системы постоянно развиваются и процент несанкционированного доступа злоумышленников к данным предельно низкий.

Оперативное исправление проблемы возможно путем звонка на горячую линию обслуживающего банка.

Представители центра обслуживания проверят настройки карты и дадут первичную консультацию по поводу причин возникшей проблемы. Если это произошло по вине банка или платежной системы, решение займет не более 10 минут.

Минимизация рисков мошенничества

Для снижения рисков необходимо следовать общепринятому алгоритму действий описанных в таблице.

Действие	Описание
Оформление отдельной карты	Для электронных платежей не рекомендуется использовать зарплатные карты, на которые поступает основная часть дохода держателя. Оптимальным вариантом считаются виртуальные карты с предустановленной функцией возврата части суммы покупки.
Проверка адреса сайта продавца	Сайт платежной страницы должен в обязательном порядке начинаться с https.
Снятие части денег с карты через банкоматы перед транзакцией	Покупателям не следует держать все имеющиеся средства на карте. Идеальный вариант – сохранение суммы, равной цене покупки. 10% от общей стоимости закладывается на возможную комиссию.
Совершение покупок только в проверенных магазинах	Перед покупкой важно ознакомиться с отзывами о продавце на страницах популярных агрегаторов.

 

Заключение

Дополнительная мера защиты 3DS-аутентификация дает возможность обеспечения безопасности платежей, совершаемых в режиме онлайн. Снять деньги с карты без согласия владельца практически невозможно. Протокол защиты не обеспечивает 100% гарантию безопасности.

Платежные карты – NBG

Общие сведения

Дебетовые карты международного образца, по которым представителям компаний и их предприятиям предоставляется широкий спектр услуг.

Технология бесконтактных электронных платежей, используемая Mastercard Business Debit, предоставляет Вам возможность ежедневно совершать деловые операции на сумму до 3000 евро и мгновенно, легко и безопасно управлять своими деловыми расходами. Через Вашу карту Вы получаете прямой доступ к средствам на своем счету в миллионах точек по всему миру, отмеченных эмблемой Mastercard и знаком .

​ Осуществление бесконтактных операций в несколько простых и абсолютно безопасных шагов.

Используемая Mastercard Business Debit технология бесконтактных электронных платежей делает более удобным и быстрым процесс покупок в торговых точках, оборудованных специальными терминалами и отмеченных соответствующим знаком.

Как пользоваться?

• • Несколько секунд удерживайте карту у терминала оплаты.
  • Для проведения операций на сумму, не превышающую 50 евро, подтверждение PIN-кодом не требуется (*),
  • Для проведения операции на сумму более 50 евро, при необходимости, введите PIN-код Вашей карты.
  • Завершение операции сопровождается звуковым сигналом.

Кроме того, карта открывает своим держателям доступ к миллионам компаний, работающих с MasterCard, позволяет совершать покупки онлайн и оформлять заказы.

Вместе с этим карта служит и для проведения банковских операций, например, снятия наличных через банкомат.

УСЛОВИЯ

• • Для прочтения Условий использования карт нажмите здесь.
• НАЛОГИ – СБОРЫ
  • Для ознакомления с таблицей сборов по карте нажмите здесь
• Примечание
• (*) В интересах безопасности, запрос PIN-кода может производиться и для операций на сумму, равную или меньшую 50 евро.

Аутентификация неплатежей с 3D Secure 2

Усовершенствованный протокол 3D Secure, 3DS 2.0, окажет большое влияние на платежную индустрию, в том числе возможность расширить сеть для предотвращения мошенничества.

Теперь существует больше каналов, где протокол может быть реализован для безопасных транзакций, включая платформы, не основанные на браузере, и мобильную интеграцию.

Неплатежная аутентификация — это один из аспектов, который будет представлен в 3DS 2.0, который позволяет использовать протокол не только в традиционных платежах на основе браузера.

Что мы подразумеваем под

с неплатежной аутентификацией
?

Чтобы понять эту концепцию, стоит взглянуть на основы работы исходного протокола 3DS.

3DS версии 1 просит держателей карт (лицо, производящее онлайн-платеж) подтвердить свою личность банку-эмитенту, прежде чем транзакция может быть завершена. Это происходит через всплывающее окно или встроенный фрейм на этапе фактического оформления платежа.

Таким образом, процесс аутентификации всегда происходил во время фактического платежа.Это привело к двум проблемам.

Во-первых, пользователи не всегда могут определить подлинность всплывающего окна, что часто вызывает подозрения и приводит к отказу от транзакции. Во-вторых, поскольку протокол 3DS был представлен за несколько лет до того, как стали доступны мобильные платежи, при проверке подлинности в мобильных браузерах возникли проблемы совместимости.

Хотя 3D Secure 2.0 решает проблемы совместимости и теперь обеспечивает более удобную работу с мобильными устройствами, в некоторых случаях он также позволяет продавцам отделить процесс аутентификации от фактического платежа.

Это напрямую влияет на уход пользователей и качество обслуживания клиентов.

Почему?

Поскольку мошенники придумывают более изощренные способы получения несанкционированного доступа к данным дебетовых и кредитных карт, мы все слишком осознаем потенциальные опасности совершения онлайн-платежей.

Это может сделать процесс онлайн-кассы стрессовой ситуацией. Вот почему люди так легко уходят, когда сталкиваются с «неизвестным» всплывающим окном с просьбой ввести часть своей личной информации.

Путем переноса проверки 3D Secure с фактического платежа в менее напряженную среду, то есть неплатежную аутентификацию, можно уменьшить подозрения покупателей и, следовательно, отказ от транзакции.

Неплатежная аутентификация

в мобильных приложениях

Мы видели, какое влияние 3DS 2.0 окажет на индустрию мобильных платежей, включая внедрение мобильных SDK, которые помогут продавцам легко интегрировать новый протокол с уже существующими мобильными устройствами. Приложения.

Это также улучшит процесс проверки в целом и обеспечит неплатежную аутентификацию.

Одно из таких приложений — через мобильные кошельки.

По мере роста популярности мобильных платежей в последние годы росло и использование мобильных кошельков (или электронных кошельков). Это удобная платформа для безопасного хранения денег и быстрой обработки онлайн-платежей.

Согласно исследованию, проведенному Mastercard, в 75% всех отслеживаемых разговоров в социальных сетях цифровые кошельки упоминались в той или иной форме.Другое исследование, проведенное Points, показало, что почти 100% потребителей будут чаще использовать мобильный кошелек, если он предлагает какое-то вознаграждение за лояльность.

Большим плюсом мобильных кошельков является возможность для пользователей хранить данные своих кредитных или дебетовых карт в приложении. Таким образом, транзакции могут быть выполнены через платформу без необходимости вводить данные своей карты каждый раз при совершении платежа.

Здесь вступают в игру дополнительные функциональные возможности 3DS 2.0.Это позволяет проводить процесс аутентификации в мобильном приложении продавца, обеспечивая дополнительный уровень безопасности в момент, когда пользователь вводит данные своей карты на платформе для последующего использования.

Это означает, что процесс аутентификации переместился из платежной среды в одобренную эмитентом среду без платежей.

Процесс аутентификации также будет выглядеть согласованным с остальной частью работы в приложении, что менее тревожно для пользователей.

Поставщики мобильных кошельков могут проверить подлинность пользователя, заимствуя информацию у банка-эмитента через простое подключение к серверу каталогов , используя сервер 3DS в сочетании с Mobile SDK от утвержденных поставщиков.

Неплатежная аутентификация

и PSD2

При разработке PSD2 (второй Директивы Европейского Союза о платежных услугах) некоторые функции нового 3D Secure 2 частично совпадают.0, особенно когда речь идет о SCA (строгой аутентификации клиентов), включая TFA (двухфакторную аутентификацию) и OTP (одноразовые пароли).

В новых правилах PSD2 говорится, что SCA потребуется для электронных платежей на определенную сумму (около 10 евро). Они определяют SCA как «использование двух или более элементов, классифицируемых как знание (что-то, что знает только пользователь), владение (что-то, чем владеет только пользователь) и наследование (что-то, что пользователь), которые являются независимыми, в том смысле, что нарушение одного из них делает не ставить под угрозу надежность других.

Это в основном то, что представляет собой MFA (многофакторная аутентификация), включая одноразовые пароли, биометрическую аутентификацию, такую ​​как отпечатки пальцев или распознавание лиц, и QR-коды, которые могут сканироваться мобильными приложениями.

Когда будет введена в действие новая Директива о платежах, банки и другие финансовые учреждения должны будут соблюдать правила SCA.

Хорошая новость для продавцов и эмитентов заключается в том, что этот процесс неплатежной аутентификации уже требуется в 3DS 2.0 и, следовательно, полностью соответствует принципам, установленным в PSD2.

Если протокол 3DS 2.0 уже принят на платформе продавца, он позволит легко обеспечить соответствие PDS2 с небольшой или нулевой настройкой, что позволит всем вовлеченным сторонам легко продолжать борьбу с мошенничеством.

Те же серверы ACS, которые банки используют в своих элементах управления SCA, можно использовать в онлайн-платежах, требующих аутентификации 3D Secure. Для банков может даже иметь смысл перейти на сервер 3D Secure 2.0 ACS.

Заключение

Джонатан Мэйн, председатель совета управляющих EMVCo, сказал: «Помимо безопасности, потребительский опыт играет центральную роль в работе EMVCo».

Предоставление опции аутентификации без оплаты, одобренной эмитентом, 3DS 2.0 приближает продавцов и эмитентов еще на один шаг к обеспечению беспрепятственного обслуживания клиентов.

Кроме того, он позволяет продавцам обеспечивать дополнительный уровень безопасности для онлайн-платежей через более широкий спектр каналов, кроме транзакций на основе браузера.

И, наконец, неплатежная аутентификация в 3DS 2.0 не просто помогает продавцам легко соблюдать правила оплаты, как PSD2, но фактически работает вместе с регулирующими органами, чтобы создать еще более безопасную онлайн-среду для клиентов.

Visa Secure с использованием EMV 3DS User Experience Guidelines

Вступление

keyboard_arrow_down

Последнее обновление 17 мая 2021 г.

Введение

Добро пожаловать в руководство по продукту UX для Visa Secure с использованием потоков EMV 3DS в веб-браузерах и мобильных приложениях.Независимо от того, являетесь ли вы дизайнером, разработчиком, менеджером по продукту или ответственным за принятие бизнес-решений, эти рекомендации помогут вам создать наилучшие условия для ваших клиентов.

Visa Secure (ранее известная как Verified by Visa) — это программа Visa, которая управляет транзакциями Visa с использованием стандарта 3-D Secure. Программа предоставляет правила и политику, которым должны следовать продавцы и эмитенты, чтобы активировать аутентификацию для транзакций электронной коммерции, что позволяет проверять личность держателя карты до того, как транзакция будет отправлена ​​на авторизацию.

В зависимости от решения аутентификации, которое выбирает эмитент, эмитент может использовать множество методов аутентификации. Visa рекомендует эмитентам использовать аутентификацию на основе рисков в качестве подхода к аутентификации, когда это уместно, признавая, что в некоторых случаях нормативные требования могут содержать особые «повышающие» или оспаривающие требования аутентификации. Пожалуйста, обратитесь к нормативным требованиям для конкретных требований.

Вызов анатомии

Расположение каждой задачи следует естественной иерархии.Последовательная иерархия улучшает качество обслуживания клиентов.

Компоненты пользовательского интерфейса

Требования к пользовательскому интерфейсу

Элемент	Требование
Зона заголовка	Содержит все метки, управляемые запросчиком 3DS, и находится в верхней части экрана. Примечание: Пользовательский интерфейс браузера не включает зону заголовка.
Зона брендинга	Не должно быть никаких конкурирующих брендов, включая, помимо прочего, MasterCard Identity Check, American Express SafeKey и J / Secure JCB. Название / логотип эмитента Логотип эмитента должен отображаться на странице аутентификации и находиться в верхнем левом углу. Разрешен только логотип эмитента. Не разрешены логотипы других услуг эмитента Использование сторонних имен или логотипов запрещено Visa Logo Логотип Visa должен отображаться на странице аутентификации, должен отображаться в правом верхнем углу. Логотип Visa можно получить в Стандартах товарных знаков Visa https://www.productbrandstandards.com/account/login?ReturnUrl=%2F.
Зона испытания	Содержит информацию об обработке и запросе и расположен между зоной брендинга и зоной информации. Состояние отсутствия наведения / посещения (применимо только к мобильному представлению) Без движения / анимации или звука
Информационная зона	Содержит дополнительную информацию для держателя карты и находится в нижней части экрана.
Фон страницы	Требования к фону для любой страницы пользовательского интерфейса 3DS будут различаться в зависимости от типа пользовательского интерфейса. для собственных интерфейсов Белый фон должен использоваться для обеспечения единообразия и во избежание расхождения цветов между цветовыми схемами эмитента и продавца Для интерфейсов браузер / HTML Белый фон должен использоваться для обеспечения единообразия и во избежание расхождения цветов между цветовыми схемами эмитента и продавца Эмитент может использовать свою цветовую схему, которая знакома потребителям и ассоциируется с Эмитентом.
Без внешних ссылок	Не должно быть никаких внешних ссылок или рекламы, никаких ссылок на другие сайты, а также никаких рекламных или иных коммуникационных сообщений.

Адаптивный дизайн

Продавцы

ожидают, что Visa Secure будет адаптироваться ко всем размерам экранов (например, телефонов, планшетов и настольных устройств).

Размер экрана и разрешение

Экраны вызовов

Visa Secure должны адаптироваться к разрешению устройства, на котором они отображаются.

Visa Secure экраны могут иметь следующие размеры:

• 250 х 400
• 390 х 400
• 500 х 600
• 600 х 400
• Полный экран

Макеты экрана Visa Secure должны адаптироваться ко всем размерам экрана. Эмитенты должны проверить элемент данных о размере экрана в сообщении запроса аутентификации, чтобы убедиться, что размер экрана, который они отображают для пользователей, соответствует требованиям.

Если у эмитента нет размера экрана запроса, который соответствует размеру экрана пользователя, рекомендуется, чтобы эмитент представлял размер экрана меньше, чем размер экрана пользователя.Экран 250×400 может отображаться на экранах всех размеров, в то время как это не относится к экранам большего размера.

Содержимое экрана должно загружаться в первую очередь в соответствии с визуальной иерархией Visa Secure, чтобы пользователь мог четко видеть заголовок информации о проблеме и текст информации о проблеме. Пользователи должны иметь возможность быстро понять, почему их просят пройти аутентификацию и как это сделать.

Шрифты

Open Sans следует использовать в качестве основного шрифта там, где он поддерживается (например,г. Латинский, греческий и кириллица). Noto следует использовать для всех языков, не охваченных Open Sans (например, китайский, японский, корейский, языки Юго-Восточной Азии и Ближнего Востока). Open Sans Regular или Open Sans Semibold можно использовать для выделения или построения иерархии в сообщениях.

Определения

Срок	Определение
3-D Secure (3DS)	Протокол аутентификации электронной коммерции, который обеспечивает безопасную обработку платежных, неплатежных операций и транзакций по карте подтверждения счета.Для получения дополнительной информации о 3-D Secure посетите веб-сайт EMVCo [https://www.emvco.com/emv-technologies/3d-secure/]
Отказанная аутентификация	Аутентификация не завершена. Аутентификация не может быть завершена из-за отмены держателя карты, тайм-аута бездействия или неисправности эмитента / продавца.
Сервер контроля доступа (ACS)	Компонент, работающий в домене эмитента, который проверяет, доступна ли аутентификация для номера карты и типа устройства, а также аутентифицирует определенных держателей карт.
Пользовательский интерфейс сервера контроля доступа (ACS UI)	Пользовательский интерфейс ACS создается во время запроса держателя карты и отображается ACS в окне запроса браузера.
Аутентификация	В контексте 3-D Secure — процесс подтверждения того, что лицо, совершающее транзакцию электронной торговли, имеет право использовать платежную карту.
Авторизация	Процесс, с помощью которого Эмитент или процессор от имени Эмитента утверждает транзакцию для оплаты.
Браузер	В контексте 3-D Secure браузер является каналом для передачи сообщений между сервером 3DS (в домене эквайера) и ACS (в домене эмитента).

Схема

В этом разделе мы исследуем, как продавцы могут реализовать рекомендации Visa Secure на основе наших рекомендаций по макету и руководств для продавцов. Выбор будет зависеть от технических возможностей и существующих платформ.

Пример модального представления

Продавцы должны реализовать модальное представление для экрана аутентификации, который находится над их страницей оформления заказа.Для мобильных устройств мы рекомендуем использовать модальные представления полной ширины и полной высоты.

Модальное представление является предпочтительной реализацией проверки подлинности для браузеров, поскольку она эффективно фокусирует внимание пользователей на задаче проверки подлинности с минимальными отвлекающими факторами.

Экран обработки (аутентификация без трения)

Беспрепятственный поток возникает, когда эмитент аутентифицирует держателя карты без участия держателя карты, оценивая уровень риска транзакции.Продавец отправляет Эмитенту сообщение с запросом аутентификации со всеми необходимыми данными для облегчения аутентификации на основе рисков. Эмитент оценивает транзакцию и отвечает либо без запроса дополнительной проверки, либо с запросом запроса. Если запрос вызова получен, можно использовать один из следующих методов вызова.

Во время обмена сообщениями для держателя карты должен отображаться экран, указывающий на то, что выполняется обработка 3-D Secure.

Экран обработки — браузер

Экран обработки должен включать вращающееся колесо и логотип Visa под

.

Экран обработки — мобильный

Экран обработки должен включать вращающееся колесо и логотип Visa под

.

Платежные потоки

В этом разделе содержатся описания методов проверки Visa Secure для аутентификации платежей, которые включают как браузер, так и собственную версию потока.

Обзор

Когда клиентов просят подтвердить транзакции, им предоставляется поток запроса. Используемый метод проверки определяется эмитентом. Чтобы обеспечить бесперебойное обслуживание клиентов, эмитенты и поставщики ACS должны отображать пояснительный текст на экранах запросов.

Одноразовый код доступа (OTP)

Клиенты подтверждают транзакции, используя безопасный код, отправляемый по тексту или электронной почте. Эмитенты могут выбирать, какие каналы доставки сделать доступными для клиента.Мы рекомендуем предоставить заказчику и то, и другое.

Технические характеристики — OTP / электронная почта (мобильный)

Технические характеристики — OTP / SMS (мобильный)

Требования к SMS / электронной почте — мобильный (в приложении)

#	Элементы данных из спецификации EMV 3DS	Содержание / требование
1	Заголовок информации о вызове Экран выбора одноразового пароля	Страница должна отображать заголовок Keep Your Account Safe над текстом запроса для экрана выбора одноразового пароля.
2	Текст с информацией о вызове Экран выбора одноразового пароля	Мы почти закончили. Чтобы произвести покупку, мы отправим вам подтверждение от (Название эмитента). Куда бы вы его отправили? Радиокнопка: Мой адрес электронной почты << замаскированный адрес электронной почты >> Радиокнопка: Мой мобильный << замаскированный номер телефона >>
3	Заголовок информации о вызове Ввод кода OTP	На странице должен отображаться заголовок Подтвердить по телефону над текстом запроса.
4	Текст с информацией о вызове Ввод кода OTP	Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам проверочный код на ваш зарегистрированный номер мобильного телефона << замаскированный номер телефона >>. Вы авторизуете платеж на (merchantName) {buyCurrency} (сумма покупки) . OTP по электронной почте: Мы только что отправили вам проверочный код на ваш зарегистрированный адрес электронной почты << замаскированный адрес электронной почты >>. Вы авторизуете платеж на (merchantName) {buyCurrency} (сумма покупки) . Название продавца, валюта покупки и сумма покупки, как указано в сообщении AReq.
5	Наклейка с информацией о вызове	Отображаемое имя для этого поля должно быть « Verification Code» .
6	Запрос информации о вводе данных	Поле ввода
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
8	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code ». Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
9	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
10	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Технические характеристики — Браузер

Требования к SMS / электронной почте — браузер

#	Зона	Элемент	Содержание / требование
1	Вызов	Экран выбора одноразового пароля	На странице должен отображаться заголовок Обеспечьте безопасность учетной записи над информацией о выборе одноразового пароля. Мы почти закончили. Чтобы произвести покупку, мы отправим вам подтверждение от (Название эмитента). Куда бы вы его отправили? Радиокнопка: Мой адрес электронной почты << замаскированный адрес электронной почты >> Радиокнопка: Мой мобильный << замаскированный номер телефона >>
2	Вызов	Экран ввода кода OTP	На странице должен отображаться заголовок Подтвердить по телефону над текстом запроса. Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам проверочный код на ваш зарегистрированный номер мобильного телефона << замаскированный номер телефона >>. Вы авторизуете платеж на (merchantName) {buyCurrency} (сумма покупки) . OTP по электронной почте: Мы только что отправили вам проверочный код на ваш зарегистрированный адрес электронной почты << замаскированный адрес электронной почты >>. Вы авторизуете платеж на (merchantName) {buyCurrency} (сумма покупки) . Название продавца, валюта покупки и сумма покупки, как указано в сообщении AReq.
3	Вызов	Поле ввода пароля	Отображаемое имя для этого поля должно быть « Verification Code » над полем ввода.
4	Вызов	Отправить поле аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
5	Вызов	Повторно отправить информационное поле	Отображаемое имя для этого поля должно быть « Resend Code» . Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
6	Информация	Поле «Нужна помощь»	Отображаемое имя для этого поля должно быть « Нужна помощь? ’. Отобразите метку «Нужна помощь?» Как графический элемент управления, который можно развернуть. Отображать текст «Нужна помощь» только тогда, когда пользователь выбирает ярлык «Нужна помощь». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.
7	НЕТ	Аутентификация прошла успешно	Окно испытания закрывается, и владелец карты переводится на страницу успешной покупки. * Информацию о неверных попытках аутентификации см. Ниже

Код подтверждения

Неверные технические характеристики Требования — Браузер

Код подтверждения неправильные требования

Требования к браузеру по SMS / электронной почте с одноразовым паролем отображаются до тех пор, пока владелец карты не вводит неверный проверочный код, затем следуйте инструкциям ниже для неправильного ввода:

Проверочный код

, оставленный пустым Технические характеристики — браузер

Проверочный код

оставлен пустым Требования — браузер

Требования к браузеру по SMS / электронной почте с одноразовым паролем отображаются до тех пор, пока владелец карты не введет проверочный код и не нажмет кнопку «Подтвердить», затем выполните следующие действия:

#	Элемент	Содержание / требование
1	Проверочный код остается пустым Сообщение об ошибке	Страница должна отображать заголовок Пожалуйста, заполните обязательное поле. над полем ввода пароля.
2	Поле ввода пароля	Отображаемое имя для этого поля должно быть « Verification Code » над полем ввода. Отображаемое имя под полем ввода должно быть «. Введите действительный код»
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
4	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code» . Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
5	Использовать другой метод аутентификации	Отображаемое имя для этого поля должно быть « Возникли проблемы? ’. Дисплей « Выберите другой вариант безопасности ». Новый экран должен отображаться, если этот параметр выбран с другим методом проверки подлинности (см. Раздел «Метод резервной проверки подлинности»).

Введено неправильное количество цифр — браузер

Требования к браузеру для SMS / электронной почты с одноразовым паролем отображаются до тех пор, пока владелец карты не введет неправильное количество цифр, затем выполните следующие действия:

#	Элемент	Содержание / требование
1	Поле ввода пароля	Отображаемое имя для этого поля должно быть « Verification Code » над полем ввода. Отображаемое имя под полем ввода должно быть « Пожалуйста, введите все цифры X». включает общее количество цифр.
2	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
3	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code» . Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
4	Использовать другой метод аутентификации	Отображаемое имя для этого поля должно быть « Возникли проблемы? ’. Отобразите этикетку « Выберите другой вариант безопасности» ’. Новый экран должен отображаться, если этот параметр выбран с другим методом проверки подлинности (см. Раздел «Метод резервной проверки подлинности»).

Технические характеристики максимального количества попыток — браузер

Максимальное количество попыток Требования

Требования к браузеру по SMS / электронной почте с одноразовым паролем отображаются до тех пор, пока владелец карты не достигнет максимального количества попыток, затем выполните следующие действия:

#	Элемент	Содержание / требование
1	Сообщение об ошибке	Страница должна отображать заголовок Это неправильный код.Пожалуйста, попробуйте еще раз. Над полем ввода пароля. Максимальное количество попыток не должно превышать 6 раз.
2	Поле ввода пароля	Отображаемое имя для этого поля должно быть « Verification Code » над полем ввода. Отображаемое имя под полем ввода должно быть «. Введите действительный код»
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
4	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code» . Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
5	Использовать другой метод аутентификации	Отображаемое имя для этого поля должно быть « Возникли проблемы? ’. Дисплей « Выберите другой вариант безопасности ». Новый экран должен отображаться, если этот параметр выбран с другим методом проверки подлинности (см. Раздел «Метод резервной проверки подлинности»).
6	Максимальное количество достигнутых попыток	Страница должна содержать заголовок «Получить новый проверочный код». Язык выше максимального числа попыток. Вы достигли максимального количества попыток с текущим кодом подтверждения. Чтобы продолжить, мы отправим вам еще один код для подтверждения вашей личности. Мы отправим вам проверочный код в текстовом сообщении на << замаскированный номер телефона >>. Максимальное количество попыток не должно превышать 3 раза.
7	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code» . Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.

Технические характеристики метода аутентификации резервного копирования (автоматический телефон + биометрические данные) — браузер

Требования к браузеру по SMS / электронной почте с одноразовым паролем отображаются до тех пор, пока владелец карты не решит отправить проверочный код другому параметру безопасности:

#	Элемент	Содержание / требование
1	Метод аутентификации резервной копии, страница	Метод аутентификации резервной копии, страница
2	Резервные методы аутентификации	Радиокнопка должна использоваться со следующим языком. Автоматический телефонный звонок: Получите код безопасности, позвонив по телефону << замаскированный номер телефона >> или << замаскированный номер телефона >>. Биометрия: Получите push-уведомление от своего банковского приложения, чтобы использовать отпечаток пальца или лицо. QR-код: Сгенерировать одноразовый токен, действительный на время транзакции.
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить » при выборе радиокнопки.
4	Автоматический телефонный звонок	На странице должен отображаться заголовок. Выберите номер телефона над текстом запроса. Радиокнопка: Мой мобильный << замаскированный номер телефона >> Радиокнопка: Мой стационарный << номер замаскированного телефона >>
5	Поле ввода пароля	Отображаемое имя для этого поля должно быть « Verification Code » над полем ввода.
6	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
7	Использовать другой метод аутентификации	Отображаемое имя для этого поля должно быть « Возникли проблемы? ’. Дисплей « Выберите другой вариант безопасности ». Новый экран должен отображаться, если этот параметр выбран с другим методом проверки подлинности (см. Раздел «Метод резервной проверки подлинности»).
8	Наклейка «Нужна помощь»	Отображаемое имя для этого поля должно быть « Нужна помощь? ’. Отобразите метку «Нужна помощь?» Как графический элемент управления, который можно развернуть.
9	Нужен текст справки	Отображать текст «Нужна помощь» только тогда, когда пользователь выбирает ярлык «Нужна помощь». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Резервный метод аутентификации (биометрический) — браузер

Требования к браузеру по SMS / электронной почте с одноразовым паролем отображаются до тех пор, пока владелец карты не решит отправить проверочный код другому параметру безопасности:

#	Элемент	Код / Требование
1	Метод аутентификации резервной копии, страница	Страница должна отображать заголовок «Выберите параметр безопасности» над параметром «Выбор метода резервной аутентификации».
2	Резервные методы аутентификации	Radio Button должен использоваться для методов резервного копирования. Не все параметры должны поддерживаться, если эти параметры используются, необходимо использовать следующий язык. Автоматический телефонный звонок: Получите код безопасности, позвонив по телефону << замаскированный номер телефона >> или << замаскированный номер телефона >>. Биометрия: Получите push-уведомление от своего банковского приложения, чтобы использовать отпечаток пальца или лицо. QR-код: Сгенерировать одноразовый токен, действительный на время транзакции .
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить » при выборе радиокнопки.
4	Биометрия	Страница должна отображать заголовок Подтвердите это через приложение {Issuer Name}, затем вернитесь на эту страницу. Графика с биометрическим приложением может отображаться без анимации или звука.
5	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
6	Использовать другой метод аутентификации	Отображаемое имя для этого поля должно быть « Возникли проблемы? ’. Дисплей « Выберите другой вариант безопасности ». Новый экран должен отображаться, если этот параметр выбран с другим методом проверки подлинности (см. Раздел «Метод резервной проверки подлинности»).
7	Наклейка «Нужна помощь»	Отображаемое имя для этого поля должно быть « Нужна помощь? ’. Отобразите метку «Нужна помощь?» Как графический элемент управления, который можно развернуть.
8	Нужен текст справки	Отображать текст «Нужна помощь» только тогда, когда пользователь выбирает ярлык «Нужна помощь». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.
9	Вернуться на страницу оформления заказа	После того, как потребитель успешно завершит биометрическую аутентификацию и вернется на страницу оформления заказа, должен отобразиться экран успешной покупки.

Резервный метод аутентификации (QR-код) — Браузер

Требования к браузеру по SMS / электронной почте с одноразовым паролем отображаются до тех пор, пока владелец карты не решит отправить проверочный код другому параметру безопасности:

#	Элемент	Содержание / требование
1	Метод аутентификации резервной копии, страница	Страница должна отображать заголовок «Выберите параметр безопасности» над параметром «Выбор метода резервной аутентификации».
2	Резервные методы аутентификации	Radio Button должен использоваться для методов резервного копирования. Не все параметры должны поддерживаться, если эти параметры используются, необходимо использовать следующий язык. Автоматический телефонный звонок: Получите код безопасности, позвонив по телефону << замаскированный номер телефона >> или << замаскированный номер телефона >>. Биометрия: Получите push-уведомление от своего банковского приложения, чтобы использовать отпечаток пальца или лицо. QR-код: Сгенерировать одноразовый токен, действительный на время транзакции .
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить » при выборе радиокнопки.
4	QR-код	На странице должен отображаться заголовок. Отсканируйте QR-код над QR-кодом. Отсканируйте QR-код с помощью приложения {Issuer Name} на мобильном телефоне и следуйте инструкциям. Показать QR-код для сканирования .
5	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
6	Поле ввода пароля	Отображаемое имя для этого поля должно быть « Verification Code » над полем ввода.
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
8	Использовать другой метод аутентификации	Отображаемое имя для этого поля должно быть « Возникли проблемы? ’. Дисплей « Выберите другой вариант безопасности ». Новый экран должен отображаться, если этот параметр выбран с другим методом проверки подлинности (см. Раздел «Метод резервной проверки подлинности»).
9	Наклейка «Нужна помощь»	Отображаемое имя для этого поля должно быть « Нужна помощь? ’. Отобразите метку «Нужна помощь?» Как графический элемент управления, который можно развернуть.
10	Нужен текст справки	Отображать текст «Нужна помощь» только тогда, когда пользователь выбирает ярлык «Нужна помощь». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации

Внешняя аутентификация (OOB)

Пользователи проверяют транзакции в службе аутентификации своего эмитента. Эмитенты могут выбрать, какую услугу сделать доступной для аутентификации пользователя при внеплановой работе, например аутентификации через мобильное приложение эмитента.

Встроенные в приложение задачи создаются с помощью шаблонов 3DS SDK для упрощения работы, соответствующей собственному пользовательскому интерфейсу продавца.Рекомендации в этом разделе учитывают технические характеристики 3DS SDK, которые немного отличаются от технических характеристик взаимодействия с пользователем HTML.

Задачи, основанные на HTML, позволяют эмитенту более гибко подходить к решению задач. Мы включили в наши рекомендации три раздела, специально посвященные проблемам UX HTML для приложений, мобильных и настольных браузеров.Задачи на основе HTML позволяют эмитентам:

• Используйте форматированный текст для экранов инструкций по вызову
• Разрешить пользователям выбирать метод резервной аутентификации, если они не смогут выполнить аутентификацию OOB

В обоих случаях настоятельно рекомендуется, чтобы издатели отправляли пользователям push-уведомление в свою службу аутентификации OOB после показа пользователям информационного текста запроса OOB. Было показано, что это улучшает взаимодействие с пользователем, предоставляя пользователям прямой путь к службе аутентификации OOB своего эмитента вместо того, чтобы переходить к ней вручную.

Требования к OOB — встроенное мобильное приложение

#	Элемент	Код / Требование
1	Заголовок информации о вызове	На странице должен отображаться заголовок «Убедитесь, что это вы» над текстом о задании.
2	Текст информации о вызове	Этот текст должен включать следующий язык: Перед размещением заказа вы должны подтвердить платеж [Продавцу] на [Сумма]. Шаг 1. Откройте приложение [Issuer] на мобильном устройстве для проверки. Шаг 2. Вернитесь на эту страницу и нажмите «Готово», чтобы завершить оформление заказа.
3	Отправить этикетку аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с надписью «Завершено».
4	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
5	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Требования к OOB — HTML-код в мобильном приложении

Технические характеристики — HTML-код для мобильных приложений в приложении

#	Элемент	Код / Требование
1	Заголовок информации о вызове	Страница должна отображать заголовок. Убедитесь, что это вы над текстом о задаче.
2	Текст информации о вызове	Этот текст должен включать следующий язык: Перед размещением заказа вы должны подтвердить оплату [Продавцу] на [Сумма]. Откройте приложение [Issuer] на своем мобильном устройстве, чтобы проверить. Вернитесь на эту страницу и нажмите «Готово», чтобы завершить оформление заказа. Рекомендуется использовать нумерованные списки с форматированным текстом, чтобы пользователи могли четко понимать шаги аутентификации.
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Complete ».
4	Текст метода аутентификации резервной копии	Этот текст должен включать следующий язык: Возникли проблемы?
5	Метка метода аутентификации резервной копии	Элемент формы, который должен выровняться с левой стороной нижнего поля с отображением « Выберите другой параметр безопасности ».
6	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
7	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Требования к OOB — мобильный браузер HTML

Технические характеристики — мобильный браузер HTML

#	Элемент	Код / Требование
1	Заголовок информации о вызове	Страница должна отображать заголовок. Убедитесь, что это вы над текстом о задаче.
2	Текст информации о вызове	Этот текст должен включать следующий язык: Перед размещением заказа вы должны подтвердить оплату [Продавцу] на [Сумма]. Откройте приложение [Issuer] на своем мобильном устройстве, чтобы проверить. Вернитесь на эту страницу и нажмите «Готово», чтобы завершить оформление заказа. Рекомендуется использовать нумерованные списки с форматированным текстом, чтобы пользователи могли четко понимать шаги аутентификации.
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Complete ».
4	Текст метода аутентификации резервной копии	Этот текст должен включать следующий язык: Возникли проблемы?
5	Метка метода аутентификации резервной копии	Элемент формы, который должен выровняться с левой стороной нижнего поля с отображением « Выберите другой параметр безопасности ».
6	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
7	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Требования к OOB — настольный браузер HTML

Технические характеристики — Настольный браузер HTML

#	Элемент	Код / Требование
1	Заголовок информации о вызове	Страница должна отображать заголовок. Убедитесь, что это вы над текстом о задаче.
2	Текст информации о вызове	Этот текст должен включать следующий язык: Перед размещением заказа вы должны подтвердить оплату [Продавцу] на [Сумма]. Откройте приложение [Issuer] на своем мобильном устройстве, чтобы проверить. Вернитесь на эту страницу и нажмите «Готово», чтобы завершить оформление заказа. Рекомендуется использовать нумерованные списки с форматированным текстом, чтобы пользователи могли четко понимать шаги аутентификации.
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Complete ».
4	Текст метода аутентификации резервной копии	Этот текст должен включать следующий язык: Возникли проблемы?
5	Метка метода аутентификации резервной копии	Элемент формы, который должен выровняться с левой стороной нижнего поля с отображением « Выберите другой параметр безопасности ».
6	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
7	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Требования к преждевременному завершению

В каждом из каналов устройства, показанных выше, пользователи могут нажать кнопку «Завершить» до того, как произойдет аутентификация OOB. В случае, если пользователи нажимают кнопку «Завершить» перед аутентификацией OOB, рекомендуется, чтобы эмитенты отображали экран преждевременного завершения, который соответствует следующим рекомендациям, чтобы пользователи понимали, что им необходимо пройти аутентификацию в службе аутентификации OOB их эмитента.

#	Элемент	Код / Требование
1	Заголовок информации о необходимости справки	Страница должна отображать заголовок Ой! Вы нажимали «Завершить» перед первым переходом в приложение Digital Bank? над текстом «Нужна информация».
2	Нужна справка Текст информации	Этот текст должен включать следующий язык: Шаг 1. Откройте приложение [Issuer] на мобильном устройстве для проверки. Шаг 2. Вернитесь на эту страницу и нажмите «Готово», чтобы завершить оформление заказа.
3	Отправить этикетку аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с надписью «Завершено».
4	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
5	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Требования к методу аутентификации резервного копирования — HTML для мобильных или настольных ПК

HTML-вызовы дают эмитентам возможность предоставить пользователям выбор резервного метода аутентификации, если аутентификация OOB невозможна.Чтобы выбрать метод аутентификации резервного копирования, пользователи нажимают «Выбрать другой вариант безопасности» на экране запроса OOB HTML, и им предоставляются параметры безопасности резервного копирования, если их предложит эмитент.

Примечание: Для европейских эмитентов, соответствующих PSD2 SCA, одноразовые коды доступа не могут быть отправлены на адрес электронной почты пользователя.

#	Элемент	Код / Требование
1	Заголовок информации о необходимости справки	Страница должна отображать заголовок Выберите другой параметр безопасности над текстом Требуется информация о помощи.
2	Нужна справка Текст информации	Этот текст должен включать следующий язык: (заголовок в поле) Получите код безопасности, отправленный на [radiobtn] [адрес электронной почты] [radiobtn] (123) xxx-xx12
3	Отправить этикетку аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить ».
4	Метка отмены резервного метода аутентификации	Элемент формы, который должен выровняться с левой стороной нижнего поля с отображением « Я передумал. Вернись. ” Эта метка направляет пользователя обратно к экрану информации о вызове OOB

Аутентификация на основе знаний (KBA)

Клиенты проверяют транзакции, отвечая на основанные на знаниях вопросы. Эмитенты могут выбирать, какие методы сделать доступными для клиентов.

Технические характеристики — KBA (мобильный)

Требования, основанные на знаниях — для мобильных устройств (в приложении)

#	Элемент	Код / Требование
1	Заголовок информации о вызове Подтверждение оплаты до аутентификации	Страница должна отображать заголовок Обеспечьте безопасность своей учетной записи над текстом «Информация о вызове».
2	Текст информации о вызове Подтверждение оплаты до аутентификации	Этот текст должен включать следующий язык: Вы санкционируете платеж (merchantName) на {покупную валюту} (сумма покупки) . Давайте убедимся, что это вы . Ответьте на контрольные вопросы: {X}. Название продавца, валюта покупки и сумма покупки, как указано в сообщении AReq. Рекомендуется задать минимум 2 контрольных вопроса.
3	Заголовок информации о вызове Страница испытаний	Страница должна отображать заголовок Подтвердите покупку над текстом о вызове.
4	Текст информации о вызове	Отображаемое имя для этого поля должно быть {вопрос 1} и {фактический вопрос}.
5	Ярлык с информацией о вызове Если не вопрос с несколькими вариантами ответов	Отображаемое имя для этого поля должно быть « Ваш ответ» .
6	Ввод данных о вызове Если не вопрос с несколькими вариантами ответов	Поле ввода
7	Ярлык с информацией о вызове Для вопроса с несколькими вариантами ответов	Отображаемое имя для этого поля должно быть « Пожалуйста, выберите все подходящие».
8	Ввод данных о вызове Для вопроса с несколькими вариантами ответов	Несколько флажков
9	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Подтвердить ».
10	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
11	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Спецификации, основанные на знаниях — Браузер

Требования, основанные на знаниях — неправильный ответ — браузер

#	Элемент	Содержание / требование
1	Сообщение об ошибке	На странице должен быть заголовок Вы неправильно ответили на один или несколько вопросов.Пожалуйста, попробуйте еще раз. A над полем ввода информации.
2	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить ».
3	Подтверждение платежа до аутентификации	Этот текст должен включать следующий язык: Вы санкционируете платеж (merchantName) на {покупную валюту} (сумма покупки) . Давайте убедимся, что это вы . Ответьте на контрольные вопросы: {X}. Название продавца, валюта покупки и сумма покупки, как указано в сообщении AReq. Рекомендуется задать минимум 2 контрольных вопроса.
Дисплей № 3-10 выше, чтобы покупатель мог повторить попытку

Отменить / закрыть

#	Элемент	Код / Требование
1	Отменить / закрыть	Держателю карты должны быть предоставлены средства, позволяющие отказаться от подачи возражения.Однако, если владелец карты выбирает «Отменить или закрыть», эмитент должен представить предупреждение.
2	Отменить / закрыть предупреждение	Если владелец карты нажимает кнопку «Отменить или закрыть» или если владелец карты нажимает кнопку «Назад», должно отображаться предупреждение, информирующее держателя карты о том, что транзакция будет прекращена. На странице должен отображаться заголовок Вы уверены? над текстом выхода. В случае отмены вы не сможете авторизовать платеж на (merchantName) {покупная валюта} (сумма покупки) . Это означает, что вы не сможете приобрести товар в своей корзине.
3	Вернуться на страницу аутентификации	Элемент формы, который должен выровняться с центром поля с отображением « Я изменил свое мнение, ».
4	Завершить Отмена / Закрыть	Отображаемое имя для этого поля должно быть « Да, я хочу отменить». Если владелец карты нажимает кнопку «ОК», ACS должен вернуть ответ об ошибке аутентификации участвующему продавцу, чтобы не дать мошенникам избежать аутентификации. Это предупреждение должно сообщать держателю карты, что продолжение отмены прекращает покупку у участвующего продавца.

Аутентификация статического пароля

Для повышения удобства работы пользователей и безопасности держателей карт Visa рекомендует эмитентам использовать методы аутентификации держателей карт, основанные на оценке риска или динамические.Статические пароли могут привести к высокому проценту отказов от проверки подлинности, так как пользователи не всегда могут иметь доступ к статическим паролям издателя для проверки подлинности.

Кроме того, с октября 2018 года Visa отказалась от использования статических паролей Visa Secure и связанных с ними процессов регистрации.

Предыдущие версии

Щелкните здесь, чтобы загрузить Руководство по пользовательскому интерфейсу с Visa Secure с использованием 3DS 1.0 PDF.

Лучшие практики дизайна

Набор принципов UX

В нашем мире UX мы живем по трем основным принципам, которые изложены ниже.Общий эффект — быстрый и простой для клиентов поток.

• Держитесь подальше
• Думайте как человек, а не робот
• Будьте заслуживающими доверия

Доступность

Согласно Инициативе доступности Интернета, процент людей с ограниченными возможностями во многих группах населения составляет от 10% до 20%; примерно 285 миллионов человек страдают нарушениями зрения; и 10-15% населения мира страдают дислексией. Мы рекомендуем дизайнерам руководствоваться международными стандартами в соответствии с Руководством по обеспечению доступности веб-контента уровня AA 2.0. Мы собрали краткий список предложений по разным направлениям.

Руководящие принципы 3DS UX, представленные на этом веб-сайте, соответствуют требованиям ADA. Эмитентам рекомендуется следовать этим руководящим принципам UX, чтобы их экраны 3DS были доступны для всех пользователей.

Полные инструкции по доступности см. На сайте wcag.org.

Ресурсы пользовательского интерфейса

Visa 3DS_UIAssets_Mobile_Browser.sketch

Дополнительные варианты использования

Visa Secure поддерживает функции, которые улучшают функциональность аутентификации и удобство работы пользователей за пределами платежных потоков.В этом разделе рассматривается идентификация и проверка токена (ID&V), а также статус доверенного получателя с помощью Visa Secure.

Проверка держателя карты как часть идентификатора токена EMV и V

Эмитенты

могут выполнять идентификацию и проверку (ID&V) своих владельцев учетных записей с помощью сценариев использования EMV® 3-D Secure (3DS) для Visa Token Service (VTS), таких как предоставление токенов или привязка устройств Cloud Token Framework (CTF) и аутентификация держателей карт. Спецификации EMV 3DS 2.1 и 2.2 определяют категорию сообщения о неплатежах и индикатор аутентификации специально для ID&V токена EMV®.

В запросах аутентификации

ID&V установлены следующие поля:

• Индикатор аутентификации запрашивающей стороны 3DS = 06 (проверка держателя карты как часть идентификатора и идентификатора токена EMV)

Эмитентам рекомендуется представлять потоки вызовов аутентификации пользователей, специфичные для ID&V, для запросов аутентификации ID&V. Ниже приведены инструкции по потоку вызовов EMV® 3DS ID&V от эмитента в зависимости от метода проверки и канала устройства.

При заполнении EMV 3DS 2.После проверки подлинности платежа держатели карт могут иметь возможность доверять списку компаний, которым они доверяют, чтобы избежать необходимости проверять подлинность будущих покупок. Затем эти предприятия включаются в «список доверия», который ведет эмитент держателя карты или поставщик платежных услуг.

Чтобы запросить статус доверенного получателя, продавец должен установить индикатор вызова запрашивающего лица 3DS в запросе аутентификации на 09 (запрос запрошен — запрос списка доверия запрошен, если требуется вызов).После того, как продавец добавлен в список доверенных лиц держателя карты, продавец должен установить для индикатора запроса 3DS значение 08 (запрос не запрашивается; используйте исключение из списка доверия, если оно не требуется).

Эмитенты, получающие запросы аутентификации доверенного получателя, должны предоставить держателям карт возможность добавить продавца, у которого они совершают покупки, в свой список доверенных получателей. Следующие ниже руководства по UX были протестированы, чтобы эмитент мог эффективно сообщить держателю карты, что статус доверенного получателя может быть предоставлен продавцу, у которого он совершает покупки.

Одноразовый пароль (OTP)

Одноразовый пароль (OTP) — Браузер

Клиенты подтверждают транзакции, используя безопасный код, отправляемый по тексту или электронной почте. Эмитенты могут выбирать, какие каналы доставки сделать доступными для клиента. Мы рекомендуем предоставить заказчику и то, и другое. После того, как клиент успешно отправит правильный OTP, ACS эмитента закрывает окно запроса и передает управление взаимодействием обратно на сервер 3DS.

Требования к SMS / электронной почте — браузер

#	Элементы данных из спецификации EMV 3DS	Содержание / требование
1	Заголовок информации о вызове Экран выбора одноразового пароля	Страница должна отображать заголовок Получить проверочный код над текстом запроса для экрана выбора одноразового пароля.
2	Текст с информацией о вызове Экран выбора одноразового пароля	Для дополнительной безопасности [Card Issuer] отправит вам одноразовый код. Выберите, как получить код: Радиокнопка: текстовое сообщение << замаскированный номер телефона >> Радиокнопка: электронная почта << замаскированный адрес электронной почты >>
3	Заголовок информации о вызове Ввод кода OTP	На странице должен отображаться заголовок . Введите проверочный код над текстом запроса.
4	Текст с информацией о вызове Ввод кода OTP	Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам подтверждение с помощью текстового сообщения на << замаскированный номер телефона >>. У вас есть [количество попыток входа в одноразовый пароль] OTP по электронной почте: Мы только что отправили вам проверочный код по электронной почте на << замаскированный адрес электронной почты >>. У вас есть [количество попыток входа в одноразовый пароль]
5	Наклейка с информацией о вызове	Отображаемое имя для этого поля должно быть « Verification Code ».
6	Запрос информации о вводе данных	Поле ввода
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить ».
8	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code ». Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
9	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
10	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Одноразовый пароль (OTP) — встроенный в мобильное приложение

Клиенты подтверждают транзакции, используя безопасный код, отправляемый по тексту или электронной почте. Эмитенты могут выбирать, какие каналы доставки сделать доступными для клиента. Мы рекомендуем предоставить заказчику и то, и другое.

Встроенный в приложение интерфейс использует SDK 3DS.Встроенный интерфейс обеспечивает более интегрированный вид и удобство для пользователей. Встроенный интерфейс не использует форматированный текст.

Требования к SMS / электронной почте — встроенное мобильное приложение

#	Элементы данных из спецификации EMV 3DS	Содержание / Требование
1	Заголовок информации о вызове Экран выбора одноразового пароля	На странице должен отображаться заголовок «Получить код подтверждения» над текстом «Информация о запросе» для экрана выбора одноразового пароля.
2	Текст с информацией о вызове Экран выбора одноразового пароля	Для дополнительной безопасности [Card Issuer] отправит вам одноразовый код. Выберите, как получить код: Радиокнопка: текстовое сообщение << замаскированный номер телефона >> Радиокнопка: электронная почта << замаскированный адрес электронной почты >>
3	Заголовок информации о вызове Ввод кода OTP	На странице должен отображаться заголовок «Введите проверочный код» над текстом «Информация о вызове».
4	Текст с информацией о вызове Ввод кода OTP	Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам подтверждение с помощью текстового сообщения на << замаскированный номер телефона >>. У вас есть [количество попыток входа в одноразовый пароль] OTP по электронной почте: Мы только что отправили вам проверочный код по электронной почте на << замаскированный адрес электронной почты >>. У вас есть [количество попыток входа в одноразовый пароль]
5	Наклейка с информацией о вызове	Отображаемое имя для этого поля должно быть «Verification Code».
6	Запрос информации о вводе данных	Поле ввода
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с надписью «Продолжить».
8	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть «Resend Code». Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
9	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
10	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Вне диапазона (OOB)

Out of Band (OOB) — мобильный браузер

Пользователи проверяют транзакции в службе аутентификации своего эмитента. Эмитенты могут выбрать, какую услугу сделать доступной для аутентификации пользователя при внеплановой работе, например аутентификации через мобильное приложение эмитента. После завершения аутентификации через службу OOB эмитента пользователи возвращаются к экрану запроса 3DS эмитента и нажимают «Завершить», чтобы завершить строгую аутентификацию 3DS.

Настоятельно рекомендуется, чтобы эмитенты отправляли пользователям push-уведомление в свою службу аутентификации OOB после показа пользователям информационного текста запроса OOB. Было показано, что это улучшает взаимодействие с пользователем, предоставляя пользователям прямой путь к службе аутентификации OOB своего эмитента вместо того, чтобы переходить к ней вручную.

Требования OOB — мобильный браузер

#	Элемент	Содержание / требование
1	Заголовок информации о вызове	Страница должна отображать заголовок Давайте убедимся, что это вы над текстом запроса.
2	Текст информации о вызове	Этот текст должен включать следующий язык: Для дополнительной безопасности вы будете проверены [службой аутентификации OOB эмитента]. Откройте [Служба аутентификации OOB эмитента] для проверки. Вернитесь на эту страницу и коснитесь Завершить после завершения проверки с помощью [службы проверки подлинности OOB эмитента]. Рекомендуется использовать нумерованные списки с расширенным текстом и полужирный шрифт , чтобы пользователи могли четко понимать этапы аутентификации.
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением «Завершено» .
4	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
5	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Out of Band (OOB) — встроенное мобильное приложение

Пользователи проверяют транзакции в службе аутентификации своего эмитента. Эмитенты могут выбрать, какую услугу сделать доступной для аутентификации пользователя при внеплановой работе, например аутентификации через мобильное приложение эмитента. После завершения аутентификации через службу OOB эмитента пользователи возвращаются к экрану запроса 3DS эмитента и нажимают «Завершить», чтобы завершить строгую аутентификацию 3DS.

Настоятельно рекомендуется, чтобы эмитенты отправляли пользователям push-уведомление в свою службу аутентификации OOB после показа пользователям информационного текста запроса OOB. Было показано, что это улучшает взаимодействие с пользователем, предоставляя пользователям прямой путь к службе аутентификации OOB своего эмитента вместо того, чтобы переходить к ней вручную.

Встроенный в приложение интерфейс использует SDK 3DS. Встроенный интерфейс обеспечивает более интегрированный вид и удобство для пользователей. Встроенный интерфейс не использует форматированный текст.

Требования OOB — встроенное мобильное приложение

#	Элемент	Содержание / требование
1	Заголовок информации о вызове	Страница должна отображать заголовок Давайте убедимся, что это вы над текстом запроса.
2	Текст информации о вызове	Этот текст должен включать следующий язык: Для дополнительной безопасности вы будете проверены [службой аутентификации OOB эмитента]. Откройте [Служба аутентификации OOB эмитента] для проверки. Вернитесь на эту страницу и коснитесь Завершить после завершения проверки с помощью [службы проверки подлинности OOB эмитента]. Рекомендуется использовать нумерованные списки с расширенным текстом и полужирный шрифт , чтобы пользователи могли четко понимать этапы аутентификации.
3	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением «Завершено» .
4	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
5	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Одноразовый пароль (OTP) и аутентификация на основе знаний (KBA)

Одноразовый пароль (OTP) и аутентификация на основе знаний (KBA) — мобильный браузер

Если эмитент заинтересован в выполнении многофакторной аутентификации, методы запроса OTP и KBA могут быть объединены в последовательном порядке.Клиенты выполняют проверку, отправляя защищенный код в текстовом или электронном сообщении и отвечая на два контрольных вопроса.

Требования OTP и KBA — мобильный браузер

#	Элементы данных из спецификации EMV 3DS	Содержание / требование
1	Заголовок информации о вызове Экран выбора одноразового пароля	Страница должна отображать заголовок Получить проверочный код над текстом запроса для экрана выбора одноразового пароля.
2	Текст с информацией о вызове Экран выбора одноразового пароля	Для дополнительной безопасности [Card Issuer] отправит вам одноразовый код. Выберите, как получить код: Радиокнопка: текстовое сообщение << замаскированный номер телефона >> Радиокнопка: электронная почта << замаскированный адрес электронной почты >>
3	Заголовок информации о вызове Ввод кода OTP	На странице должен отображаться заголовок . Введите проверочный код над текстом запроса.
4	Текст с информацией о вызове Ввод кода OTP	Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам подтверждение с помощью текстового сообщения на << замаскированный номер телефона >>. У вас есть [количество попыток входа в одноразовый пароль] OTP по электронной почте: Мы только что отправили вам проверочный код по электронной почте на << замаскированный адрес электронной почты >>.У вас есть [количество попыток входа в одноразовый пароль]
5	Наклейка с информацией о вызове	Отображаемое имя для этого поля должно быть « Verification Code ».
6	Запрос информации о вводе данных	Поле ввода
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить ».
8	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code ». Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
9	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
10	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

#	Элементы	Содержание / требование
1	Заголовок информации о вызове Страница испытаний	На странице должен отображаться заголовок «Ответить на контрольные вопросы» над текстом запроса.
2	Информационный текст запроса	Отображаемое имя для этого поля должно быть Почти готово! Пожалуйста, ответьте на эти два контрольных вопроса. Вопрос 1 из 2 {Вопрос 1} и {фактический Вопрос}.
3	Ярлык с информацией о вызове Если не вопрос с несколькими вариантами ответов	Отображаемое имя для этого поля должно быть «Ваш ответ».
4	Ввод данных о вызове Если не вопрос с несколькими вариантами ответов	Поле ввода
5	Ярлык с информацией о вызове Для вопроса с несколькими вариантами ответов	Отображаемое имя для этого поля должно быть « Пожалуйста, выберите все, что применимо «.
6	Ввод данных о вызове Для вопроса с несколькими вариантами ответов	Несколько флажков
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Отправить ».
8	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
9	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Одноразовый пароль (OTP) и аутентификация на основе знаний (KBA) — встроенная мобильная версия приложения

Если эмитент заинтересован в выполнении многофакторной аутентификации, методы запроса OTP и KBA могут быть объединены в последовательном порядке. Клиенты выполняют проверку, отправляя защищенный код в текстовом или электронном сообщении и отвечая на два контрольных вопроса.

Встроенный в приложение интерфейс использует SDK 3DS. Встроенный интерфейс обеспечивает более интегрированный вид и удобство для пользователей.Встроенный интерфейс не использует форматированный текст.

Требования к OTP и KBA — встроенное мобильное приложение

#	Элементы данных из спецификации EMV 3DS	Содержание / требование
1	Заголовок информации о вызове Экран выбора одноразового пароля	На странице должен отображаться заголовок «Получить код подтверждения» над текстом «Информация о запросе» для экрана выбора одноразового пароля.
2	Текст с информацией о вызове Экран выбора одноразового пароля	Для дополнительной безопасности [Card Issuer] отправит вам одноразовый код. Выберите, как получить код: Радиокнопка: текстовое сообщение << замаскированный номер телефона >> Радиокнопка: электронная почта << замаскированный адрес электронной почты >>
3	Заголовок информации о вызове Запись кода OTP	На странице должен отображаться заголовок Введите проверочный код над текстом запроса.
4	Текст с информацией о вызове Ввод кода OTP	Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам подтверждение с помощью текстового сообщения на << замаскированный номер телефона >>. У вас есть [количество попыток входа в одноразовый пароль] OTP по электронной почте: Мы только что отправили вам проверочный код по электронной почте на << замаскированный адрес электронной почты >>. У вас есть [количество попыток входа в одноразовый пароль]
5	Наклейка с информацией о вызове	Отображаемое имя для этого поля должно быть « Verification Code ».
6	Запрос данных ввода данных	Поле ввода
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с отображением « Продолжить ».
8	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть « Resend Code ». Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
9	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
10	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.

#	Элемент	Содержание / требование
1	Заголовок информации о вызове Страница испытаний	На странице должен отображаться заголовок «Ответить на контрольные вопросы» над текстом запроса.
2	Текст с информацией о вызове	Отображаемое имя для этого поля должно быть Почти готово! Пожалуйста, ответьте на эти два контрольных вопроса. Вопрос 1 из 2 {Вопрос 1} и {фактический Вопрос}.
3	Ярлык с информацией о вызове Если не вопрос с несколькими вариантами ответов	Отображаемое имя для этого поля должно быть «Ваш ответ».
4	Ввод данных о вызове Если не вопрос с несколькими вариантами ответов	Поле ввода
5	Ярлык с информацией о вызове Для вопроса с несколькими вариантами ответов	Отображаемое имя для этого поля должно быть «Пожалуйста, выберите все подходящие».
6	Ввод данных о вызове Для вопроса с несколькими вариантами ответов	Несколько флажков
7	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с надписью «Отправить».
8	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть « Нужна помощь? ’.
9	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Список доверия

Поток доверенных получателей

Во время покупки поставщик сервера EMV 3DS продавца отправит через EMV 3DS запрос эмитенту, чтобы позволить держателю карты предоставить этому продавцу статус доверенного получателя. ACS эмитента отобразит возможность предоставить держателю карты статус доверенного получателя. Если владелец карты соглашается предоставить продавцу статус доверенного получателя, то он аутентифицируется как для предоставления статуса доверенного получателя, так и для платежа.После успешной аутентификации продавцу будет присвоен статус доверенного получателя по основному номеру счета (PAN) держателя карты.

После того, как владелец карты предоставил продавцу статус доверенного получателя, для будущих покупок с использованием того же PAN у этого продавца может не потребоваться строгая аутентификация держателя карты. Держатели карт должны иметь возможность определять, какие продавцы имеют статус доверенного получателя, через онлайн-банкинг их эмитента.

#	Элементы данных из спецификации EMV 3DS	Содержание / требование
1	Заголовок информации о вызове Ввод кода OTP	На странице должен отображаться заголовок «Введите проверочный код» над текстом «Информация о вызове».
2	Текст с информацией о вызове Ввод кода OTP	Этот текст должен включать следующий язык: OTP по SMS: Мы только что отправили вам подтверждение с помощью текстового сообщения на << замаскированный номер телефона >>. У вас есть [количество попыток ввести одноразовый пароль] попыток. OTP по электронной почте: Мы только что отправили вам проверочный код по электронной почте на << замаскированный адрес электронной почты >>. У вас есть [количество попыток входа в одноразовый пароль]
3	Наклейка с информацией о вызове	Отображаемое имя для этого поля должно быть «Verification Code».
4	Запрос информации о вводе данных	Поле ввода
5	Отправить этикетку для аутентификации	Элемент формы, который должен выровняться по центру нижнего поля с надписью «Подтвердить»
6	Повторно отправить информационный ярлык	Отображаемое имя для этого поля должно быть «Resend Code». Информация о вызове повторно отправляется заказчику. Элемент формы, который должен вертикально выровняться по центру нижнего поля.
7	Флажок для доверенного получателя	Необходимо установить флажок на следующем предлагаемом языке: Включите быструю аутентификацию, чтобы пропустить эти шаги в будущем Хотя у эмитента может быть свой собственный язык для программы доверенного бенефициара, во время пользовательского тестирования Visa предпочтение было отдано указанному выше языку, назвав программу «Быстрая проверка подлинности».Это рекомендуемый язык для программ Доверенных получателей с точки зрения Visa.
8	Наклейка с информацией о доверенном получателе	Отображение информационной метки «Доверенный получатель» как графического элемента управления, который может быть расширен. Отображаемое имя для этого поля должно быть «Подробнее о быстрой аутентификации».
9	Текст информации о доверенном получателе	Отображать текст информации о доверенном получателе только тогда, когда пользователь выбирает «Метку информации о доверенном получателе». Рекомендуется следующий язык: Банки теперь обязаны проводить клиентов через дополнительные этапы проверки при совершении определенных покупок в Интернете. [Название эмитента] позволяет покупателям пропустить их в некоторых интернет-магазинах без ущерба для безопасности.
10	Зачем нужна информационная этикетка	Отобразить информационный ярлык «Почему» как графический элемент управления, который можно развернуть. Отображаемое имя для этого поля должно быть «Нужна помощь?».
11	Почему информационный текст	Отображать информационный текст «Почему» только тогда, когда пользователь выбирает «Нужна помощь? Этикетка». Текст, предоставленный эмитентом для отображения держателю карты, чтобы объяснить, почему держателя карты просят выполнить задачу аутентификации.

Приведенные выше рекомендации демонстрируют поток доверенных получателей, использующий вызов одноразового пароля (OTP).Эмитенты могут использовать любой из типов вызовов EMV 3DS (внеполосный, основанный на знаниях и т. Д.) Для аутентификации держателя карты для случая использования доверенного получателя.

Информационный текст держателя карты

Текстовое поле информации о держателе карты — это текст, предоставляемый ACS / эмитентом в ответе на аутентификацию продавцу во время беспрепятственной или несвязанной транзакции. Это поле является необязательным для заполнения ACS / Issuers, если только транзакция не использует независимую аутентификацию. Для Продавцов это необязательно для отображения в EMV 3DS 2.1, но обязательно для Продавцов для отображения в EMV 3DS 2.2. Независимо от используемой версии EMV 3DS, после заполнения Продавцам настоятельно рекомендуется отображать эту информацию держателям карт, чтобы повысить удобство использования EMV 3DS.

Текст информации о держателе карты полезен всякий раз, когда эмитент хочет призвать держателя карты к действию, чтобы улучшить его аутентификацию. Например, эмитент может предложить держателю карты загрузить его мобильное банковское приложение, чтобы в следующий раз совершать покупки в Интернете для более удобной аутентификации или для передачи важной информации держателю карты. E.г. Обратитесь в свой банк.

Продавцы получают выгоду от отображения текста информации о держателе карты для держателей карт, позволяя держателям карт выполнять необходимые шаги, чтобы получить лучший опыт работы с EMV 3DS и, следовательно, лучший опыт покупок. Продавцам рекомендуется отображать текст информации о держателях карты для держателей карт на странице оформления заказа. Приведенные ниже инструкции, проверенные пользователями, показывают продавцам, как правильно отображать текст информации о держателе карты для держателя карты.

Успешная аутентификация

Эмитенты могут захотеть, чтобы их держатели карт выполнили дополнительный шаг (т.д., загрузите приложение мобильного банкинга), чтобы улучшить работу пользователей с EMV 3DS 2.2 после успешной аутентификации. Продавцам рекомендуется показывать текст информации о держателе карты на экране «Подтверждение заказа», чтобы держатели карт могли выполнить призыв к действию эмитента и улучшить взаимодействие с пользователем EMV 3DS при следующих покупках в Интернете.

Рекомендуется, чтобы текст информации о держателе карты был отформатирован в стиле страницы оформления заказа продавца.Текст с информацией о держателе карты должен быть виден на экране подтверждения заказа продавца, чтобы держатели карт могли отреагировать на призыв к действию.

Ошибка аутентификации

В случае неудачной аутентификации эмитенты могут захотеть, чтобы держатели карт выполнили шаги аутентификации за пределами потока EMV 3DS 2.1 и 2.2, чтобы их владелец карты мог пройти аутентификацию через EMV 3DS для своей следующей покупки. Продавцам рекомендуется показывать текст информации о держателе карты, чтобы и продавец, и держатель карты могли пользоваться преимуществами EMV 3DS.

Если продавец отправляет запрос авторизации ECI 07 (электронная торговля без аутентификации) из-за неудачной аутентификации EMV 3DS, продавцу рекомендуется отображать текст информации о держателе карты для держателя карты на экране «Подтверждение заказа».

Если продавец не выполняет авторизацию и транзакция завершается, рекомендуется отображать текст информации о держателе карты на странице оформления заказа продавца.Таким образом, если владелец карты последует призыву к действию, он сможет вернуться и завершить покупку.

Программа Visa Secure и руководство по внедрению

Посетите Visa Online по адресу https://secure.visaonline.com/, войдите в систему и выполните поиск по «Visa Secure» для получения соответствующих руководств по программе и внедрению. Если у вас нет учетных данных для входа в Visa Online, обратитесь к своему эмитенту или эквайеру.

Заявление об отказе от ответственности

Важная информация об авторских правах и отказе от ответственности

© 2021 Visa.Все права защищены

Уведомление: товарные знаки, логотипы, торговые наименования и знаки обслуживания, зарегистрированные или незарегистрированные (совместно именуемые «Товарные знаки»), являются товарными знаками, принадлежащими Visa. Все другие товарные знаки, не относящиеся к Visa, являются собственностью соответствующих владельцев, используются только в целях идентификации и не подразумевают одобрения продукта или аффилированности с Visa.

Примечание. Этот документ не является частью Основных правил Visa и Правил продуктов и услуг Visa. В случае любого противоречия между любым содержанием в этом документе, любым документом, на который есть ссылка в нем, любыми экспонатами к этому документу или любыми сообщениями, касающимися этого документа, и любым содержанием Основных правил Visa, Правил продуктов и услуг Visa, Основных правил Visa и Правила продуктов и услуг Visa регулируют и контролируют.

Примечание: обратите внимание, что экраны предназначены только для иллюстративных целей.

Отказ от ответственности: ДАННЫЙ ДОКУМЕНТ ПРЕДОСТАВЛЯЕТСЯ НА «КАК ЕСТЬ», «ГДЕ ЕСТЬ», «СО ВСЕМИ ОШИБКАМИ», ИЗВЕСТНЫХ И НЕИЗВЕСТНЫХ. В МАКСИМАЛЬНОЙ СТЕПЕНИ, РАЗРЕШЕННОЙ ПРИМЕНИМЫМ ЗАКОНОДАТЕЛЬСТВОМ, ВИЗА ЯВНО ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ. ЛИЦЕНЗИОННЫЕ РАБОТЫ И НАЗВАНИЯ, ВКЛЮЧАЯ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ, ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ И НЕ НАРУШЕНИЯ ПРАВ ТРЕТЬИХ ЛИЦ НА ИНТЕЛЛЕКТУАЛЬНУЮ СОБСТВЕННОСТЬ.

Cardinal Consumer Authentication с использованием 3-D Secure 2.0

3-D Secure — это набор протоколов, который позволяет банкам-эмитентам карты подтверждать, что держатели карт являются теми, кем они себя называют, чтобы уменьшить количество случаев мошенничества при транзакциях «карта без предъявления».

Каждая сеть карт (Visa, Mastercard, American Express и Discover) имеет свою собственную версию 3-D Secure.

EMV® 3-D Secure уже здесь!

EMV® 3-D Secure (ранее известный как 3-D Secure 2.0) рассматривает изменения в отрасли за последние 15+ лет. Улучшения в 3DS включают:

• фокусировка на улучшении потребительского опыта
• использование расширенных данных для аутентификации большинства транзакций за кулисами
• включение аутентификации на любом устройстве (например, смартфонах, планшетах и ​​устройствах Интернета вещей)

Карточные сети и некоторые сторонние отраслевые поставщики (например, Cardinal) были сертифицированы EMVCo для предложения EMV 3DS продавцам и эмитентам через их сервер 3DS, SDK (iOS и Android) и ACS.Cardinal — один из немногих глобальных провайдеров, сертифицированных для всех четырех платформ.

Продавцы могут настраивать правила:

• Обязательные и необязательные поля данных могут использоваться для настройки правил продавца
• Продавцы могут передавать от потребителя дополнительные поля данных, которые могут стать правилом транзакции, например: цена товара, конкретный SKU или место доставки.

Продавцы извлекают выгоду из Cardinal Consumer Authentication разными способами:

Использование данных Сбор данных в реальном времени Проверка данных по протоколу Отчетность и аналитика Обнаружение BIN	Контроль рисков Управление правилами продавца Удобство для потребителей Больше подтвержденных заказов Поддержка региональных мандатов / требований
Гибкость Маршрутизация протокола между 1.0 и 2,0 Теперь можно использовать 2.0 Взаимодействие для пилотов с сетями, эмитентами и торговцами предварительная сертификация	Производительность Повышенная скорость аутентификации BIN Intelligence & Monitoring Авторизация после запуска и анализ мошенничества Сокращение ложных падений

Как работает аутентификация 3-D Secure

Эмитент сотрудничает с продавцом для аутентификации личности держателя карты до того, как произойдет авторизация.Работая за кулисами, он оценивает относительный риск каждой транзакции на основе обмена надежными данными между продавцом, эмитентом и Visa.

CCA поддерживает 3DS 1.0 и EMV® 3DS


Сбор кардинальных данных обеспечивает аутентификацию на основе рисков с использованием расширенных данных для принятия решений о рисках

• Информация о транзакции и странице оформления заказа
• Аутентификационная информация
• Информация о предварительной аутентификации
• Информация о рисках для продавцов
• Информация о счете держателя карты
• Информация об устройстве
• Дополнительная информация об устройстве (прямо из браузера)

EMV® — зарегистрированная торговая марка в США.S. и другие страны, а также незарегистрированный товарный знак в другом месте. Торговая марка EMV принадлежит EMVCo, LLC.

3DS Authentication · Документация

Важная информация

• Пожалуйста, свяжитесь с нами по адресу [email protected] для получения дополнительной информации о включении этой службы для вашей учетной записи.

• Служба аутентификации 3D Secure не поддерживается для использования продавцами, интегрирующимися через партнеров, подключающихся к PayU от их имени.

PaymentsOS предоставляет службу аутентификации 3D Secure, которая обрабатывает весь процесс аутентификации 3D Secure, с поддержкой как 3D Secure версии 1, так и версии 2. Вы можете использовать службу аутентификации двумя способами, в зависимости от того, как вы интегрировались с PaymentsOS:

Поддерживаемые схемы

Служба аутентификации 3D Secure может использоваться только для транзакций Visa и Mastercard.

Включение службы аутентификации 3D Secure

Прежде чем вы сможете использовать службу аутентификации 3D Secure, она должна быть активирована в вашей учетной записи PaymentsOS и для каждого бизнес-подразделения, обрабатывающего транзакции 3D Secure.Вы должны отправить запрос в нашу службу поддержки, чтобы включить службу в вашей учетной записи. После того, как служба была включена в вашей учетной записи, вы можете включить службу для каждого бизнес-подразделения по вашему выбору, вызвав запрос «Обновить функцию по учетной записи и бизнес-подразделению».

Использование службы аутентификации 3D Secure как часть платежных потоков, обрабатываемых PaymentsOS

При использовании службы аутентификации 3D Secure необходимо помнить о некоторых важных деталях. Во-первых, вы должны убедиться, что выполняете все условия для использования службы.Когда они будут созданы, вам следует ознакомиться со спецификой запроса Create Authentication и понять, как обрабатывать его ответ. Мы рассмотрим эти темы в следующих темах, так что давайте прямо сейчас.

Предварительные требования

Перед внедрением службы аутентификации 3D Secure убедитесь, что выполнены следующие предварительные условия:

• Ваш банк-эквайер для аутентификации должен быть зарегистрирован в схемах карт.

• Зарегистрируйте свое торговое имя во всех эквайерах, которые вы будете использовать.Обязательно зарегистрируйте с тем же именем у каждого эквайера. Также убедитесь, что ваши эквайеры зарегистрировали ваше имя продавца в карточных схемах.

• Эквайеры, у которых вы собираетесь пройти аутентификацию, должны быть зарегистрированы у провайдера 3DS MPI.

За дополнительной информацией обращайтесь к вашим эквайерам.

Обзор процесса аутентификации

Процесс аутентификации при использовании службы аутентификации 3D Secure довольно прост: вы сначала создаете платеж (здесь ничего нового), а затем вызываете запрос Create Authentication, чтобы инициировать поток аутентификации 3D Secure.Если ответ на запрос указывает, что клиента не нужно перенаправлять на возможный этап аутентификации 3D Secure, вы можете просто перейти к авторизации транзакции. Однако, если требуется этап аутентификации 3D Secure, вам нужно будет перенаправить клиента на URL-адрес аутентификации. Этот URL-адрес используется PaymentsOS для обработки оставшейся части процесса аутентификации за вас.

На следующем изображении показан процесс аутентификации.

Фиолетовые числа на изображении выше указывают на шаг, требующий дополнительной настройки от вашего имени:

• Шаг 2. При вызове Create Authentication API передайте merchant_site_url .Это URL-адрес, на который клиенты будут перенаправлены после завершения процесса аутентификации.

• Шаги 4 и 5: при получении ответа от API создания аутентификации перенаправьте своих клиентов на URL-адрес аутентификации для выполнения любых действий, которые могут потребоваться (если аутентификация проходит без проблем, никаких действий не требуется). Мы предоставляем вам URL-адрес аутентификации в объекте Redirection данных ответа аутентификации.

• Шаг 7: PaymentsOS расширит merchant_site_url следующими параметрами: payment_id , authentication_id и статусом аутентификации .Вы можете использовать эти параметры, чтобы предоставить клиентам дополнительную информацию об аутентификации. Вот пример дополнительных параметров, добавленных к merchant_site_url (обратите внимание, что статус аутентификации все еще может быть Pending , когда мы перенаправляем вашего клиента обратно на ваш сайт):

    
    ? payment_id = dd1fbe34-4636-4a61-8cb1-27ac8a175284
    & authentication_id = aec1c306-e0f7-452b-8fb5-5b34489e9d10
    & status = Ожидается
    

• Шаг 8: Если требуемое действие было выполнено успешно, аутентификация перейдет в состояние Успешно, (или, как вариант, на Неудачно , если действие не удалось).В тестовой или реальной среде PaymentsOS убедитесь, что вы настроили конечную точку веб-перехватчика, на которую PaymentsOS будет отправлять уведомление об изменении статуса аутентификации. Узнайте больше о Webhooks для получения дополнительной информации.

• Шаг 9: Приступите к авторизации транзакции.

Вызов запроса аутентификации 3D Secure

Теперь, когда у вас есть общее представление о процессе аутентификации, давайте продолжим и рассмотрим тело запроса 3D Secure Authentication.В частности, мы рассмотрим, как:

• Передайте информацию об эквайере и продавце (это обязательно).

• Исключите ненужные поля из данных ответа, получив только частичные результаты аутентификации 3D Secure (это необязательно, но рекомендуется).

• В частности, запросить выполнение шага аутентификации 3D Secure (это необязательно).

Рекомендуемые поля

Существует ряд полей, которые являются необязательными в потоке аутентификации 3D secure 2 (ваш запрос не будет отклонен, если не будет предоставлен), но их следует передать, чтобы увеличить количество одобрений.Это следующие поля:

• Все поля информации браузера, переданные в объекте authentication_attributes тела запроса аутентификации 3D Secure.
• Все поля номера телефона (домашний, рабочий и мобильный), переданные в объекте authentication_attributes тела запроса аутентификации 3D Secure.
• Поле address_match , переданное в объекте authentication_attributes тела запроса аутентификации 3D Secure.
• Поля адреса доставки и выставления счета, переданные в теле запроса на создание платежа.

Передача информации об эквайере и продавце

При использовании службы аутентификации 3D Secure необходимо специально указать имя эквайера, который будет обрабатывать запрос аутентификации 3D Secure. Вы делаете это, передавая информацию эквайера в объект authentication_attributes.acquirer запроса Create Authentication. Кроме того, не забудьте передать всю соответствующую информацию о продавце в authentication_attributes.купец объект. Обратите внимание, что authentication_attributes.merchant.merchant_name должно быть названием вашей компании, зарегистрированным у вашего эквайера (ов).

  {
  ...
  "authentication_attributes": {
    ...
    "покупатель": {
      "Acquirer_bin": "1482822",
      "Acquirer_merchant_id": "272871818AZz4422",
      "Acquirer_country_code": "США"
    },
    "торговец": {
      «mcc»: ​​«8999»,
      "merchant_name": "Seohs Atlovart Nhoj",
      "merchant_country_code": "США"
    }
  }
  ...
}
  

Имейте в виду, что переданная выше информация будет использоваться только в процессе аутентификации 3D Secure 2.

Использование одного эквайера для аутентификации и авторизации транзакции

Вы должны использовать того же эквайера для авторизации транзакции после завершения этапа аутентификации 3D secure.

Банки-эмитенты могут отклонить транзакции, если существует несоответствие данных эквайера между запросами аутентификации и авторизации.Вот почему вы должны указать, что один и тот же эквайер используется для аутентификации клиента и авторизации транзакции. Если вы не уверены в передаваемой информации, попросите своего провайдера предоставить все необходимые данные эквайера.

Конечно, простая передача информации об эквайере, которая будет использоваться, не гарантирует, что транзакция действительно направлена ​​поставщику, чей эквайер будет использоваться. Чтобы это было гарантировано, вам необходимо настроить правило бизнес-маршрутизации.Дополнительные сведения см. В разделе «Маршрутизация транзакций к поставщику, который использует определенного покупателя».

Получение результатов частичной аутентификации 3D Secure

В теле запроса на создание аутентификации есть поле с именем return_partial_result . Это поле дает указание API аутентификации либо вернуть полный набор результатов в теле ответа, либо исключить поля, к которым вам не обязательно иметь доступ при использовании службы аутентификации 3D Secure как части ваших потоков PaymentsOS.По умолчанию возвращаются все поля, поэтому вы должны передать return_partial_result со значением true :

  {
  "способ оплаты": {
    ...
  },
  "merchant_site_url": "http://myurl.com",
  "дополнительные детали": {},
  "cof_transaction_indicators": {
    ...
  },
  "return_partial_result": истина,
  "authentication_attributes": {
    ...
  }
}
  

Какие поля исключены из данных ответа?

При передаче поля return_partial_result со значением true следующие поля исключаются из данных ответа: cavv , ds_xid , xid и three_d_secure_server_transaction.PaymentsOS обработает эти поля «под капотом» в последующем запросе на создание авторизации (на основе идентификатора аутентификации).

Конечно, вы все равно можете выбрать возврат этих полей, передав поле return_partial_result со значением false или опуская все поле return_partial_result . Учтите, что возврат всех полей может повлечь дополнительные расходы.

, конкретный запрос на выполнение аутентификации 3D Secure. Этап

Вы также должны знать, что эмитенты могут принять решение освободить клиента от аутентификации 3D Secure.Однако есть случаи, когда вы хотите специально запросить выполнение шага аутентификации 3D Secure. Вы можете сделать это, передав поле authentication_attributes.challenge_indicator со значением 03 (запрос запрошен (предпочтение запрашивающей стороны 3DS)) или 04 (запрос запрошен (мандат)).

  {
  "способ оплаты": {
    ...
  },
  "merchant_site_url": "http://myurl.com",
  "дополнительные детали": {},
  "cof_transaction_indicators": {
    ...
  },
  "return_partial_result": истина,
  "authentication_attributes": {
    "challenge_indicator": "04",
    ...
  }
}
  

Обработка ответа аутентификации 3D Secure

Когда все данные запроса на месте, перейдем к ответу аутентификации. После вызова запроса Create Authentication следите за данными, возвращаемыми в поле provider_data.response_code , поскольку код ответа определяет ваши следующие шаги:

• ТРЕБУЕТСЯ ВЫЗОВ : клиент должен выполнить этап аутентификации 3D Secure.Перенаправьте клиента на URL-адрес, возвращенный в поле redirection.url (вы можете попробовать показать целевую страницу в iFrame, если redirection.iframe_allowed вернул true ). Затем за вас обрабатывается оставшаяся часть потока 3D Secure (включая перенаправление на URL-адрес запроса, если он определен эмитентом). После того, как клиент завершил этап аутентификации и получил result.status стал Succeed , переходите к авторизации транзакции.

• NOT_REQUIRED : аутентификация 3D Secure не требуется, как в случае транзакции, инициированной продавцом (MIT), или платежа, инициированного посредством почтового перевода / заказа по телефону (moto).В этом случае переходите к авторизации транзакции. Примечание : убедитесь, что при отправке транзакции согласия (это транзакция, предшествующая транзакции MIT), вы передаете challenge_indicator со значением 04 , чтобы гарантировать, что транзакция согласия была аутентифицирована с использованием Strong Проверка подлинности клиента.

• AUTHORIZATION_FIRST : указывает, что этап аутентификации 3D Secure может не потребоваться, поэтому вы можете сначала попытаться авторизовать транзакцию.Прежде чем продолжить, найдите значение в поле provider_data.three_d_secure_proposed_exemption , поскольку оно может вам понадобиться при вызове запроса на создание авторизации. Для получения дополнительной информации о реализации запроса авторизации см. Авторизация транзакции ниже.

• ГОТОВО . Шаг аутентификации 3D Secure был завершен. Приступите к авторизации транзакции.

Временные рамки для авторизации транзакции

Авторизация платежа на основе результатов шага аутентификации 3D Secure должна выполняться в пределах временного интервала, определенного различными схемами карт.

Понимание статуса результата аутентификации

Ответ аутентификации возвращает два статуса результата:

• provider_data.three_d_secure_authentication_status : показывает состояние процесса аутентификации, возвращенное поставщиком, обрабатывающим запрос аутентификации 3D Secure.

• result.status : показать состояние запроса аутентификации, который вы вызвали. Это значение вычисляется PaymentsOS на основе provider_data.three_d_secure_authentication_status и provider_data.response_code . Статус Succeed возвращается, если в ответе провайдера указано, что этап аутентификации был успешно завершен, или если аутентификация 3D Secure не требуется. Статус будет Ожидание , если provider_data.response_code CHALLENGE_REQUIRED , и Failed , если шаг аутентификации 3D Secure вернул ошибку. Вы можете настроить уведомление веб-перехватчика, чтобы получать уведомление в момент получения результата .статус изменений.

Примечание

Если result.status остается Pending более 15 минут, он автоматически переходит в статус Cancelled . Это может произойти, например, если пользователь закрывает окно браузера на этапе аутентификации 3D Secure.

Авторизация транзакции

Следующим шагом после вызова запроса аутентификации 3D Secure является вызов запроса на создание авторизации.Убедитесь, что оба запроса вызываются с использованием одного и того же идентификатора платежа. Также передайте three_d_secure_attributes.external.authentication_id (вы получите этот идентификатор в поле id данных ответа на запрос аутентификации).

  {
  ...
  "three_d_secure_attributes": {
  "внешний": {
    "authentication_id": "aec1c306-e0f7-452b-8fb5-5b34489e9d10"
  }
},
...
  

Напомним, что provider_data.response_code , полученный в данных ответа на запрос аутентификации 3D Secure, мог быть AUTHORIZATION_FIRST .Если вы попытаетесь авторизовать транзакцию после получения этого кода ответа, примите во внимание следующее:

• В запросе на создание авторизации передайте значение three_d_secure_attributes.sca_exemptions.exemption_reason , которое соответствует значению, полученному в поле provider_data.three_d_secure_proposed_exemption , полученном в ответе на запрос Create Authentication (используйте three_d_secure_attributes.sca_exemptions.exemption_reason поддерживается поставщиками, с которыми вы совершаете транзакции).

• Если вы получили мягкий отказ, вы должны вызвать запрос Create Authentication еще раз и передать поле authentication_attributes.challenge_indicator со значением 04 (запрос запрошен (мандат)). Обратите внимание, что причина отклонения авторизации возвращается в поле result.category .

Использование службы аутентификации 3D Secure только для аутентификации

При желании вы можете использовать службу аутентификации 3D Secure только для аутентификации.Для этого вы сначала создаете платеж (здесь ничего нового). Затем вызовите запрос Create Authentication и либо опустите поле return_partial_result , либо передайте его со значением false .

  {
  "способ оплаты": {
    ...
  },
  "merchant_site_url": "http://myurl.com",
  "дополнительные детали": {},
  "cof_transaction_indicators": {
    ...
  },
  "return_partial_result": ложь,
  "authentication_attributes": {
    ...
  }
}
  

Примечания:

• Помните, что получение результатов полного 3D Secure может повлечь дополнительные расходы.
• Обязательно указывайте ту же сумму платежа в любом последующем запросе авторизации.

Затем данные ответа будут включать поля cavv , ds_xid , xid и three_d_secure_server_transaction_id для использования в вашей собственной логике потока платежей. Если вы реализовали свои платежные потоки в PaymentsOS, вы можете передать three_d_secure_attributes.external.authentication_id в запросе на создание авторизации, и в этом случае вам не нужно передавать cavv , ds_xid , xid и serid_transaction_ Также полей.

3D Secure Authentication (3DS) | Совет по торговым рискам

---

, Парул Шарма, старший директор LexisNexis Risk Solutions

Максимизация защиты и конверсии в это беспрецедентное время неопределенности

Согласно Due Inc. 1 , прогнозировалось, что к 2020 году объем продаж электронной коммерции достигнет 632 миллиардов долларов, что повысит стимулы интернет-мошенников к инновациям своей тактики. 1 Поскольку люди продолжают оставаться дома и больше совершать операции на цифровом уровне во время блокировки, мы ожидаем, что прогнозируемые цифры будут и дальше увеличиваться.

Логично ожидать появления новых цифровых идентификаторов, а также увеличения объема транзакций для существующих цифровых идентификаторов. Это создает больше возможностей для мошенников влиться в новые тенденции. Если не будут приняты дополнительные меры, прогнозируется, что к 2020 году убытки от мошенничества со стороны CNP со стороны банков и других продавцов в Соединенных Штатах могут составить более 12 миллиардов долларов. 2

Эти числа выше указывают на необходимость обеспечения безопасных транзакций и сдерживания мошенников. В этой статье мы узнаем больше о рабочих процессах, основанных на оценке риска, с использованием или без использования 3DS.

Что такое 3DS?

3DS или 3D-Secure - это безопасный протокол, разработанный для обеспечения повышенной безопасности и более строгой аутентификации для клиентов, когда они используют свои дебетовые или кредитные карты для покупок в Интернете.

Преимущества для продавцов включают снижение риска мошенничества и перенос ответственности за мошенничество с продавца на эмитента.Версия 1 протокола 3DS была разработана в 1999 году, и по мере развития технологий недостатки протокола стали очевидны. 3DS 2.x был разработан для устранения недостатков 1.x и содержит разработки, которые включают дополнительные контекстуализированные данные (более 100 полей), которые могут быть предоставлены продавцом эмитенту, согласованность в способе представления экранов аутентификации покупателю, удобные для мобильных устройств варианты, а также возможность для специализированных сторонних поставщиков устройств и поставщиков цифровых идентификационных данных обогатить процесс принятия решений о рисках - лучше выявлять верных, вернувшихся клиентов, обеспечивая при этом улучшенную защиту от мошенничества.

Соответствует ли 3DS SCA?

PSD2 требует соблюдения принципов строгой аутентификации клиентов. PSD2 еще не применяется, но когда-нибудь будет, и мы должны быть готовы.

Для успешной транзакции требуется сочетание минимум двух из следующих факторов аутентификации:

• Что-то, что знает клиент: OTP (одноразовый пароль), SMS-код, PIN-код, пароль, секретный вопрос и т. Д.
• Что-то, что принадлежит клиенту: мобильное устройство, носимое устройство и т. Д.
• Что-то, что является клиентом: биометрические данные, такие как отпечаток пальца, сканирование радужной оболочки глаза, распознавание лица или голоса.

При этом 3DS предоставляет механизм для SCA, который должен выполняться во время платежного процесса электронной коммерции - сама аутентификация не через 3DS, но ее взаимодействие в процессе оплаты позволяет выполнять действия аутентификации.

Как выглядит клиентский опыт с поддержкой 3DS?

Риск транзакции оценивается поставщиком услуг 3D Secure эмитента кредитной или дебетовой карты.3DS используется для аутентификации события онлайн-платежа. Если транзакция определяется как высокорисковая, транзакция проходит проверку или отклоняется.

Другими словами, он предлагает держателю карты подтвердить свою личность, используя один из трех факторов аутентификации, выбранных поставщиком 3DS. Если транзакция считается малорисковой, никаких дальнейших действий со стороны держателя карты не требуется. После аутентификации транзакция отправляется для окончательной авторизации и утверждения.

Есть ли у продавцов выбор в США?

Торговцы борются между трением и конверсией, и поскольку 3DS действительно создает некоторое трение, некоторые торговцы не предпочитают протокол безопасности 3DS.

Если они не используют 3DS, они берут на себя ответственность и контролируют уровень риска, который они готовы принять, в соответствии с риском продавца и аппетитом потребителей. Если они решат внедрить 3DS, ответственность за мошенничество перекладывается с продавцов на эмитентов карт, но они несут расходы в результате проталкивания транзакций через 3DS. Да, они платят за такой уровень безопасности, но они также знают, что не будут нести никаких потерь от мошенничества или дополнительных эксплуатационных расходов для управления возвратными платежами.Это также означает, что торговцы будут оставлять деньги на столе и больше не будут контролировать уровень риска, который они готовы взять на себя.

Как продавцы обеспечивают эффективный баланс между мошенничеством, трением и аутентификацией клиентов?

Независимо от того, внедряют ли продавцы 3DS или нет, для них важно оценить рабочие процессы, основанные на оценке рисков, по этим двум причинам:

1. Если продавец поддерживает 3DS, на онлайн-мероприятии проводится оценка рисков, и 3DS позволяет продавцам и эмитенты карт должны принять информированное решение о рисках
2. Если продавец не поддерживает 3DS, ему нужны рабочие процессы, основанные на оценке рисков, еще больше, чтобы снизить потери от мошенничества и операционные расходы

Что следует искать в стороннем решении при оценке рабочих процессов?
Идея использования стороннего решения заключается в снижении ответственности, такой как убытки от мошенничества и операционные убытки.Продавцам следует обратить внимание на следующие характеристики в решении:

• Атрибуты, связанные с устройством и цифровой идентификацией : Применяется ли продавцом напрямую в рамках их собственной оценки рисков или через 3DS как часть эмитента карты, устройства оценки рисков и Анализ цифровой идентичности может предоставить совершенно новый набор данных о компонентах.
• Принятие решений : Продавцы должны использовать подробную и обширную информацию для оценки риска - будь то вся информация, которой располагает продавец (включая такие данные, как адрес доставки, активность веб-страницы и т. Д.) или расширенный объем данных, передаваемых эмитенту карты через 3DS. Для получения дополнительной информации продавцы могут подняться еще на один уровень и использовать данные своих коллег, используя существующие консорциумы.

  Когда дело доходит до принятия решений, важнее всего скорость и точность. Использование большего количества данных, как упомянуто выше, может повысить точность. Чтобы обеспечить скорость, продавцы могут использовать модели машинного обучения, возможности пассивной аутентификации, такие как поведенческая биометрия, и флагманские модели.

• Простота развертывания : возможность развертывания нескольких типов клиентских циклов на основе оценки риска может создать дополнительный уровень защиты от мошенничества.Это также обеспечит направление пользователя по соответствующему пути на основе этого результата и позволит продавцам и / или эмитентам карт найти эффективный баланс между мошенничеством и трениями.

Подводя итог, можно сказать, что рабочие процессы, основанные на рисках, могут повысить ценность аутентификации как на основе 3DS, так и без нее. Для аутентификации 3DS подход, основанный на оценке риска, поможет продавцам завоевать доверие эмитентов кредитных и дебетовых карт. Если эмитент доверяет рабочим процессам, реализованным продавцом, он будет менее консервативным и будет принимать больше транзакций.Для аутентификации, не основанной на 3DS, рабочие процессы, основанные на оценке риска, становятся еще более важными, потому что это может помочь продавцам максимизировать защиту и конверсию.

1 Due Inc .: https://due.com/blog/addressing-rising-payment-fraud-rates-us/

2 Forbes: https://www.forbes.com / sites / rogeraitken / 2016/10/26 / us-card-fraud-loss-might-превосходит-12 млрд-к-2020/

PSD2 и надежная проверка подлинности клиентов

Обзор SCA

Надежная аутентификация клиентов (SCA) - это регулирование безопасности платежей, разработанное Европейским банковским управлением (EBA), чтобы гарантировать, что многофакторная аутентификация выполняется для платежей по картам.EBA сделало обязательным внедрение SCA в рамках инициативы пересмотренной Директивы о платежных услугах (PSD2). Это относится ко всем онлайн-транзакциям, в которых платежный процессор и банк-эмитент карты находятся в Европейской экономической зоне (ЕЭЗ). Поправка должна была вступить в силу с 14 сентября 2019 года, но Европейские банковские органы (в октябре 2019 года) продлили полное исполнение до 31 декабря 2020 года .

Однако, если ваш бизнес находится за пределами Европы или имеет значительную клиентскую базу в ЕЭЗ, рекомендуется соответствовать требованиям SCA.3DS 2.0 будет вашим лучшим вариантом для соблюдения правил SCA.

Важное обновление :

Применение PSD2 было отложено некоторыми странами ЕЭЗ , чтобы дать время для принятия SCA, после оценки сложностей, связанных с внедрением SCA. Страны, объявившие об отсрочке исполнения, - Великобритания, Германия, Франция, Нидерланды, Бельгия, Австрия, Ирландия, Италия, Греция, Польша, Мальта, Люксембург, Норвегия, Швеция и Дания. Мы будем обновлять этот список на основе решения, принятого другими странами ЕЭЗ.

3-D Secure :

3-D Secure (3DS) - это дополнительный протокол аутентификации, реализуемый сетями карт для защиты транзакций с помощью карт в Интернете. 3DS 2.0 авторизует оплату картой, собирая проверяемую пользователем информацию с помощью окна аутентификации. Его предшественник (3DS 1.0) не получил широкого распространения из-за отсутствия поддержки мобильных устройств и неудовлетворительного взаимодействия с пользователем, что привело к низкому уровню одобрения транзакций.

3DS 2.0 улучшил свою предшественницу (3DS 1.0), делая аутентификацию более гибкой и безопасной, удобной для мобильных устройств и улучшая взаимодействие с пользователем. Банки-эмитенты, которые не поддерживают 3DS 2.0, по-прежнему будут способствовать выполнению пользователем аутентификации через 3DS 1.0, которая перенаправляет пользователя в новое окно для сбора пароля или OTP.

Список шлюзов, поддерживаемых в Chargebee для 3DS :

1. Полоса
2. Брейнтри
3. Адиен
4. Checkout.com
5. Cybersource (Работа в процессе)
6. PayPal Express Checkout

Список шлюзов, не поддерживаемых в Chargebee для 3DS :

1. Авторизоваться.нетто
2. Штифт
3. eWay Rapid
4. Sage Pay
5. Ingenico ePayments
6. Карточка
7. Paymill
8. НМИ
9. Moneris
10. Орбитальная (Chase Paymentech)
11. Bluepay
12. Бамбора
13. Вантив
14. Worldpay
15. Bluesnap (оценка в процессе)
16. PayPal Pro

Примечание

Если на вас влияет PSD2, и вы использовали какой-либо из неподдерживаемых шлюзов, свяжитесь с [адрес электронной почты защищен], и мы поможем вам перейти на один из шлюзов, поддерживаемых 3DS.

Рабочие процессы 3DS

Поток без трения

Фоновые данные вашего клиента, такие как отпечаток пальца устройства, IP-адрес и т. Д., Легко собираются во время оформления заказа и отправляются в банк-эмитент, чтобы проверить, требуется ли проверка. Если банк-эмитент может аутентифицировать клиента на основе предоставленных исходных данных, дополнительная проверка будет исключена для клиента, и транзакция будет проходить в обычном режиме.

Поток вызова

В случае, если банк-эмитент отклоняет поток без трения и требует аутентификации, клиенту будет предложено проверить через поток запроса.Банк-эмитент теперь будет запрашивать аутентификацию с помощью 3DS 2.0.

Если поток запроса необходим и банк-эмитент не поддерживает 3DS 2.0, пользователь будет перенаправлен в новое окно проверки (3DS 1.0).

Резервный поток

Большая часть внесессионных (клиент отсутствует) платежей, таких как продления, разовые платежи, пробная подписка на активные обновления и т. Д., Являются транзакциями, инициированными продавцом (MIT), и в идеале проходят без дополнительной проверки с использованием ранее сохраненных клиентом данные.

Однако все еще существует небольшая вероятность того, что банк-эмитент может потребовать от клиента пройти аутентификацию в определенных сценариях. Поскольку пользователь не будет доступен для аутентификации, это приведет к сбою платежа. Затем клиента необходимо уведомить об ошибке платежа и подключить к сети для завершения аутентификации.

Информация

Chargebee поддерживает 3DS только с помощью шлюзов. В конечном итоге банк-эмитент должен решить, необходима ли проверка 3DS для клиента.

Контрольный список для SCA

Последовательность шагов, приведенных ниже, объясняет, что необходимо сделать в Chargebee, чтобы соответствовать требованиям SCA и не терять доход из-за спада платежей 3DS. Заполнение этого контрольного списка включает поддержку 3DS для страниц, размещенных на Chargebee (проверка в приложении, проверка на одной странице, портал) и пользователей Chargebee API.

Важно, чтобы вы выполнили все шаги, упомянутые в контрольном списке, чтобы охватить все потоки 3DS и, таким образом, позволить Chargebee позаботиться об уведомлении вашего клиента об отказе платежа и последующих действиях для восстановления платежа.

1. Включите 3D Secure на вашем шлюзе

2. Включить 3D Secure в Chargebee

3. Включить Напоминание для онлайн-платежей

4. Настроить напоминаний по электронной почте

5. Включить Причину сбоя и Pay Now в напоминаниях по электронной почте

Конфигурация: Детальная

Выполните указанные ниже действия по настройке, чтобы начать тестирование платежей через поток 3DS на вашем тестовом сайте Chargebee,

.

1.Включите 3DS на вашем шлюзе

В

Stripe по умолчанию включена 3DS для всех продавцов.

Braintree также включает 3DS по умолчанию, но только для продавцов из ЕС. Если вы работаете за пределами ЕС и используете Braintree, обратитесь в службу поддержки Braintree, чтобы включить его.

В

Adyen по умолчанию включена 3DS для разовых платежей. Обратитесь в службу поддержки Adyen, чтобы включить 3DS для регулярных платежей.

Чтобы включить 3DS для других поддерживаемых Chargebee шлюзов, обратитесь к своему шлюзу.

Убедитесь, что 3DS включен в вашей учетной записи шлюза, прежде чем включать его в Chargebee.

2. Включение 3DS в Chargebee

Вы можете переключить Включить 3D Secure в разделе «Настройки »> «Настроить Chargebee»> «Платежные шлюзы»> {используемый шлюз}> «Карты»> «Управление ». 3DS можно включить только для поддерживаемых шлюзов в Chargebee.

Вы можете включить 3DS на своем сайте Chargebee Test для всестороннего тестирования потоков 3DS. По завершении тестирования вы можете включить его на своем сайте Live и начать взимать плату с клиентов по способу 3DS.

3. Включить напоминания

Dunning гарантирует, что счета-фактуры неудавшихся платежей попадут в цикл повторных попыток (повторная попытка оплаты) и последующих действий (уведомления по электронной почте). Dunning - это основной механизм восстановления платежей в Chargebee при сбоях платежей 3DS из-за требований аутентификации. Таким образом, покупателя могут попросить подключиться к сети и выполнить аутентификацию.

Включите напоминание, чтобы гарантировать, что соответствующие клиенты будут подтверждены, когда сбой платежа 3DS происходит с их картой.

Поскольку сбой аутентификации 3DS - это серьезный отказ и требует вмешательства клиента, Chargebee не будет повторять попытки сбоя 3DS. Единственное исключение - когда вы установили индивидуальную повторную попытку в Chargebee. Поэтому для Smart retry Chargebee не будет повторять попытку, если это сбой платежа 3DS. Однако, если вы настроили индивидуальные повторные попытки, мы будем повторять попытки только в последний день периода напоминаний перед тем, как будет предпринято последнее действие.

4. Настройте напоминания по электронной почте

Настройте электронное письмо с напоминанием о напоминании «При сбое первого платежа», чтобы его можно было отправлять, как только транзакция не удалась из-за требования аутентификации 3DS.Кроме того, вы можете настроить больше писем с напоминаниями и установить частоту их отправки, чтобы напоминать клиентам об ошибке платежа. Электронные письма с напоминаниями для 3DS не имеют отдельного шаблона и будут заменять обычные электронные письма с напоминаниями.

Обратите внимание, что электронные письма с напоминанием будут отправляться вашим клиентам до тех пор, пока счет не будет оплачен или пока не истечет период напоминания.

5. Укажите причину сбоя и заплатите сейчас

Это важный шаг для того, чтобы сообщить вашим клиентам о сбое 3DS, чтобы они могли вернуться в сеть и пройти аутентификацию с помощью Pay Now .

При нажатии на опцию Pay Now ваши клиенты будут перенаправлены на страницу Chargebee Pay Now, на которой перечислены все их неоплаченные счета. Теперь они могут выбрать счета и щелкнуть Pay , чтобы подтвердить подлинность и завершить транзакцию.

Уведомления по электронной почте

v2 покажут флажок Причина сбоя , когда вы щелкнете по шаблону (как показано на снимке экрана ниже). Убедитесь, что он отмечен, чтобы в электронном письме при отправке была указана причина сбоя.

Уведомления по электронной почте

v1 могут быть встроены со следующими полями слияния, чтобы подтвердить заказчику сбоя 3DS, используя код причины сбоя вместе с опцией Pay Now .

Обработка резервного потока в Chargebee

Платежи вне сеанса (клиент отсутствует) являются транзакциями, инициированными продавцом, и в соответствии с правилами будут применяться соответствующие исключения. Однако, как упоминалось в резервном потоке, для небольшого процента таких внесеансовых платежей может потребоваться аутентификация 3DS, если банк-эмитент требует ее.

В таких случаях платеж не состоится. Однако в Chargebee намеченное действие все равно будет выполнено, и счет-фактура попадет в напоминание. Затем клиент будет рассылать напоминания по электронной почте в соответствии с частотой, заданной в ваших настройках напоминания, с указанием причины сбоя платежа и опции Pay Now .

Когда клиент нажимает на Pay Now , он попадает на страницу Chargebee Pay Now, чтобы выбрать счета, которые они намереваются оплатить.После выбора счетов-фактур, когда клиент нажимает на Pay , ему будет показано окно / всплывающее окно проверки 3DS, чтобы подтвердить свою личность и завершить платеж.

Интеграции и воздействия

Размещенные страницы Chargebee

Размещенные страницы Chargebee могут обрабатывать все потоки, участвующие в транзакции 3DS. Если вы используете In-app Checkout, одностраничный заказ или портал Chargebee, то включение 3DS для вашей транзакции может быть выполнено всего за несколько простых шагов, как описано в нашем контрольном списке и настройке PSD2.

Вы можете протестировать 3DS для Checkout, используя тестовые карты 3DS для шлюза Chargebee Test. Если вам нужно протестировать 3DS для шлюзов Stripe, Braintree и Adyen, вы можете протестировать их с помощью соответствующих тестовых карт 3DS.

Также убедитесь, что вы используете один из наших шлюзов, поддерживающих 3DS. Если нет, напишите нам по адресу [адрес электронной почты защищен], и мы поможем вам с переносом.

Gateway JS и API Chargebee

Если у вас есть интеграция Gateway JS + API с Chargebee, эта блок-схема объясняет, каким будет ваш новый поток:

Chargebee поддерживает 3DS для интеграции JS Stripe, Braintree и Adyen.Взгляните на наши разделы на Stripe.js, Braintree.js и Adyen.js, чтобы понять, какие изменения необходимо внести в вашу интеграцию JS. Вы можете протестировать шлюзы для потоков 3DS на своем сайте Chargebee Test, используя соответствующие тестовые карты 3DS.

Интеграция на основе API

Отправка необработанных данных карты в Chargebee через API не рекомендуется для 3DS. Внедрение 3DS для интеграции на основе API - это громоздкий процесс, который включает в себя несколько шагов с вашей стороны, это также может повлиять на скорость утверждения платежей.

Шлюзы

выполняют роль сбора справочной информации о клиенте из браузера с помощью их JS и отправки ее в банк-эмитент. Помимо передачи фоновых данных клиента банку-эмитенту, шлюзы также легко обрабатывают потоки 3DS и, следовательно, имеют более высокую скорость утверждения. Мы рекомендуем вам перейти на параметры интеграции Chargebee.js или Gateway JS + Chargebee API, которые мы поддерживаем, и настроить 3DS в Chargebee, используя эти параметры.

Для получения дополнительной информации по этому поводу, пожалуйста, свяжитесь с [электронная почта защищена].

Реализация

3DS в Chargebee с использованием шлюза JS

Stripe.js

Если у вас уже есть интеграция Chargebee - Stripe.js, вам необходимо обновить интеграцию с помощью наших обновленных API, чтобы обеспечить соответствие 3DS / SCA и избежать сбоев при оплате.

Чтобы узнать больше об интеграции Stripe Elements на кассе и тестировании потока 3DS, обратитесь к нашему руководству по интеграции Stripe.js, поддерживаемой 3DS.

Брейнтри.js

Одноразовый номер

Braintree.js, проверенный 3DS для новых и существующих сохраненных карт, может быть передан в API Chargebee для выполнения необходимых операций. Узнайте больше об обновлении API для Braintree.js в нашей документации по API.

Чтобы узнать больше об интеграции Braintree.js на странице оформления заказа и тестировании потока 3DS, обратитесь к нашему руководству по интеграции Braintree.js, поддерживаемой 3DS.

Adyen.js

Мы реализовали поддержку 3DS для последней версии Adyen.js с помощью вспомогательного модуля 3DS от Chargebee.js. Если вы используете CSE (шифрование на стороне клиента) Adyen, вам необходимо установить последнюю версию Adyen.js, чтобы воспользоваться вспомогательным JS-помощником Chargebee 3DS.

Взгляните на наше руководство по внедрению JS помощника 3DS, чтобы изменить интеграцию Adyen.js и приспособить его к 3DS.

Checkout.com js

Доступна поддержка

3DS для последней версии Checkout.com js с использованием Chargebee.js. Чтобы узнать больше об этой интеграции, взгляните на наше руководство по реализации JS помощника 3DS

.

1.Поддерживает ли Chargebee SetupIntent Stripe?

Да, SetupIntent можно использовать для авторизации транзакции 3DS для новой карты. Никакой суммы не будет, важно только то, что заказчик должен пройти верификацию.

* 2. Что произойдет с существующими картами в хранилище после 14 сентября 2019 г.? *

Карты, которые уже находятся в хранилище шлюза, в большинстве случаев не проходят проверку 3DS. Такие шлюзы, как Stripe, Braintree и Adyen, подтверждают, что они применит соответствующие исключения SCA к таким картам.

3. Что мне делать, если я столкнулся с ошибкой «Операция завершилась неудачно, поскольку страна ЕС, указанная клиентом в платежном адресе, не может быть проверена по IP-адресу или номеру BIN карты»?

Отключите проверку местоположения на тестовом сайте во время тестирования 3DS, поскольку может быть несоответствие между IP-адресом и BIN карты.

Проверить местоположение можно в разделе «Настройки »> «Настроить Chargebee»> «Налоги ». Щелкните соответствующую страну и снимите флажок Включить проверку местоположения .

4. Как отфильтровать неудачные платежи 3DS и уведомить моих клиентов об аутентификации?

Есть два способа проинструктировать клиентов об аутентификации неудачных платежей 3DS,

1. Путем отправки электронных писем с напоминанием о напоминаниях с указанием причины сбоя и опцией «Оплатить сейчас», которая, по сути, представляет собой шаги 3, 4 и 5 в контрольном списке.
2. Путем фильтрации счетов-фактур с помощью фильтра «С ожиданием аутентификации 3DS» и отправки электронной почты с массовой аутентификацией.
3. Перейдя к любому счету, столкнувшемуся с ошибкой 3DS, и используя напоминание об аутентификации Отправить , находящееся в верхней части страницы.

5. Могу ли я выполнить минимальную авторизацию 3DS, чтобы гарантировать, что будущие платежи будут проходить без вмешательства клиента?

Да, вы можете выполнить авторизацию 3DS на минимальную сумму, но только при получении новой карты для будущего платежа (без немедленной оплаты).

Использование Stripe.js:

Пользователи

Stripe могут использовать SetupIntent API для выполнения проверки карты 3DS бесплатно. Вы можете передать идентификатор SetupIntent в Chargebee payment_intent [gw_token] .Setup Intent API можно использовать только в тех случаях, когда не требуется немедленная оплата.

Braintree.js:

Пользователи

Braintree могут использовать минимальную сумму (скажем, 1 доллар) и выполнить проверку 3DS на эту сумму. После успешной проверки минимальная разрешенная сумма будет предоставлена ​​клиенту автоматически.

3DS 2.0: понимание нового подхода к аутентификации.

3D Secure (3DS) - это дополнительный уровень безопасности, обеспечиваемый American Express, Visa, Mastercard и Discover, чтобы обеспечить более надежную защиту онлайн-транзакций по дебетовым и кредитным картам.Во время первой версии этого стандарта клиенты были направлены на страницы своих банков-эмитентов, чтобы подтвердить свою личность в процессе оплаты. Совсем недавно 3DS 2.0 была дополнена до 3DS 2.2.

Несколько лет назад была развернута технология 3D Secure, призванная защитить платежную арену. Во многих отношениях это развертывание было успешным. Во-первых, компаниям был предоставлен более надежный способ проверки законности клиента. Кроме того, ответственность за любое мошенничество, имевшее место во время транзакции 3D Secure, была переложена с плеч продавца на банк клиента.При этом процесс аутентификации был неуклюжим, ложные отказы были безудержными, и у продавца не было возможности отказаться от него.

Напротив, новый протокол 3DS2 исправляет многие из этих ошибок. Доверенным потребителям не нужно проходить процесс аутентификации, он интегрируется как с мобильными приложениями, так и с браузерами, эмитенту может быть предоставлено больше точек данных, чтобы уменьшить количество ложных отказов, а продавцы могут отказаться от него при желании. Это приводит к большей гибкости, беспроблемной и безопасной обработке платежей и более счастливым клиентам.

Беспрепятственные платежи 3D Secure.

Когда консорциум из шести основных сетей кредитных карт, известный как EMVCO, выпустил свою последнюю версию 3D Secure, их намерением было усилить протоколы аутентификации и одновременно упростить процесс покупок. Как следует из названия, так называемая трехмерная безопасность без трения позволяет упростить процесс оплаты от начала до конца. Благодаря этому обновлению продавцы и их провайдеры платежей могут включать гораздо больше данных при отправке платежной транзакции в банк покупателя.Эта информация может включать в себя основную информацию, такую ​​как адрес электронной почты и адреса доставки, а также другие соответствующие контекстные факты, такие как идентификатор устройства клиента или информацию о предыдущих транзакциях. Эти данные отнюдь не тривиальны; он может использоваться банком держателя карты для определения того, является ли клиент законным и должна ли транзакция быть разрешена, или, альтернативно, требуется ли дополнительная информация для аутентификации до завершения продажи.

Доверенный клиент больше не должен запоминать ПИН-код или перенаправляться на другой сайт для аутентификации.Вместо этого они просто вводят информацию о своей кредитной карте и другие платежные данные на странице оформления заказа, где был вставлен код JavaScript. Затем конфиденциальная информация потребителя (а также его цифровой след) передается в банк-эмитент держателя карты. Пока карта подтверждена и транзакция подтверждена, она считается подтвержденной 3D Secure; в противном случае потребителю потребуется предоставить дополнительную надежную аутентификацию клиента (SCA). Эта проверка SCA должна состоять как минимум из двух из следующих трех компонентов: знания (что-то, что знает только пользователь, например ПИН-код), владение (что-то, что есть только у пользователя, например, умные часы) и принадлежность (что-то, связанное с пользователем, которое не может можно поменять, например, отпечаток пальца).Независимо от того, принимается ли SCA немедленно или клиенту необходимо пройти эти дополнительные испытания, продавец не несет ответственности за расходы в случае мошенничества.

Улучшенный пользовательский интерфейс.

К моменту появления 3DS2 мобильные технологии уже господствовали. Следовательно, этот стандарт быстро улучшил процесс проверки личности для всех соответствующих игроков в этой цифровой среде. Например, все банки предоставляют мобильные приложения, которые позволяют клиентам получать доступ к информации и услугам через свои смартфоны.Благодаря 3DS2 получение доступа к этим приложениям с помощью методов аутентификации стало проще и безопаснее. В результате потребители теперь могут подтвердить свою личность, используя биометрические данные, такие как отпечаток пальца или даже распознавание лица. Кроме того, проверка больше не включает в себя эти тревожные перенаправления на чужие страницы; весь опыт содержится в разделе оформления заказа продавца.

Эта расширенная проверка SCA принесет пользу всем. Клиенты будут приятно удивлены, увидев более быструю, менее утомительную и более безопасную обработку платежей.Между тем, продавцы будут получать меньше возвратных платежей, потому что код причины «не авторизован» больше не применяется. Благодаря протоколам 3D Secure 2 большинство платежей могут быть полностью обработаны и проверены в соответствии с требованиями SCA PSD2, без необходимости предпринимать какие-либо дополнительные действия. Их данные могут быть незаметно подтверждены эмитентом карты. В случае, если от клиента требуется дополнительная проверка, 3D Secure 2 также позволяет использовать биометрические данные и PIN-коды.

Как Inovio подходит для совков.

Хотя нет никаких сомнений в том, что соблюдение обновленных стандартов 3D Secure меняет правила игры как для покупателей, так и для продавцов, выполнение этого требования по-прежнему может быть проблемой для бизнеса. К счастью, все наши системы полностью обновлены, и наша опытная команда знающих сотрудников готова предоставить вам любую необходимую информацию и обучение. Независимо от того, где находится ваша компания или в какой отрасли вы работаете, мы можем описать все протоколы аутентификации и их исключения, чтобы гарантировать, что ваши платежные системы и процедуры полностью соответствуют 3DS 2.

No related posts.