Actualizaciones de las API de pagos web

Mantente al tanto de las novedades de los pagos web.

Danyao Wang
Danyao Wang
Rouslan Solomakhin
Rouslan Solomakhin

Los pagos web están disponibles públicamente en los navegadores desde 2016. La función principal, la API de Payment Request, ahora está disponible en varios navegadores: Chrome, Safari, Edge y, pronto, Firefox. Si es la primera vez que usas los pagos web, consulta la “Descripción general de pagos web” para comenzar.

Desde el lanzamiento de la API de Payment Request y la API de Payment Handler, se realizaron bastantes cambios en sus respectivas especificaciones. Estos cambios no dañarán tu código en funcionamiento, pero te recomendamos que los tengas en cuenta. En esta publicación, se resumen esas actualizaciones y se seguirán acumulando esos cambios en la API.

Nuevo método: hasEnrolledInstrument()

En la versión anterior de la API de Payment Request, se usaba canMakePayment() para verificar la presencia del instrumento de pago del usuario. En una actualización reciente de la especificación, canMakePayment() se reemplazó por hasEnrolledInstrument() sin cambiar su funcionalidad.

El método hasEnrolledInstrument() tiene el consenso de todos los navegadores principales. Chrome lo implementó en la versión 74, y WebKit y Gecko tienen errores de seguimiento, pero aún no implementan el método a partir de junio de 2019.

Para usar el nuevo método hasEnrolledInstrument(), reemplaza el código que se ve de la siguiente manera:

// Checking for instrument presence.
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);

Con código como el siguiente:

// Checking for instrument presence.
if (request.hasEnrolledInstrument) {
  // hasEnrolledInstrument() is available.
  request.hasEnrolledInstrument().then(handleInstrumentPresence).catch(handleError);
} else {
  request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
}

canMakePayment() ya no verifica la presencia de instrumentos

Debido a que hasEnrolledInstrument() ahora controla la verificación del instrumento de pago del usuario, canMakePayment() se actualizó para verificar solo la disponibilidad de la app de pagos.

Este cambio a canMakePayment() está vinculado a la implementación de hasEnrolledInstrument(). A partir de junio de 2019, se implementó en Chrome 74, pero no en ningún otro navegador. Asegúrate de verificar si el método hasEnrolledInstrument() está disponible en el navegador del usuario antes de intentar usarlo.

// Checking for payment app availability without checking for instrument presence.
if (request.hasEnrolledInstrument) {
  // `canMakePayment()` behavior change corresponds to
  // `hasEnrolledInstrument()` availability.
  request.canMakePayment().then(handlePaymentAppAvailable).catch(handleError);
} else {
  console.log("Cannot check for payment app availability without checking for instrument presence.");
}

languageCode se quitó de la forma de pago basic-card

Se quitó PaymentAddress.languageCode de las direcciones de envío y de facturación de basic-card. Las direcciones de facturación de otras formas de pago (como Google Pay) no se ven afectadas.

Este cambio se implementó en Chrome 74, Firefox y Safari.

PaymentRequest.show() ahora toma un detailsPromise opcional.

PaymentRequest.show() permite que un comercio presente una IU de solicitud de pago antes de que se conozca el total final. El comercio tiene diez segundos para resolver el detailsPromise antes de que se agote el tiempo de espera. Esta función está diseñada para un recorrido de ida y vuelta rápido del servidor.

Esta función se lanzó en Chrome 75 y Safari.

// Not implemented in Chrome 74 and older.
// There's no way to feature-detect this, so check a few
// older versions of Chrome that you're seeing hit your servers.
if (/Chrome\/((6[0-9])|(7[0-4]))/g.exec(navigator.userAgent) !== null) {
  return;
}

// Supported in Chrome 75+.
request.show(new Promise(function(resolveDetailsPromise, rejectDetailsPromise) {
  // Find out the exact total amount and call
  // `resolveDetailsPromise(details)`.
  // Use a 3 second timeout as an example.
  window.setTimeout(function() {
    resolveDetailsPromise(details);
  }, 3000); // 3 seconds.
}))
.then(handleResponse)
.catch(handleError);

PaymentRequestEvent.changePaymentMethod()

La función de la API de Payment Handler PaymentRequestEvent.changePaymentMethod() permite que los controladores de pagos (p. ej., Google Pay) para activar el controlador de eventos onpaymentmethodchange. changePaymentMethod() muestra una promesa que se resuelve en una respuesta del comercio con información de precios actualizada (p.ej., el recálculo de impuestos).

Tanto PaymentRequestEvent.changePaymentMethod() como el evento paymentmethodchange están disponibles en Chrome 76, y Webkit implementó el evento paymentmethodchange en su Versión preliminar de tecnología.

// In service worker context, `self` is the global object.
self.addEventListener('paymentrequest', (evt) => {
  evt.respondWith(new Promise((confirmPaymentFunction, rejectPaymentFunction) => {
    if (evt.changePaymentMethod === undefined) {
      // Not implemented in this version of Chrome.
      return;
    }
    // Notify merchant that the user selected a different payment method.
    evt.changePaymentMethod('https://paymentapp.com', {country: 'US'})
    .then((responseFromMerchant) => {
      if (responseFromMerchant === null) {
        // Merchant ignored the 'paymentmethodchange' event.
        return;
      }
      handleResponseFromMerchant(responseFromMerchant);
    })
    .catch((error) => {
      handleError(error);
    });
  }));
});

Ejemplo de comercio:

if (request.onpaymentmethodchange === undefined) {
  // Feature not available in this browser.
  return;
}

request.addEventListener('paymentmethodchange', (evt) => {
  evt.updateWith(updateDetailsBasedOnPaymentMethod(evt, paymentDetails));
});

Desarrollo local mejorado

En Chrome 76, se agregan dos pequeñas mejoras en la productividad de los desarrolladores. Si tu entorno de desarrollo local usa un certificado autofirmado, ahora puedes usar la marca de línea de comandos --ignore-certificate-errors para que Chrome permita las APIs de pagos web en tu entorno de desarrollo. Si desarrollas con un servidor web local que no admite HTTPS, también puedes usar la marca --unsafely-treat-insecure-origin-as-secure=<origin> para que Chrome trate el origen HTTP como HTTPS.