Введение в 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
.
Если вы хотите попробовать пример этой статьи в своем браузере, вы можете клонировать следующий репозиторий:
использованная литература
Хотите читать больше подобных статей?
Если вам понравилась эта статья, я призываю вас подписаться на информационный бюллетень, который я отправляю каждое воскресенье с публикациями, похожими на этот и другие рекомендуемые материалы: 👇👇👇