Atualizações nas APIs Web Payments

Fique por dentro das novidades dos pagamentos na Web.

Danyao Wang
Danyao Wang
Rouslan Solomakhin
Rouslan Solomakhin

O Web Payments está disponível publicamente em navegadores desde 2016. O recurso principal, a API Payment Request, agora está disponível em vários navegadores: Chrome, Safari, Edge e, em breve, Firefox. Se você não conhece os pagamentos pela Web, confira a Visão geral dos pagamentos pela Web para começar.

Desde o lançamento da API Payment Request e da API Payment Handler, várias mudanças foram feitas nas respectivas especificações. Essas alterações não quebrarão seu código em funcionamento, mas recomendamos que você fique atento a elas. Esta postagem resume essas atualizações e continuará acumulando essas alterações de API.

Novo método: hasEnrolledInstrument()

Na versão anterior da API Payment Request, canMakePayment() era usado para verificar a presença do instrumento de pagamento do usuário. Em uma atualização recente da especificação, canMakePayment() foi substituído por hasEnrolledInstrument() sem mudar a funcionalidade.

O método hasEnrolledInstrument() tem consenso de todos os principais navegadores. O Chrome o implementou na versão 74, e o Webkit e a Gecko (links em inglês) têm bugs de rastreamento, mas ainda não implementaram o método desde junho de 2019.

Para usar o novo método hasEnrolledInstrument(), substitua o código semelhante a este:

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

Com um código parecido com este:

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

canMakePayment() não verifica mais a presença do instrumento

Como hasEnrolledInstrument() agora processa a verificação do instrumento de pagamento do usuário, canMakePayment() foi atualizado para verificar apenas a disponibilidade do app de pagamento.

Essa mudança para canMakePayment() está vinculada à implementação de hasEnrolledInstrument(). Desde junho de 2019, ela foi implementada no Chrome 74, mas não em outros navegadores. Verifique se o método hasEnrolledInstrument() está disponível no navegador do usuário antes de tentar usá-lo.

// 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 removida da forma de pagamento basic-card

PaymentAddress.languageCode foi removido dos endereços de entrega e de faturamento de basic-card. Os endereços de faturamento de outros métodos de pagamento, como o Google Pay, não são afetados.

Essa mudança foi implementada no Chrome 74, no Firefox e no Safari.

PaymentRequest.show() agora usa um detailsPromise opcional

PaymentRequest.show() permite que um comerciante apresente uma interface de solicitação de pagamento antes que o total final seja conhecido. O comerciante tem dez segundos para resolver o detailsPromise antes de um tempo limite. Esse recurso é destinado a uma ida e volta rápida no servidor.

Esse recurso foi lançado no Chrome 75 e no 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()

O recurso da API Payment Handler PaymentRequestEvent.changePaymentMethod() permite que os gerenciadores de pagamento (por exemplo, Google Pay) para acionar o manipulador de eventos onpaymentmethodchange. changePaymentMethod() retorna uma promessa que é resolvida para uma resposta do comerciante com informações de preço atualizadas (por exemplo, recalculo de tributos).

O PaymentRequestEvent.changePaymentMethod() e o evento paymentmethodchange estão disponíveis no Chrome 76, e o Webkit implementou o evento paymentmethodchange na prévia de tecnologia.

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

Exemplo de comerciante:

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

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

Desenvolvimento local aprimorado

O Chrome 76 adiciona duas pequenas melhorias para a produtividade dos desenvolvedores. Se o ambiente de desenvolvimento local usar um certificado autoassinado, agora é possível usar a flag de linha de comando --ignore-certificate-errors para permitir que o Chrome permita APIs de pagamentos da Web no ambiente de desenvolvimento. Se você desenvolve usando um servidor da Web local que não oferece suporte a HTTPS, também é possível usar a sinalização --unsafely-treat-insecure-origin-as-secure=<origin> para que o Chrome trate a origem HTTP como HTTPS.