Программное обеспечение Руководство по интеграции 3D Secure Документация

Руководство по интеграции 3D Secure

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

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

  • Вы используете форму оплаты hCO?
  • Вы используете форму оплаты hPF?
  • Вы обрабатываете платежи без использования формы, предоставленной системой Unzer?

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

Также обратите внимание:
Если вы используете регулярные платежи (платежи по подписке), обязательно ознакомьтесь с разделом «3D Secure и периодические платежи».

Процедура 3D Secure при использовании формы оформления заказа hCO

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

Для этого необходимо оценить следующие параметры.

  • ОБРАБОТКА.ВОЗВРАТ.КОД = 000.200.000
  • PROCESSING.RETURN = Транзакция + ожидание
  • ОБРАБОТКА.РЕЗУЛЬТАТ = ПОДТВЕРЖДЕНИЕ

Объяснение: Статус транзакции «ожидает», параметр PROCESSING.RESULT
представляет собой лишь предварительный результат. Пока выполняется процесс 3D Secure, статус
остаются в ожидании.

Окончательный результат транзакции - это либо

  •  ОБРАБОТКА.ВОЗВРАТ.КОД = 000.000.000
  • ОБРАБОТКА.РЕЗУЛЬТАТ = ПОДТВЕРЖДЕНИЕ
    or
  • PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 или 000.200.000
  • ОБРАБОТКА.РЕЗУЛЬТАТ = NOK

В первом случае транзакция была успешно завершена, во втором - полностью провалилась. Последнее может иметь разные причины, в том числе отказ в аутентификации. Ты сможешь
получить более подробную информацию в параметрах «PROCESSING.RETURN» и «PROCESSING.RETURN.CODE».
Мы рекомендуем вам запустить тест для обоих сообщений. Для получения дополнительной информации о том, как пройти тест и какие данные кредитной карты вы можете использовать для тестирования, см. Ниже.

Процедура 3D Secure при использовании формы оформления заказа hPF

Форма оформления заказа hPF также уже предназначена для использования процедуры 3DS. Никаких дополнительных действий с вашей стороны для выполнения процедуры не требуется. Как описано
для реализации hCO ответ платежной системы происходит в два этапа, поэтому ваша система должна проверить значение PROCESSING.RETURN.CODE
параметр при обработке ответа.

Для этого необходимо оценить следующие параметры.

  • ОБРАБОТКА.ВОЗВРАТ.КОД = 000.200.000
  • PROCESSING.RETURN = Транзакция + ожидание
  • ОБРАБОТКА.РЕЗУЛЬТАТ = ПОДТВЕРЖДЕНИЕ

Объяснение: Статус транзакции «ожидает», параметр PROCESSING.RESULT представляет только предварительный результат. Пока выполняется процесс 3D Secure, статус
остаются в ожидании.

Окончательный результат транзакции - это либо

  • ОБРАБОТКА.ВОЗВРАТ.КОД = 000.000.000
  • ОБРАБОТКА.РЕЗУЛЬТАТ = ПОДТВЕРЖДЕНИЕ
    or
  • PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 или 000.200.000
  • ОБРАБОТКА.РЕЗУЛЬТАТ = NOK

В первом случае транзакция была успешно завершена, во втором - полностью провалилась. Последнее может иметь разные причины, в том числе отказ в аутентификации. Ты сможешь
получить более подробную информацию в параметрах «PROCESSING.RETURN» и «PROCESSING.RETURN.CODE».
Мы рекомендуем вам запустить тест для обоих сообщений. Для получения дополнительной информации о том, как пройти тест и какие данные кредитной карты вы можете использовать для тестирования, см. Ниже.

Процедура 3D Secure с прямым подключением

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

Асинхронный поток транзакций:

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

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

Обратите внимание: в этом рабочем процессе ваша система получает два ответа от платежной системы:

- Один со статусом «в ожидании» (PROCESSING.RETURN.CODE = 000.200.000 и PROCESSING.RETURN = Transaction + pending) и параметрами перенаправления в банк-эмитент карты клиента.
- Один с окончательным результатом списания или резервирования. Также есть два редиректа URLs, упомянутые в этом процессе, один из платежной системы, в которую клиент должен быть перенаправлен для аутентификации в банке-эмитенте своей карты, и один из вашей системы, при получении окончательного результата, для перенаправления клиента обратно в вашу систему.

временная шкала

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

  1. Ответ URL
    При первом звонке (№2 на схеме) в платежную систему «Ответ URL»Должны быть переданы в группе внешнего интерфейса.
    графический пользовательский интерфейс, текст, приложение
    Пожалуйста, обрати внимание: Параметр IDENTIFICATION.REFERENCEID актуален только в том случае, если вы ссылаетесь на регистрацию или другую уже существующую транзакцию.
  2. Перенаправление обработки URL Если требуется аутентификация, перенаправление URL а остальные параметры в группе редиректа передаются в ответе от платежной системы (№ 5 на схеме).
    графический пользовательский интерфейс, текст
    графический пользовательский интерфейс, текст, приложение, письмо
  3. Перенаправление клиента на редирект URL
    Если группа перенаправления отвечает перенаправлением URL, браузер клиента должен быть перенаправлен на этот URL (№ 6 на схеме) для выполнения аутентификации. Дополнительные параметры из группы перенаправления должны быть переданы на внешний website как параметры POST.
    Обратите внимание: дополнительные параметры возвращаются в группе «PROCESSING.REDIRECT.xxx» только с 3D Secure Version 1 (даже там номер и название могут отличаться), тогда как с 3D Version 2 только PROCESSING.REDIRECT.URL как показано ниже, возвращается: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
    CCF / run Это означает, что независимо от типа и количества параметров браузер клиента должен перенаправить на PROCESSING.REDIRECT.URL.
    Ниже вы найдете простой код example о том, как такое перенаправление может быть выполнено. В Часть предназначена для информирования конечных клиентов, чьи системы не поддерживают Javascript или отключили его. Мы настоятельно рекомендуем выполнять перенаправление в активном окне браузера клиента, а не использовать всплывающие окна или новые окна браузера, поскольку это может
    раздражают клиентов и побуждают их закрыть страницу, на которую они перенаправлены.
    текст, письмо
  4. Асинхронная проверка результата
    Результат аутентификации асинхронно отправляется на ваш сервер. Платежная система ожидает действительного URL как ответ. (№ 12 и 13 на схеме). Для успешных или отклоненных
    платежи, разные URL здесь может ответить ваша система.
  5. Обратный путь клиента
    Платежная система перенаправляет покупателя на URL предоставляется системой продавца после завершения процесса аутентификации и платежной транзакции.
    Обратите внимание: шаги 4.) и 5.) выполняются точно так же, как вы уже знакомы с существующими транзакциями NONE 3D Secure.

3D Secure и повторяющиеся платежи

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

Для этого в банках различают

  • CIT = транзакции, инициализированные клиентом
  • MIT = транзакции, инициализированные продавцом

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

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

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

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

  • Существует как минимум одно успешное дебетование или резервирование (предварительная авторизация), которое было выполнено с помощью 3D Secure или имело место до 01.01.2021.
  • он ссылается на существующую регистрацию и дебетует при подаче

Чтобы платежная система знала, что это повторяющийся платеж, необходимо также отправить параметр RECURRENCE.MODE = REPEATED. Это сигнализирует системе, что
о повторяющихся платежах необходимо сообщать в банковские системы.

Обратите внимание: если параметр RECURRENCE.MODE = REPEATED вводится при первой загрузке новой карты, пересылка 3D Secure будет выполняться, несмотря на этот параметр.

Тестирование реализации 3D Secure

Вы можете в любой момент протестировать соединение 3D Secure через нашу платежную систему. Для этого используйте режим «CONNECTOR_TEST» для транзакции, как показано в примереamples выше.
Данные подключения для этого теста:

  БЕЗОПАСНОСТЬ.   31HA07BC8142C5A171745D00AD63D182
  ЛОГИН ПОЛЬЗОВАТЕЛЯ   31ha07bc8142c5a171744e5aef11ffd3
  ПОЛЬЗОВАТЕЛЬ.PWD   93167DE7
  ТРАНЗАКЦИЯ.КАНАЛ   31HA07BC8142C5A171749A60D979B6E4
  Валюта, настроенная для 3D версии 2   Евро, доллары США, шведские кроны
  Валюта, настроенная для 3D версии 1   Фунты стерлингов, чешские кроны, швейцарские франки

Конечная точка системного шлюза либо
Шлюз SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - в кодировке Latin-15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - в кодировке UTF-8
Шлюз NGW:
- https://test-heidelpay.hpcgw.net/ngw/post

Данные кредитной карты для этого теста:

  бренды   номера карт   CVV   Дата истечения срока действия   примечание
  МастерКард   5453010000059543   123   дата в будущем   3D - пароль: secret3
  Виза   4711100000000000   123   дата в будущем   3DS - пароль: секрет! 33

Обратите внимание: для 3D Secure версии 2 вам не нужно вводить пароль, просто нажмите на ссылку «Нажмите здесь, чтобы завершить аутентификацию.
Единственный способ имитировать ошибку с помощью 3D Secure Version 2 - дать странице со ссылкой время ожидания (около 18 минут).

 

Узнайте больше об этом руководстве и загрузите PDF-файл:

Документы/Ресурсы

Руководство по интеграции программного обеспечения 3D Secure [pdf] Документация
Unzer, Руководство по интеграции, 3D Secure

Ссылки

Оставьте комментарий

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