Fique por dentro das novidades dos pagamentos na Web.
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.