Atualizações nas APIs Web Payments

Fique por dentro das novidades do Web Payments.

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 estiver familiarizado com os Web Payments, confira a "Visão geral de pagamentos pela Web" para começar.

Desde o lançamento da API Payment Request e da API Payment Handler, foram feitas várias mudanças nas respectivas especificações. Essas alterações não corrompem seu código de trabalho, mas recomendamos que você as procure. Esta postagem resume essas atualizações e continuará acumulando essas alterações na 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 um consenso de todos os principais navegadores. O Chrome implementou o recurso na versão 74, e o Webkit e a Gecko 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 como 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 de instrumentos

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

Essa mudança em canMakePayment() está vinculada à implementação de hasEnrolledInstrument(). Desde junho de 2019, ela foi implementada no Chrome 74, mas não em outros navegadores. Confira 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.");
}

A forma de pagamento languageCode foi removida da basic-card

PaymentAddress.languageCode foi removido dos endereços de entrega e endereços de faturamento para basic-card. Os endereços de faturamento de outras formas de pagamento (como o Google Pay) não são afetados.

Essa mudança foi implementada no Chrome 74, Firefox e 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 10 segundos para resolver o detailsPromise antes do tempo limite. Esse recurso se destina a uma viagem de ida e volta rápida do lado do 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 gerenciadores de pagamento (por exemplo, Google Pay) para acionar o manipulador de eventos onpaymentmethodchange. changePaymentMethod() retorna uma promessa que é resolvida em uma resposta do comerciante com informações de preço atualizadas (por exemplo, recálculo de tributos).

Tanto o evento PaymentRequestEvent.changePaymentMethod() quanto o 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 à produtividade dos desenvolvedores. Se o ambiente de desenvolvimento local usa um certificado autoassinado, agora é possível usar a sinalização de linha de comando --ignore-certificate-errors para fazer com 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 fazer com que o Chrome trate a origem HTTP como HTTPS.