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 de forma pública 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 muchos cambios en sus respectivas especificaciones. Estos cambios no dañarán tu código de trabajo, pero te recomendamos que los prestes atención. En esta publicación, se resumen esas actualizaciones y seguirán acumulando esos cambios de API.

Método nuevo: hasEnrolledInstrument()

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

El método hasEnrolledInstrument() tiene un 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 implementaron el método desde junio de 2019.

Para usar el nuevo método hasEnrolledInstrument(), reemplaza el código con el siguiente aspecto:

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

Con un código que se ve de la siguiente manera:

// 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 implementa 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.");
}

Se quitó languageCode 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á pensada para ofrecer un recorrido de ida y vuelta rápido del servidor.

Esta función se envió 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 PaymentRequestEvent.changePaymentMethod() de la API de Payment Handler permite controladores de pago (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 actualizada del precio (p.ej., un nuevo cálculo de impuestos).

Tanto PaymentRequestEvent.changePaymentMethod() como el evento paymentmethodchange están disponibles en Chrome 76, y Webkit implementó el evento paymentmethodchange en su vista previa 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 hacer 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.