English version: https://medium.com/@ger86/introduction-to-the-payment-request-api-60f71fae567

En este artículo quiero hablaros de la API Payment Request, una API nativa de los navegadores actuales que el otro día descubrí y que tiene como objetivo facilitar que el “user agent” actúe como intermediario entre los usuarios y los vendedores de servicios o productos.

He aprovechado este fin de semana para trastear un poco con ella y aquí os dejo un pequeño artículo a modo de introducción por si queréis probarla en alguno de vuestros side projects. Al final del artículo encontraréis un repositorio desde el cual podréis descargar un proyecto básico escrito en React donde empleo esta API por si queréis comenzar a trastear desde ahí.

La verdad es que tiene muy buena pinta así que como siempre, ¡vamos a ello!

0. Introducción

Antes de comenzar y por si os estáis planteando usar esta API en producción deciros que según la web caniuse.com le da un soporte del 85% entre los navegadores, por lo que tenedlo en mente si os vais a “lanzar a la piscina”.

Y, aunque resulte obvio a estas alturas, esta API sólo está disponible si nuestra página funciona bajo HTTPS.

Objetivos de la API Payment Request

Atendiendo a la documentación de la API Payment Request en la página w3.org sus objetivos son:

• Permitir al “user agent” actuar como intemediario entre el vendedor, el usuario y el proveedor del método de pago proporcionando una experiencia consistente en todos los sitios webs que implementen esta API. Esto por ejemplo supone una mejora a nivel de accesibilidad pues es el navegador quien controla los “input elements” de modo que sean accesibles para todos los tipos de usuario.
• Agilizar la experiencia de pago teniendo en cuenta las preferencias de pago del usuario (que son almacenadas en el navegador evitando que el usuario tenga que introducirlas múltiples veces), los requisitos de seguridad y la información del vendedor.
• Estandarizar el flujo de comunicación entre el vendedor, el usuario y el método de pago.

Es decir, se trata de una API muy interesante de cara a reducir la “fricción” que supone al usuario lidiar con diferentes formas de pago y formularios en las distintas webs donde quiera realizar compras.

A continuación os enseñaré un ejemplo sencillo explicando cómo integrarla.

1. El objeto PaymentRequest

Para comenzar a trabajar con esta API nos centraremos en el objeto PaymentRequest .

Puesto que como os comentaba antes no todos los navegadores lo soportan, podemos realizar la comprobación de compatibilidad mediante el siguiente código extraído de la documentación que proporciona Google para esta API:

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

El constructor de PaymentRequest recibe 3 argumentos:

• Un array donde especificar los métodos de pago soportados.
• Un objeto donde especificar los detalles de la transacción.
• Y un objeto de opciones donde modificar algunos aspectos del comportamiento del navegador una vez que comience a controlar el proceso del pago como por ejemplo, solicitar el nombre, email o teléfono del comprador o su dirección de envío.

Por ejemplo, podemos crear el siguiente objeto PaymentRequest :

La explicación del código es la siguiente:

• El objeto supportedPaymentMethods define que aceptamos pagos con tarjetas VISA y MasterCard.
• El objeto paymentDetails establece un único pago (total) de 20 €.
• Finalmente el objeto opciones (que no es requerido en el constructor) lo dejamos vacío de cara a no complicar este ejemplo.

Con esto el siguiente paso será añadir un botón que nos permita delegar en el navegador el proceso de pago.

2. Proceso de pago y el objeto PaymentResponse

Una vez que tenemos creado el objeto PaymentRequest lo siguiente que haremos será añadir un botón a nuestro código que lance el proceso de pago vinculado al navegador.

De este modo, cuando el botón sea pulsado lo que haremos será ejecutar el método show del objeto PaymentRequest el cual devuelve una Promise que al resolverse nos devolverá un objeto PaymentResponse con el resultado del proceso.

Los objetos PaymentResponse contienen las siguientes propiedades:

• methodName con el método de pago seleccionado por el usuario.
• details , con los detalles del pago realizado.
• payerName que será null salvo que hayamos establecido en el objeto opciones el valor true para la propiedad requestPayerName .
• payerPhone que será null salvo que hayamos establecido en el objeto opciones el valor true para la propiedad requestPayerPhone .
• payerEmail que será null salvo que hayamos establecido en el objeto opciones el valor true para la propiedad requestPayerEmail .
• shippingInfo para la información de envío.

Por tanto, si ahora pulsamos sobre el botón Pay lo que obtendremos será un diálogo como el siguiente:

Ahora, si pulsamos sobre el botón Añadir podremos establecer la tarjeta que querremos usar. De cara a no usar datos reales podemos emplear el número de tarjeta que proporciona VISA para pruebas:

4242 4242 4242 4242

Hecho esto ya podremos completar el pago pulsando sobre el botón Pagar :

Y obtendremos el siguiente objeto PaymentResponse por consola:

Si os dais cuenta, la modal que lanza el navegador para gestionar el pago no se cierra automáticamente una vez que el pago se completa sino que tendremos que hacerlo nosotros empleando para ello el método complete del objeto PaymentResponse .

Este método recibe como argumento un string con uno de los siguientes valores:

• success para indicar que el pago ha sido procesado satisfactoriamente. Puede que el navegador en este caso muestre algún al usuario un mensaje avisando de que el pago se ha completado correctamente.
• fail , si se ha producido un fallo procesando el pago y, de nuevo, depende del navegador mostrar un mensaje o no informando de esto al usuario.
• unknown , en el caso de que el resultado de la transacción sea desconocido o irrelevante. Esto forzará a que el navegador no presente ninguna notificación por si mismo a diferencia de los dos casos anteriores. Este es el valor por defecto.

Por tanto, al código anterior añadiremos lo siguiente:

De modo que ahora sí, la modal abierta por el navegador se cierre.

La necesidad de tener que emplear el método complete del objeto PaymentResponse se debe a que puede que queramos validar el pago o registrarlo en nuestro “backend”:

Conclusiones

Como habéis podido ver, la API Payment Request nos proporciona una forma nativa y fácil de añadir una pasarela de pago a nuestra aplicación de modo que podamos simplificar todo este proceso y estandarizarlo.

Por supuesto este artículo sólo ha sido una introducción, pues hay mucho más detrás de esta API como por ejemplo la posibilidad de gestionar formas de envío, manejar los errores que sucedan o comprobar si las forma de pago que el usuario tiene registradas en su navegador son compatibles con las de nuestra plataforma mediante el método canMakePayment .

Si queréis probar el ejemplo de este artículo en vuestro navegador podéis clonar el siguiente repositorio:

Referencias

¿Quieres recibir más artículos como este?

Si te ha gustado este artículo te animo a que te suscribas a la newsletter que envío cada domingo con publicaciones similares a esta y más contenido recomendado: 👇👇👇