Введение в API запроса платежа, предоставляемый современными браузерами

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

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

Правда в том, что это выглядит очень хорошо, так что, как всегда, давайте сделаем это!

0. Введение

Прежде чем начать, а также в случае, если вы планируете использовать этот API в производственной среде, сообщите им, что, согласно веб-сайту caniuse.com, он обеспечивает 85% поддержку среди браузеров, так что имейте это в виду, если вы собираетесь чтобы начать с ним работать.

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

Цели API запроса платежа

Согласно документации по API запроса платежей на w3.org, его цели:

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

То есть это очень интересный API для уменьшения «трений», которые пользователь имеет в виду при работе с различными формами оплаты и формами на разных веб-сайтах, где вы хотите совершать покупки.

Ниже я покажу вам простой пример, объясняющий, как его интегрировать.

1. Объект PaymentRequest

Чтобы начать работу с этим API, мы сосредоточимся на объекте PaymentRequest.

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

if(window.PaymentRequest) {
  // Use Payment Request API
} else {
  // Fallback to traditional checkout
}

Строитель PaymentRequest получает 3 аргумента:

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

Например, мы можем создать следующий объект PaymentRequest:

Объяснение кода следующее:

  • Объект supportedPaymentMethods определяет, что мы принимаем платежи картами VISA и MasterCard.
  • Объект paymentDetails устанавливает разовый (общий) платеж в размере 20 евро.
  • Наконец, параметры объекта (которые не требуются в конструкторе) мы оставляем пустыми, чтобы не усложнять этот пример.

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

2. Процесс оплаты и объект PaymentResponse

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

Таким образом, когда кнопка нажата, мы выполним метод show объекта PaymentRequest, который возвращает Promise, который при разрешении вернет объект PaymentResponse с результатом процесса.

PaymentResponse объект содержит следующие свойства:

  • methodName с выбранным пользователем способом оплаты.
  • details, с реквизитами произведенного платежа.
  • payerName будет null, если только мы не установили значение true для свойства requestPayerName в объекте параметров.
  • payerPhone будет null, если только мы не установили значение true для свойства requestPayerPhone в объекте параметров.
  • payerEmail будет null, если только мы не установили значение true для свойства requestPayerEmail в объекте параметров.
  • shippingInfo для информации о доставке.

Поэтому, если мы сейчас нажмем кнопку Pay, мы получим диалог, подобный следующему:

Теперь, если мы нажмем кнопку Add, мы сможем установить карту, которую хотим использовать. Чтобы не использовать реальные данные, мы можем использовать номер карты, предоставленный VISA для тестирования:

4242 4242 4242 4242

Как только это будет сделано, мы можем завершить платеж, нажав на кнопку Pay:

И мы получим следующий объект PaymentResponse через консоль:

Если вы понимаете, модальное окно, которое запускает браузер для управления платежом, не закрывается автоматически после завершения платежа, но нам придется сделать это с помощью метода complete объекта PaymentResponse.

Этот метод получает в качестве аргумента string с одним из следующих значений:

  • success, чтобы указать, что платеж был успешно обработан. В этом случае браузер может показать пользователю сообщение о том, что платеж был выполнен правильно.
  • fail, если произошел сбой при обработке платежа и, опять же, браузер должен показывать сообщение или не информировать об этом пользователя.
  • unknown, в случае, если результат сделки неизвестен или не имеет значения. Это заставит браузер не отображать никаких уведомлений, в отличие от предыдущих двух случаев. Это значение по умолчанию.

Поэтому к предыдущему коду добавим следующее:

Итак, модальное окно, открытое браузером, закрыто.

Необходимость использования метода complete объекта PaymentResponse связана с тем, что мы можем захотеть проверить платеж или зарегистрировать его в нашем «бэкенде»:

Выводы

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

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

Если вы хотите попробовать пример этой статьи в своем браузере, вы можете клонировать следующий репозиторий:



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





Хотите читать больше подобных статей?

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