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ê ainda não conhece os Pagamentos na Web, confira a página "Pagamentos Visão geral" para começar.
Desde o lançamento da API Payment Request e do Gerenciador de pagamentos API, há vários alterações 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 assim:
// Checking for instrument presence.
if (request.hasEnrolledInstrument) {
// hasEnrolledInstrument() is available.
request.hasEnrolledInstrument().then(handleInstrumentPresence).catch(handleError);
} else {
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
}
O canMakePayment() não verifica mais a presença de instrumentos
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(). A partir de junho de 2019, ela foi implementada no Chrome 74, mas
e 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 removido 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, 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 que uma
tempo limite. Esse recurso é destinado a uma ida e volta rápida no servidor.
Esse recurso foi incluído 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
onpaymentmethodchange
manipulador de eventos. 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 local
ambiente de desenvolvimento usa um certificado autoassinado, agora você pode usar
Sinalização de linha de comando --ignore-certificate-errors para fazer com que o Chrome permita a Web
APIs Payments no seu 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.