Atualizações nas APIs Web Payments

Fique por dentro das novidades dos pagamentos na Web.

Danyao Wang
Danyao Wang
Rouslan Solomakhin
Rouslan Solomakhin

Os pagamentos na Web estão disponíveis publicamente nos 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 da Web, consulte a Visão geral dos pagamentos da 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 mudanças não vão interromper o código em funcionamento, mas recomendamos que você preste atenção nelas. Esta postagem resume essas atualizações e vai continuar acumulando essas mudanças 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 implementou o método na versão 74, e o WebKit e o Gecko têm bugs de rastreamento, mas ainda não implementaram o método em 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 lida com 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 está 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 10 segundos para resolver o detailsPromise antes do 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 da 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ê desenvolver usando um servidor da Web local que não oferece suporte a HTTPS, também poderá usar a flag --unsafely-treat-insecure-origin-as-secure=<origin> para fazer com que o Chrome trate a origem HTTP como HTTPS.