Использование подтверждения безопасной оплаты

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

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

Для сильной аутентификации используется несколько механизмов в сочетании, включая пароли, одноразовые SMS-коды, мобильные приложения и Web Authentication. Каждый из них имеет свои преимущества и недостатки. Например, одноразовые SMS-коды теперь знакомы пользователям, но могут вызывать проблемы с удобством использования (например, недоступность устройства) и уязвимости в области безопасности. Web Authentication предлагает лучшую безопасность и доступна во всех основных браузерах и на всех современных мобильных устройствах и компьютерах. Однако Web Authentication сам по себе не предоставляет доказательств согласия пользователя на совершение платежа.

SPC разработан для обеспечения бесперебойной сильной аутентификации клиента (SCA) в различных платежных системах и для предоставления криптографических доказательств, что пользователь дал согласие на условия транзакции. При вызове API браузер отображает элементы транзакции в диалоговом окне: название торговца, платежный инструмент, сумму и валюту платежа. Например, вот диалоговое окно транзакции браузера Chrome (версия M118) для SPC:

Выбор «Проверить» инициирует поток Web Authentication. Когда пользователь успешно проходит аутентификацию (например, используя биометрические аутентификаторы на своем телефоне или ноутбуке), браузер передает данные, отображенные в диалоговом окне, аутентификатору, который подписывает их и возвращает как часть утверждения Web Authentication. Затем утверждение может быть передано в Relying Party для проверки. Поскольку браузер передает отображаемые данные напрямую аутентификатору (без возможности изменения данных кодом JavaScript), Relying Party может быть уверен, что пользователь дал согласие на отображаемые данные транзакции.

Таким образом, SPC использует Web Authentication для того, чтобы сайты могли выполнять бесперебойную сильную аутентификацию и предоставлять доказательства согласия пользователя. Как правило, SPC используется как часть фреймворка аутентификации данной платежной системы. Например, SPC поддерживается как EMV® 3-D Secure (версия 2.3.1), так и EMV® Secure Remote Commerce (версия 1.3), но разработан для работы с широким спектром типов платежей, включая «push-платежи», такие как прямые переводы и платежи с помощью кошелька.

Подтверждение безопасной оплаты использует основанные возможности API запроса платежа. Стандартизированный идентификатор платежного метода для обработчика платежей подтверждения безопасной оплаты — "secure-payment-confirmation".

Подтверждение безопасной оплаты определяет расширение аутентификации веб-приложения, payment, которое добавляет три возможности, связанные с платежами, поверх традиционной Web Authentication:

1. При выборе Relying Party, позволяет сущностям, отличным от Relying Party, инициировать церемонию аутентификации платежей с учетными данными Relying Party. SPC отсоединяет церемонию аутентификации от валидации результатов аутентификации. Это позволяет торговцам (или их поставщикам платежных услуг в фрейме iframe с пересечением доменов) сохранить контроль над пользовательским опытом аутентификации, не перенаправляя пользователя (через переадресацию) на другой веб-сайт или мобильное приложение. Если Relying Party — это банк, например, это позволяет торговцу управлять пользовательским опытом аутентификации, а банк по-прежнему может проверять результаты аутентификации. Обмен данными между сторонами (учетных данных и результатов аутентификации) обычно происходит по специфичным для платежной системы каналам, таким как EMV® 3-D Secure.
2. Обеспечивает, что User Agent должным образом сообщает пользователю, что он проходит аутентификацию транзакции и детали транзакции. Затем эти детали включаются в утверждение, подписанное аутентификатором.
3. Позволяет вызывать navigator.credentials.create в фрейме iframe с пересечением доменов, при условии, что для фрейма установлен политический режим разрешения «платеж». Примечание: эта возможность теперь является частью WebAuthn Level 3, где вместо этого используется политический режим разрешения «publickey-credential-create». Разработчикам рекомендуется использовать его при наличии, вместо того, чтобы полагаться на политику разрешения «платеж» SPC.

Создание учетной записи в подтверждении безопасной оплаты выполняется с помощью того же вызова navigator.credentials.create(), что и в Web Authentication, но с указанным расширением payment.

const publicKey = {
  challenge: Uint8Array.from(randomStringFromServer, (c) => c.charCodeAt(0)),
  rp: {
    name: "Fancy Bank",
  },
  user: {
    // Assuming that userId is ASCII-only
    id: Uint8Array.from(userId, (c) => c.charCodeAt(0)),
    name: "jane.doe@example.org",
    displayName: "Jane Doe",
  },
  pubKeyCredParams: [
    {
      type: "public-key",
      alg: -7, // "ES256"
    },
    {
      type: "public-key",
      alg: -257, // "RS256"
    },
  ],
  authenticatorSelection: {
    userVerification: "required",
    residentKey: "required",
    authenticatorAttachment: "platform",
  },
  timeout: 60000, // 1 minute
  extensions: {
    payment: {
      isPayment: true,
    },
  },
};
navigator.credentials
  .create({ publicKey })
  .then((newCredentialInfo) => {
    // Send new credential info to server for verification and registration.
  })
  .catch((err) => {
    // No acceptable authenticator or user refused consent. Handle appropriately.
  });

SPC позволяет создать учетную запись в фрейме iframe с пересечением доменов (например, если merchant.com встраивает iframe от bank.com).

В этом процессе в рамках транзакции Relying Party (например, банк) проходит аутентификацию держателя счета с помощью другого механизма, чем SPC (например, с помощью одноразового кода или другого механизма). Затем Relying Party предлагает пользователю возможность регистрации учетной записи SPC для упрощения будущих транзакций. Пользователь регистрирует учетную запись SPC у Relying Party. Для того чтобы эти шаги происходили в контексте торговца (то есть без переадресации), фрейм iframe с пересечением доменов должен иметь политику разрешения payment.

Например:

<!-- Assume parent origin is merchant.com -->
<!-- Inside this cross-origin iframe, script would be allowed to create a SPC credential for example.org -->
<iframe src="https://example.org" allow="payment"></iframe>

Происхождение может вызвать API запроса платежа с помощью платежного метода "secure-payment-confirmation", чтобы попросить пользователя подтвердить учетную запись подтверждения безопасной оплаты, созданную любым другим происхождением. Браузер отобразит собственный пользовательский интерфейс (диалоговое окно «транзакции») с деталями транзакции (например, валютой платежа, суммой и происхождением получателя).

const request = new PaymentRequest(
  [
    {
      supportedMethods: "secure-payment-confirmation",
      data: {
        // List of credential IDs obtained from the Account Provider.
        credentialIds,
        // The challenge is also obtained from the Account Provider.
        challenge: new Uint8Array(randomStringFromServer, (c) =>
          c.charCodeAt(0),
        ),
        instrument: {
          displayName: "Fancy Card ****1234",
          icon: "https://fancybank.com/card-art.png",
        },
        payeeOrigin: "https://merchant.com",
        timeout: 60000, // 1 minute
      },
    },
  ],
  {
    total: {
      label: "Total",
      amount: {
        currency: "USD",
        value: "5.00",
      },
    },
  },
);
try {
  // NOTE: canMakePayment() checks only public information for whether the SPC
  // call is valid. To preserve user privacy, it does not check whether any
  // passed credentials match the current device.
  const canMakePayment = await request.canMakePayment();
  if (!canMakePayment) {
    throw new Error("Cannot make payment");
  }
  const response = await request.show();
  await response.complete("success");
  // response.details is a PublicKeyCredential, with a clientDataJSON that
  // contains the transaction data for verification by the issuing bank.
  // send response.details to the issuing bank for verification
} catch (err) {
  // SPC cannot be used; merchant should fallback to traditional flows
}

• API запроса платежа
• Идентификаторы платежных методов
• Web Authentication
• Описание подтверждения безопасной оплаты
• Сфера действия подтверждения безопасной оплаты
• Общая схема процесса SPC во время платежа
• Набор тестов подтверждения безопасной оплаты
• Документация разработчика Chrome для SPC
• EMV® 3-D Secure (версия 2.3)
• EMV® Secure Remote Commerce (версия 1.3)