Documentação

❔Dúvidas Frequentes

Sobre Pagamento Customizado

Suggest Edits

Tem algum tempo de retorno máximo das Requisições feitas pelo Pagamento Customizado?

O tempo de resposta padrão é de até 3000 ms, depois disso é considerado timeout.
Como queremos sempre prover o melhor serviço para nossos clientes, é importante que esse retorno seja feito o mais rápido possível.

Como faço para utilizar o formulário de cartão de crédito padrão da Wake no checkout?

A plataforma disponibiliza uma DIV que pode ser inserida no campo "Editor HTML" do Pagamento Custom. Essa DIV retorna os principais campos solicitados no Cartão de crédito, mas é possível inserir outros campo no Editor HTML para ser renderizado junto com os campos do Cartão de crédito.

Além disso, incluímos também um input hidden que permite trazer o campo "Salvar cartão" já selecionado automaticamente, o que ajuda bastante os clientes a deixar seus cartões salvos para a próxima compra (saiba mais).

Segue abaixo a DIV:

<div data-gateway-cartao>
  <div class='forminline'>
    <input type="hidden" id="saveCard" value="true" />
  </div>
</div>

Os campos inputs disponibilizados no HTML, já tem um default para os dados do cartão ou precisamos definir?

Se utilizar a DIV do formulário padrão da plataforma no Editor HTML, os campos abaixo serão listados.
Também é possível inserir novos campos no Editor HTML para que seja exibido no checkout e enviado no "form" da requisição.

Os campos já possuem algumas validações padrões e se o cliente não informa os dados do cartão, o pedido não chega a ser finalizado devido a obrigatoriedade dos campos.
Assim que inseridos, sempre serão enviados dentro do form no padrão da documentação.

"form": {
        "number": "5555 5555 5555 5555",
        "name": "nome cliente",
        "month": "10",
        "year": "2222",
				"expiry": "10/2222",
        "cvc": "222",
        "saveCard":true
}

Como é feito o processo de armazenagem do cartão de crédito pela Wake?

O cartão salvo deve ser gerenciado pelo Conector/Aplicação terceira.
Na DIV do formulário padrão da plataforma, temos um input hidden que traz a opção de "Salvar o cartão" selecionado _ou _não selecionado por padrão no Checkout. Essa informação é enviada nas requisições /payment e /authorize e a aplicação/conector que receber essa requisição precisa tokenizar/mascarar os dados do cartão na base (seguindo as regras da LGPD) e retornar esse cartão com os dados mascarados quando a plataforma fizer a requisição /payment-details.

O cliente irá visualizar os cartões sugeridos e selecionará o cartão que desejar.

É importante seguir a documentação de "Como configurar os cartões sugeridos nos Checkout" para que a plataforma envie o "token/chave" correto no "Form" da requisição /payment e /authorize, e a aplicação processe o pagamento corretamente.
Quando falamos sobre tokenização, estamos falando sobre mascarar as informações para manter os dados dos clientes protegidos e retornar a chave/token na resposta da requisição /payment-details para usarmos apenas essa chave no próximo pedido, e não os dados do cartão.

Como conseguimos saber qual a forma de pagamento selecionada pelo cliente? Só suporta cartão de crédito? Conseguimos habilitar Pix ou Boleto?

O custom é aberto para todos os tipos de pagamento, quem define isso é o parceiro. Para cada forma de pagamento é necessário um grupo de pagamento. Cada grupo possui um nome e pode ter uma URL cadastrada para receber os dados.

Assim é possível identificar por URL e pelos Headers cadastrados na configuração Custom, mas fica a critério do parceiro.

Como funciona uma assinatura no Pagamento Customizado? É possível ter o mesmo produto para Assinatura e Avulso?

As assinaturas são configuradas pelo Lojista dentro do admin da Wake. (saiba mais)
A periodicidade de cobrança é igual a periodicidade de entrega. Porém é possível que a aplicação externa gerencie as assinaturas e seus pagamentos como desejar.

Exemplo: Uma Assinatura Mensal na Wake irá gerar pedidos mensalmente na plataforma, porém a aplicação/conector pode cobrar apenas o primeiro pedido da assinatura x12 e, conforme receber os outros 11 pedidos gerados pela plataforma dentro da assinatura, pode apenas retornar o status de "Pago" (Não fazer a cobrança novamente).
Essa regra configura uma Assinatura Anual, que será cobrada apenas 1 vez, mas o valor do primeiro pedido multiplicado por 12, que equivale aos 12 meses do ano.

Sobre as requisições enviadas para o conector/aplicação, o Checkout monta o carrinho com informações do Pedido e informa se é uma assinatura ou não.
Essas informações são enviadas nos requests /payment e /authorize.
Caso não seja uma assinatura, os campos "primeiroPedidoAssinatura" e "assinatura" irão como "false" e "null", respectivamente.

A chave informada no JSON, é única por loja, pode ser usada como identificador da loja?

Essa chave é dinâmica e altera a cada pedido, não deve ser usada como identificador. nome da loja é informado no campo "loja" do request.

Toda vez que um cliente quiser usar nossa integração, ele terá que seguir por essa configuração customizada?

Em integrações não homologadas (que não são listadas no menu de Conectores) o cliente deverá utilizar Configuração Customizada de Pagamento.

Para integrações homologadas, o cliente irá utilizar o Conector listado no menu e preencher com seus dados.

Onde inserir o QRCode do PIX e/ou Boleto?

Como o response do Custom ainda não permite mais informações além de Status e Mensagem, é necessário que o Parceiro crie um Script para ser utilizado na página de Confirmação. Esse script deve utilizar dados disponibilizados no Carrinho para fazer uma consulta num ednpoint externo do parceiro, que irá retornar com o QRCode, Pix Copia e Cola, Linha digitável, PDF do boleto, etc...

Esse mesmo script deverá renderizar essas informações recebidas na página de Confirmação e exibir para o lojista.

Importante: Como essa busca será feita no front da loja, será necessário liberar a URL no Admin da Plataforma conforme descrito em "Gerenciar Políticas de Segurança".

Como funciona o split de pagamentos? o produto é vinculado ao vendedor? se sim, como configurar?

O Split de Pagamento deve ser gerenciado do lado do Conector.

A plataforma envia os dados dos Produtos e o Centro de Distribuição de cada Produto nas requisições/payment e /authorize.

Com isso, uma vez que os Centros de Distribuição estão cadastrados corretamente na Wake, é possível que o Conector tenha os mesmos Centros de Distribuição, os Recebedores e as Regras de Split cadastrados.

Dessa forma, ao receber a requisição com os produtos e seus CDs, o conector/aplicação poderá endereçar corretamente os valores conforme as regras criadas.

Vale ressaltar que para a Wake o pedido que houver split de pagamento está relacionado a uma transação.

A depender do fluxo (Postback, no caso), como garantir que não vamos perder a sincronia dos eventos, uma vez que o processo não é síncrono?

Como os dados não ficam disponíveis, sugerimos enviar eles apenas para manter a referente para futuras consultas.

Antifraude - Como funciona com o Pagamento Customizado?

Quando o cliente seleciona um Antifraude no Pagamento Customizado, não é utilizado a requisição {URLbase}/payment, mas é feita a requisição usando a {URLbase}/authorize e o processamento do pedido é dividido em 2 etapas: Autorização e Captura.

Além disso o cliente tem 2 possibilidades de Antifraude no momento: Antifraude Manual e Antifraude Clearsale.

Primeiro etapa - Autorização

Uma requisição é feita para o endpoint da aplicação {URLbase}/authorize com todos os campos e informações informadas da documentação (Saiba mais).
Nessa etapa, o conector deve validar o Cartão de crédito utilizado e retornar os status abaixo:

1 - Aguardando Pagamento: Quando o conector não pode informar no response da requisição um status final. Porém é importante enviar o status final (2 ou 4) via Postback;
2 - Não autorizado: Quando o conector valida o cartão e retorna que não foi autorizada a transação;
4 - Autorizado: Quando o conector valida e retorna que o cartão foi Autorizado.

Uma vez retornado o status de "Autorizado", a plataforma seguirá com o pedido conforme o antifraude selecionado pelo cliente.
Se for Antifraude Manual, a plataforma irá aguardar o Lojista atualizar o status do Pedido na Plataforma para "14 - Pedido Aprovado Análise";
Se for Antifraude Clearsale, a plataforma irá enviar o pedido automaticamente para a Clearsale, aguardando o status de Aprovado ou Reprovado.

Segunda etapa - Captura

Quando o pedido é aprovado por qualquer que seja dos Antifraudes, a plataforma irá fazer uma nova requisição para o conector usando {URLbase}/capture, aguardando o status de "Pago" ou "Não autorizado".

📘

Importante

Este fluxo de Antifraude, no Pagamento Customizado, é exclusivamente compatível com o modelo completo de integração e não é suportado no modelo simplificado. Certifique-se de que sua integração esteja configurada conforme o modelo completo para garantir o funcionamento correto deste fluxo de Antifraude.

O Editor HTML serve para incluir os campos obrigatórios para todos os meios de pagamento, como Cartão de crédito, PIX e boleto?

Sim. Veja como configurar este campo na nossa documentação. (Saiba mais)

Qual a funcionalidade do campo "Headers" no Pagamento Customizado?

Os headers são campos inseridos conforme a necessidade do parceiro no formato de "Chave" e "Valor".
Esses headers são enviados no cabeçalho de todas as requisições e podem servir para diversas funcionalidades, como autenticação, informação, etc...

Como é realizada a autenticação de um conector de pagamento, por Auth ou e-mail/token?

Todas as requisições da Versão Completa são enviadas com os "headers" no cabeçalho. Com isso, os parceiros podem inserir os campos de chave e valor para que a autenticação seja feita via header.

A plataforma oferece o serviço de repasse de juros ao comprador? Como funciona o cálculo do parcelamento?

Sim, é possível repassar os juros ao comprador. Veja em nossa documentação como configurar o Parcelamento e os Juros na plataforma. (Saiba mais)

O que são os endereços das requisições? São endereços de Entrega ou Cobrança?

O primeiro endereço informado no modelo trata do “Endereço de Entrega” e o segundo endereço trata do “Endereço de Cobrança”. Note que o segundo endereço está dentro do objeto “Pagamento”.

Os IDs de resposta são os mesmos para todos os meios de pagamento? (PIX, Boleto e Cartão de crédito)

Sim. Seja qual for a forma que o parceiro desejar utilizar o Pagamento Customizado, os status esperados serão sempre os mesmos.

Há um ambiente de Sandbox/Testes para o vendedor validar sua integração sem criar transações de verdade?

O Conector/aplicação pode prover um ambiente de teste para o lojista. Basta desenvolver a aplicação de forma que o lojista possa informar quando está fazendo um pedido para o ambiente de Homologação do Conector ou ambiente de Produção.

Uma possibilidade é o conector/aplicação utilizar os Headers e criar uma Chave chamada "Sandbox" onde o lojista pode inserir o Valor "True" ou "False".
Como esses headers serão enviados na requisição, a aplicação irá receber a requisição na URL que está cadastrada, mas endereçar o pedido para outro ambiente de homologação.

É possível utilizar o Pagamento Customizado sem uma URL cadastrada?

Sim. A plataforma irá apenas fechar o pedido e manter o pedido como "Aguardando Pagamento" até que o Lojista faça a alteração do status do pedido via Admin ou API Pública.

O que é o campo “chave” do payload?

O campo chave é um código único para cada transação realizada. Ela sempre será enviada no Post e deverá ser informada na url do endpoint no Postback.

Campo "Total" da requisição, já inclui descontos, frete, custo de personalização e qualquer outro valor adicional ou subtraído do pedido?

O campo Total é o valor final cobrado do consumidor.

Os usuario.cpf e usuario.cnpj da requisição podem ser enviado com máscara? (Exemplo: 999.999.999-99)

Não. Fazemos um tratamento para que esses valores sejam enviados sem máscara.

Caso a aplicação terceira retorne o status 2 - Não autorizado no responde, o que acontece?

Uma mensagem será apresentada para o Consumidor no Checkout pedindo para revisar os dados do cartão.

O retorno do status no response é importante para o Checkout Online, que irá retornar o status da transação no checkout para o consumidor. O status 2 é para um cenário onde realmente não foi autorizado, isso pode incluir os erros de dados do cartão, uma negativa por risco ou falta de saldo.

Porém esse fluxo é importante pois podem ocorrer erros de digitação, por exemplo, e o consumidor terá a chance de preencher corretamente ou mudar de cartão ainda na tela de Checkout, convertendo mais vendas para o lojista.

Modelo Postback - Em qual cenários mandaríamos novamente o status 1 no postback, dado que não houve uma mudança de status do pedido original?

Disponibilizamos essa opção para casos bem específicos. Porém se não houver alteração no status, podem utilizar o endpoint http://custom.conector.gateway.fbits.net/postback/informacoesadicionais/{chave_transacao} para enviar somente as informações Adicionais, se houverem.

Informações adicionais - Onde esses dados enviados serão utilizados/exibidos? (será exibido para o comprador ou para o lojista, por exemplo)

As informações adicionais serão apresentadas no detalhe do pedido no Admin para o Lojista. Essas informações relacionadas à transação servirá para várias validações, como para conciliação financeira, por exemplo.

É possível utilizar o endpoint com Status + Informações adicionais, ou o endpoint só com as Informações adicionais.

Exemplos:

{
	"informacoesAdicionais": [
	{
		"Nome": "NSU",
		"Valor": "E1BF1E6BA60C88891FC3A5A33D4DADA"
	},
	{
		"Nome": "TID",
		"Valor": "88884849848446846848"
	}						
	]
}

A Wake possui certificação PCI?

Não está nos planos possuir essa certificação. Por este motivo, orientamos nossos parceiros a tokenizar corretamente as informações dos dados de cartões dos clientes e armazenar corretamente nas aplicações somente se possuírem tal certificação.

Dentro do form do objeto pagamento tem as informações do pagamento como bandeira do cartão, parcelamento e etc?

Bandeira do cartão não é enviado como padrão. Porém os dados de Parcelamento e outras informações solicitadas no formulário são enviadas na requisição, dentro do objeto pagamento.form.

Porém é possível utilizar scripts que identifiquem a bandeira e enviem essa informação no form.

Em caso de Timeout onde a plataforma faz a requisição e não tem o retorno, qual o comportamento da plataforma?

O pedido irá permanecer como "Aguardando Pagamento" até que o lojista realize a alteração do status do pedido via Admin ou API Pública.

Como listar meu Conector desenvolvido no Pagamento Customizado na lista de Conectores no Admin da Wake?

Entre em contato com nosso time de Parcerias para saber mais.

Como redirecionar o cliente para um checkout externo?

Na págna de fechamento, após o usário pagar o pedido, o custom envia os dados para o terceiro e o app do terceiro recebe os dados do pedido.

Na página de confirmação, deve ser inserido um script do parceiro, onde esse Js redireciona para o ambiente externo com as informações necessárias e após isso o cliente é redirecionado para o site do lojista novamente.

Fluxo na prática:

Para inserir um script na página de confirmação de pagamento, utilize o Gestor de Scripts, saiba mais acessando a documentação do Gestor de Scripts

Updated 5 months ago