Перейти к основному содержимому

SDK

Для использования в вебе рекомендуемым подходом является использование Unico SDK по следующим причинам:

  • Более высокая безопасность;
  • Интегрированный процесс в рамках вашего потока;
  • Более высокая конверсия при использовании SDK;
  • Более простая реализация.
предупреждение

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

Например: реализация Unico через iFrame внутри webview, реализация iFrame с помощью HTML-тега и т. д.

Общие рекомендации​

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

Как начать​

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

опасность

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

Чтобы начать использовать SDK, необходимо начать с установки веб-SDK Unico:

npm install idpay-b2b-sdk
совет

При установке пакета Unico SDK разворачивайте его без указания конкретной версии, чтобы ваш менеджер зависимостей всегда обновлял minor- и patch-версии до последней доступной.

Чтобы посмотреть предыдущие версии, перейдите на npmjs.com/package/idpay-b2b-sdk.

Доступные методы​

init(options)​

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

Параметры:

  • options — принимает объект с настройками конфигурации:
    • type — тип потока, который будет инициализирован. В настоящее время мы предлагаем тип IFRAME. Для новых приложений мы рекомендуем использовать тип IFRAME, который делает процесс для конечного пользователя намного более плавным и с меньшим трением, поскольку позволяет избежать необходимости покидать экран оформления заказа, а сам процесс может быть предзагружен.
import { IDPaySDK } from "idpay-b2b-sdk";

IDPaySDK.init({
  type: 'IFRAME',
  env: 'uat' // Only needed for the test environment.
});

open({ transactionId, token, onFinish? })​

Этот метод открывает процесс Верификации без предъявления карты в соответствии с типом потока, выбранным ранее в функции инициализации. Для потока REDIRECT эта функция выполняет простое перенаправление на маршрут потока захвата Верификации без предъявления карты. Для потока IFRAME эта функция отображает предзагруженный iframe и запускает поток обмена сообщениями между страницей клиента и процессом Верификации без предъявления карты.

Параметры:

  • options — принимает объект с настройками конфигурации:
    • transactionId — принимает идентификатор созданной транзакции. Этот идентификатор важен для получения деталей транзакции и корректного завершения потока (его можно получить при создании транзакции через API).
    • token — принимает токен созданной транзакции. Этот токен важен для аутентификации транзакции и обеспечения того, чтобы его использовали только авторизованные домены (его можно получить при создании транзакции через API).
    • onFinish(transaction, type) (необязательно) — принимает функцию обратного вызова, которая будет выполнена по завершении потока захвата Верификации без предъявления карты, передавая два аргумента: объект транзакции ({ captureConcluded, concluded, id }) и тип ответа — FINISH для случаев, когда поток был успешно завершён, или ERROR для случаев, когда поток был прерван из-за ошибки. В случае ошибки в потоке статус транзакции не будет изменён, и обратный вызов через webhook, если он настроен, не будет выполнен.
const transactionId = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const transaction = {
  id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
  concluded: true,
  captureConcluded: true
};

const onFinish = (transaction, type) => {
  console.log('response', transaction, type);
}

IDPaySDK.open({
  transactionId,
  token,
  onFinish
});

// You can also close the SDK explicitly using the method below
IDPaySDK.close();

Безопасность​

После тщательного анализа потребностей и вызовов, с которыми мы сталкиваемся, мы решили использовать решение на основе iFrame с токенами аутентификации вместо реализации политики безопасности контента (Content Security Policy, CSP). Это решение было продиктовано рядом соображений, связанных с безопасностью и гибкостью, необходимой для удовлетворения потребностей наших клиентов.

Контекст и проблемы с CSP​

Политика безопасности контента (Content Security Policy, CSP) — это мощный инструмент для защиты веб-приложений от различных типов атак, таких как межсайтовый скриптинг (Cross-Site Scripting, XSS) и внедрение кода. Однако при настройке политики CSP необходимо определить строгий список доверенных доменов. Такой подход хорошо работает, когда домены фиксированы и предсказуемы. Однако для наших клиентов, которые часто используют динамические и переменные домены, эта жёсткая настройка создаёт значительные сложности.

Уязвимость при использовании динамических доменов​

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

Решение с использованием iFrame и токена аутентификации​

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

Как это работает​

  • Безопасная аутентификация: каждый iframe загружается с уникальным токеном аутентификации для каждой транзакции, гарантируя, что доступ к содержимому смогут получить только авторизованные пользователи. Этот токен проверяется в реальном времени, обеспечивая дополнительный уровень безопасности и контроля.
  • Изоляция контента: использование iFrame позволяет изолировать контент в отдельном контексте, снижая риск взаимного влияния между разными источниками (origins) и смягчая потенциальные атаки.
  • Гибкость для динамических доменов: не полагаясь на статическую политику CSP, наше решение легко адаптируется к динамическим доменам клиентов без необходимости постоянного обновления политик безопасности.
Последнее обновление