Apresentando o Web Payments: Compras on-line mais fáceis com a API de solicitação de pagamento

Comprar coisas online pode ser um processo frustrante, especialmente no celular. Mesmo que as páginas sejam bem projetadas, há muitas informações necessárias: Nossas informações de contato, endereços de envio e cobrança, opção de envio e detalhes do cartão. Se você já desistiu algumas vezes, você é a maioria.

O Baymard Institute fez uma média de 37 estudos diferentes e descobriu que 69% dos carrinhos de compras são abandonados.

Sem surpresa, os números são piores no celular, onde a tela menor e a falta de um teclado físico podem tornar a entrada mais lenta. A taxa de abandono no celular pode chegar a 84% ou mais! Com a ascensão e ascensão da navegação móvel nos últimos anos, isso significa que o problema geral está ficando cada vez pior. Para sites de comércio eletrônico, esses carrinhos abandonados estão custando muito dinheiro. A Business Insider estimou que US$ 4 trilhões em mercadorias seriam abandonadas em um ano.

Felizmente, a web está lutando contra esse problema. O Grupo de Trabalho do W3C “Pagamentos pela Web” tem estado ocupado trabalhando em “uma revolução nos pagamentos na Web” , desenvolvendo novos padrões para ajudar a tornar os pagamentos online muito mais fáceis. Além de ser o nome do Grupo de Trabalho, “Pagamentos pela Web” é essencialmente um termo abrangente que abrange esses novos padrões promissores.

A API de solicitação de pagamento

O primeiro desses padrões, a API de solicitação de pagamento , é um grande avanço. Ele nos dá a capacidade de solicitar o pagamento de um usuário e fazer com que o navegador forneça a interface do usuário para aceitá-lo. Já é suportado no Chrome, Edge e Samsung Internet, e está em desenvolvimento no Firefox e Safari. Muitas empresas de alto perfil estão adotando a API, incluindo o New York Times, o Washington Post e o Monzo.

Solicitar essas informações do navegador oferece um benefício imediato e importante, pois provavelmente já possui esses detalhes armazenados . Contanto que tenhamos inserido nossos dados em outro site que use a API e permitido que nosso navegador se lembre deles, o navegador poderá preencher o formulário previamente, permitindo que façamos o check-out muito mais rápido.

Isso é melhor do que o preenchimento automático padrão; permitir que o navegador manipule os campos de entrada significa que ele pode ser totalmente preciso — evitando problemas com o preenchimento prévio de informações erradas nos campos errados. Isso também significa que temos um formulário de checkout de página única otimizado para dispositivos móveis, sem precisar escrever nosso próprio HTML e CSS para ele.

Os benefícios podem ser sentidos ainda mais em dispositivos móveis, mas a API de solicitação de pagamento não se limita a navegadores móveis. Já é suportado nas versões desktop do Chrome, Edge e Samsung Internet for DeX. Também podemos esperar que o suporte chegue ao Firefox e Safari para desktop mais tarde (no momento em que escrevo, ele foi ativado recentemente por padrão no Safari Technology Preview 44).

Nossa primeira solicitação de pagamento

Vamos começar a explorar a API com um exemplo básico. Vamos solicitar um pagamento com cartão do usuário e permitir que ele faça o check-out assim:

No vídeo acima, você notará que o usuário confirma o pagamento com sua impressão digital. Isso não faz parte do padrão de solicitação de pagamento em si, mas é um recurso de segurança que o navegador de Internet Samsung fornece (junto com a digitalização da íris) em dispositivos compatíveis.

Se você estiver interessado em mais potencial para integrar a autenticação biométrica na web, você pode ficar de olho no próximo padrão de autenticação da web.

Primeiro, como de costume, devemos adotar o Progressive Enhancement e verificar se este navegador tem suporte para a API:

 if (window.PaymentRequest) { // We can continue with the Payment Request API } else { // Here we could fall back to a legacy checkout form }

Agora podemos definir a configuração do nosso PaymentRequest — o tipo de pagamento que aceitaremos e os detalhes a serem exibidos sobre a compra:

 var methodData = [{ // 'basic-card' means standard card payments - credit and debit cards supportedMethods: 'basic-card' }]; var details = { // If we are buying multiple items, each one can be included displayItems: [ { label: 'Some product that we are buying', amount: {currency: 'USD', value: '699.99'} } ], total: { label: 'Total', amount: {currency: 'USD', value: '699.99'} } }; var paymentRequest = new PaymentRequest(methodData, details);

Quando queremos exibir a interface do usuário de pagamento (por exemplo, quando o usuário clica em “Comprar agora”), podemos chamar show() . Em seguida, tratamos os dados que o usuário forneceu quando a promessa foi resolvida:

 // show() makes it actually display the user interface paymentRequest.show() .then(function(paymentResponse) { // User has confirmed. paymentResponse contains the data entered. // Here we would process it server-side... processPaymentDetails(paymentResponse) .then(function(paymentResponse) { // ...Then when processed successfully, this will make the dialog indicate success & then close: paymentResponse.complete('success'); // We could also update the page here appropriately }); }) .catch(function(error) { // Handle error, eg if user clicks the 'cancel' button. });

Agora temos o fluxo de interface do usuário configurado no front-end. Também podemos configurá-lo ainda mais, para atender aos nossos requisitos. Por exemplo, se desejarmos solicitar detalhes extras do cliente, podemos passar options adicionais para o construtor PaymentRequest. Por exemplo, para solicitar o nome do usuário, endereço de e-mail, número de telefone e endereço de entrega:

 var options = { requestPayerName: true, requestPayerEmail: true, requestPayerPhone: true, requestShipping: true }; var paymentRequest = new PaymentRequest(methodData, details, options);

Também podemos definir várias opções de envio e até controlar quais opções são apresentadas dinamicamente, com base no endereço do cliente. Você pode encontrar um exemplo disso aqui no Glitch.

Experiência de usuário

Estamos começando a ver algumas estatísticas impressionantes sobre os benefícios que a Solicitação de Pagamento pode trazer para as empresas. O Google recentemente compartilhou que a J.Crew, uma marca de moda, descobriu que 50% de seus usuários agora passam pelo fluxo de solicitação de pagamento e reduz o tempo de transação em 75%!

Cabe a você como integrar a Solicitação de Pagamento à sua experiência de compra, mas uma maneira comum é oferecer algo como uma opção de “Checkout Expresso” ou “Comprar Agora”, sem exigir que o cliente faça login primeiro. Se desejar, você pode coletar os dados de contato do usuário usando a interface de solicitação de pagamento e, uma vez que ele tenha feito a compra, oferecer a oportunidade de criar uma conta para uso futuro.

Se desejar, você pode verificar primeiro se o cliente já possui uma forma de pagamento válida configurada, antes de apresentar a UI de solicitação de pagamento. Para fazer isso, você pode chamar canMakePayment :

 if (paymentRequest.canMakePayment) { paymentRequest.canMakePayment().then(function(result) { if (result) { // User has an active payment method } else { // No active payment method yet (but they could add one) } }).catch(function(error) { // Unable to determine }); }

Integração de back-end

Vimos como configurar a interface do usuário para receber pagamentos, mas como processamos os pagamentos no back-end?

A maioria dos sites não lida com pagamentos (algo que exigiria muito cuidado e conformidade com o PCI DSS), mas usa um Gateway de Pagamento (PG) ou Provedor de Serviços de Pagamento (PSP) de terceiros. Vários gateways de pagamento já introduziram suporte específico para a API de solicitação de pagamento. Eles podem iniciar a Solicitação de Pagamento por meio de seu próprio script que você inclui em sua página, ajudando a garantir que os dados sejam enviados com segurança e que você não precise lidar com isso sozinho. Eles também podem oferecer uma solução de iFrame ou redirecionamento. A melhor maneira de proceder é verificar com seu Gateway de Pagamento como eles recomendam a incorporação de Solicitações de Pagamento.

Integração do aplicativo de pagamento

Até agora discutimos pagamentos com cartão. No entanto, a API de solicitação de pagamento também suporta aplicativos de pagamento móvel como Samsung Pay, Pay with Google (incorporando o Android Pay) e Apple Pay.

Permitir que nossos clientes paguem com um desses aplicativos significa que eles podem usar o cartão que salvaram no aplicativo, sem precisar inserir novamente os detalhes (mesmo na primeira vez) no navegador. O uso desses aplicativos também pode ser mais rápido porque eles não exigem que o cliente insira novamente seu CVC (Código de verificação do cartão, também conhecido como CVV) no verso do cartão. Por fim, eles podem trazer benefícios adicionais de segurança porque não transmitem os detalhes do cartão original, apenas tokens de uso único, protegendo-nos de possíveis ataques de interceptação e repetição.

Quando o cliente seleciona o aplicativo de pagamento como método de pagamento escolhido, o navegador muda para uma planilha de pagamento fornecida pelo aplicativo, para confirmar o pagamento. O aplicativo de terceiros geralmente aceita a impressão digital ou a digitalização da íris do cliente para confirmar o pagamento, se o dispositivo for compatível.

Cada aplicativo de pagamento terá suas próprias instruções particulares, mas a ideia geral é a mesma. Você pode identificá-los como possíveis métodos de pagamento usando seus próprios URLs especiais e passar a configuração necessária no campo de data . Por exemplo, para oferecer suporte ao Samsung Pay, você deve incluir um código como este em sua matriz methodData :

 var methodData = [ { supportedMethods: 'https://spay.samsung.com', data: { // Samsung Pay specific data here } }, … // Other payment methods ];

De um modo geral, existem dois métodos para integrar esses aplicativos com seu gateway de pagamento: um método “Gateway Token” e um método “Network Token”. Se você estiver usando um serviço de terceiros que o suporte, provavelmente usará o modo Gateway Token, em que o serviço do aplicativo de pagamento fará uma chamada para seu Gateway de pagamento em seu nome. Alternativamente, você pode usar o método de Token de Rede onde você lidará com o envio do token para seu Gateway de Pagamento com segurança, usando seu SDK. Seu gateway de pagamento e/ou provedor de aplicativo de pagamento deve fornecer mais detalhes.

O Google anunciou recentemente a Google Payment API, que incorpora o Android Pay, bem como os cartões armazenados nas contas do Google dos clientes.

Atualmente, o Apple Pay usa sua própria solução JavaScript, o Apple Pay JS. No entanto, os desenvolvedores do Google criaram um wrapper que permite que você o use por meio da API de solicitação de pagamento padrão.

Qual é o próximo?

O Grupo de Trabalho de Pagamentos pela Web não está parando na API de solicitação de pagamento. O trabalho também está em andamento em outros padrões, incluindo a API Payment Handler, que permitirá que aplicativos da web funcionem como um aplicativo de pagamento de terceiros. Outros tópicos que estão sendo discutidos incluem a possível padronização em torno da tokenização e a capacidade de Solicitações de pagamento para oferecer suporte a itens como cartões-presente. Se você quiser acompanhar os desenvolvimentos, aqui está a lista de discussão pública. Espero que juntos possamos resolver as frustrantes experiências de checkout do passado e alcançar a visão de uma revolução de pagamentos pela web!

Recursos adicionais

• “W3C Web Payments Wiki,” GitHub
• “Informações do desenvolvedor da API de solicitação de pagamento do W3C”, GitHub consulte também FAQ
• “Web Payments 101: A Short Payment Request Coding Tutorial,” Glitch
• “Mergulhe fundo na API de solicitação de pagamento”, Google Developers
• “Guia do desenvolvedor da API de solicitação de pagamento”, Microsoft Edge
• “Como aceitar o Samsung Pay em seu site usando pagamentos pela Web”, Winston Chen, Medium