Validação de CPFs nas compras com cartão de crédito

A validação de CPFs é uma atividade importante para facilitar a validação dos dados de compradores, uma parte importante de uma estratégia de segurança no processamento de vendas pela Internet usando cartões de crédito.

O gmxCheckout pode realizar a consulta de CPFs em base nacional Receita Federal (RF) sempre que uma nova venda ou uma nova recorrência for gerada. Para isso basta informar os campos venda.consumidor.cpf e venda.consumidor.dataNascimentoStr na requisição e solicitar a ativação da consulta de CPF para a equipe de suporte (para recorrências, substituir a palavra venda por recorrência nesses campos).

Vale lembrar que a consulta só é possível com o envio da data de nascimento. Os formatos aceitos são yyyy-MM-dd (ISO) ou dd/MM/yyyy, onde yyyy representa o ano com 4 dígitos, MM representa o mês com 2 dígitos e dd representa o dia com 2 dígitos. Todos numéricos.

As informações retornadas na resposta da requisição de venda ou recorrência seguem abaixo. Para recorrência basta mudar a palavra venda para recorrência.

venda.cliente.cpfConsultado.nome – Nome obtido pela consulta
venda.cliente.cpfConsultado.cpf – CPF obtido pela consulta, idêntico ao enviado
venda.cliente.cpfConsultado.dataNascimento – Data de Nascimento – Pode divergir um dia para mais ou para menos devido a problemas cadastrais do governo
venda.cliente.cpfConsultado.dataInscricao – Data de inscrição do CPF na base da RF
venda.cliente.cpfConsultado.regular – Campo booleano (true ou false) indicando se o CPF está regular na RF

Além da consulta de dados, é possível ativar a validação. O CPF é validado algoritmicamente para verificar se os dígitos verificadores estão corretos e é então consultado na base da RF. Caso o CPF não exista ou esteja em estado irregular, a transação será negada com o código LR GMX3 para ‘CPF não encontrado’ ou GMX4 para ‘CPF inativo’

Também existe a possibilidade de se ativar a validação da data de nascimento recebida junto com o CPF. Essa validação é cumulativa com a acima. Além de validar o número, existência e regularidade do CPF, o GMX irá comparar a data de nascimento recebida na requisição de venda com a data retornada da consulta. Se a data de nascimento for divergente, a transação será negada com o código LR GMX5 ‘Data de nascimento divergente’. Como a base do governo possui erros com datas de nascimento, geralmente 1 dia a mais ou a menos, o GMX considera essa variabilidade e se a diferença entre a data de nascimento informada e a data obtida na consulta divergir em mais ou menos 1 dia, ela será considerada como correta.

As informações obtidas ao consultar o CPF de um cliente também podem ser visualizadas ao entrar nos detalhes de uma venda na interface web.

Dados da consulta de CPFs

Dados da consulta de CPFs

As informações acima também se aplicam a CNPJs. O CNPJ deverá ser informado no lugar do CPF e a data de abertura da empresa deverá ser informada no lugar da data de nascimento.

Esta é uma maneira eficiente de automatizar a consulta de CPFs e oferece mais uma maneira de prevenir o processamento de transações com potencial de gerar contestações.

Outras medidas preventivas também podem ser adotadas, dentre elas a Lista de Bloqueios, bloqueio automático de clientes com várias tentativas com cartões de crédito diferentes, analise do histórico de compras de clientes, a captura posterior de transações (após validação de dados), a tokenização de cartões e o 3D Secure para a autenticação de transações, permitindo o liability shift, ou seja, passar a responsabilidade de lidar com o recebimento de clientes que tentam contestar transações para o arranjo de pagamentos via cartão de crédito, composto pela Adquirente (ex: Cielo, Rede, …), bandeira (Visa, Mastercard, …) e instituições emissoras dos cartões de crédito (ex: Bancos, Fintechs, …).

Temos outros posts explicando cada um dos mecanismos acima em detalhes.

Vale lembrar que a consulta de CPFs é uma opção interessante porém a validação pode gerar falsos-positivos devido a falta de atenção dos clientes em disponibilizar essas informações durante uma compra na internet mas, por outro lado, pode ser considerado uma atitude negligente de qualquer estratégia de segurança não implantar uma consulta de CPFs.

E assim como as outras, para que ela tenha uma melhor eficácia, seu uso não pode ser divulgado pois caso o cliente saiba que isso está sendo usado ele pode evitar ser identificado, usando guias anônimas nos navegadores, mudando de e-mail e de cartões de crédito.

Como já alertado em outros posts, vale observar que ao implantar técnicas automatizadas de prevenção de fraudes, é possível que tentativas de compra legítimas sejam consideradas como ilegítimas e tentativas ilegítimas sejam consideradas legítimas. O desafio é minimizar a taxa de erros de ambas.

Se você tiver se interessado e quiser maiores informações, continue nosso blog ou entre em contato conosco que teremos o maior prazer em sanar suas dúvidas e te mostrar como o gmxCheckout é uma boa opção para você e para os seus negócios.

Boas vendas!

Usando a Lista de Bloqueios para prevenir contestações

Contestações ou chargebacks são realizadas por portadores de cartões de crédito quando os mesmos não reconhecem alguma compra realizada. E isso só pode ser feito para compras via internet não autenticadas. Este é um mecanismo de segurança que visa permitir que consumidores tenham uma segurança maior caso os dados dos seus cartões de crédito sejam extraviados, prevenindo grandes perdas financeiras.

Mas infelizmente essas perdas podem recair sobre os estabelecimentos comerciais então medidas preventivas são necessárias.

Segundo a Cielo, seguem algumas medidas preventivas importantes https://developercielo.github.io/manual/prevencao-fraudes

Dentre essas medidas temos o estabelecimento de uma “Blacklist” contendo informações a respeito de fraudadores. O gmxCheckout também possui a verificação automática de CPF, regras para bloqueio automático de clientes com várias tentativas com cartões de crédito diferentes, permite a exploração do histórico de compras de clientes, assim como captura posterior de transações (após validação de dados), a tokenização de cartões e o 3D Secure para a autenticação de transações, permitindo o liability shift, ou seja, passar a responsabilidade de lidar com o recebimento de clientes que tentam contestar transações para o arranjo de pagamentos via cartão de crédito, composto pela Adquirente (ex: Cielo, Rede, …), bandeira (Visa, Mastercard, …) e instituições emissoras dos cartões de crédito (ex: Bancos, Fintechs, …).

Teremos outros posts explicando cada um dos mecanismos acima em detalhes. Hoje apresentaremos a Lista de Bloqueios do gmxCheckout.
A lista de bloqueios é um recurso que pode ser ativado ou desativado para seu estabelecimento e é o primeiro mecanismo para protegê-lo de fraudes. O seu propósito é permitir que perfis de clientes prejudiciais a empresa sejam detectados e não possam mais comprar. É uma boa prática que todo estabelecimento possua um controle dos clientes que já fizeram algum tipo de contestação ou que são classificados com o potencial de realizá-la novamente. O ideal é realizar a venda para esses clientes apenas através da transação autenticada (utilizando o 3D Secure) para poder fazer o liability shift para o arranjo de pagamentos, que está melhor equipado para lidar com esses casos.

Vale lembrar que a lista de bloqueios não é um mecanismo de grande assertividade mas não utilizá-lo, por outro lado, pode ser considerado uma atitude negligente de qualquer estratégia de segurança.

Para que ela tenha uma melhor eficácia, seu uso não pode ser divulgado pois caso o cliente saiba que isso está sendo usado ele pode evitar ser identificado, usando guias anônimas nos navegadores, mudando de e-mail e de cartões de crédito.

A lista de bloqueios armazena o nome, e-mail e hash do cartão de crédito utilizado.

Existem 2 formas de se adicionar um cliente e cartão de crédito à lista de bloqueios
1) Mudar o estado de um cartão de crédito para bloqueado. Isto também implicará a inclusão do e-mail e do nome do cliente que usou o cartão de crédito para a lista de bloqueios
2) Marcar uma venda como Chargeback. Haverá as mesmas implicações acima.

Ambas as operações podem ser realizadas através do front-end web quanto através da nossa API.

Marcar uma venda como contestada

Marcar uma venda como contestada

Bloquear Cartão de Crédito

Bloquear Cartão de Crédito

Além de manter uma lista dos clientes que contestaram compras junto aos bancos emissores, novas vendas que forem submetidas contendo o mesmo e-mail ou o mesmo cartão de crédito presentes na lista de bloqueios, serão rejeitadas imediatamente com o código LR GMX1 (e-mail na lista de bloqueios) ou GMX2 (cartão de crédito na lista de bloqueios). Observando apenas que para isso funcionar, as regras de segurança do uso da lista de bloqueios deverão estar ativadas. Solicite ativação através do nosso suporte

Também é possível ativar a inclusão automática de cartões e e-mails quando houver 3 (três) ou mais reprovações consecutivas (com cartões diferentes) para o mesmo e-mail.

Caso o cliente tente utilizar um novo cartão porém o e-mail utilizado já esteja na lista de bloqueios, a venda será rejeitada e novo cartão será automaticamente inserido na lista de bloqueios para aquele cliente. Caso seja utilizado um cartão bloqueado com um e-mail não bloqueado, a venda não será aprovada e o e-mail também será adicionado na lista de bloqueios automaticamente.

É possível desativar ou reativar registros da lista de bloqueios, permitindo assim que sejam realizadas compras por clientes que possam ter entrado na lista de bloqueios de forma automática.

Lista de Bloqueios

Lista de Bloqueios

Vale observar que ao implantar técnicas automatizadas de prevenção de fraudes, é possível que tentativas de compra legítimas sejam consideradas como ilegítimas e tentativas ilegítimas sejam consideradas legítimas. O desafio é minimizar a taxa de erros de ambas.

Se você tiver se interessado e quiser maiores informações, continue nosso blog ou entre em contato conosco que teremos o maior prazer em sanar suas dúvidas e te mostrar como o gmxCheckout é uma boa opção para você e para os seus negócios.

Boas vendas!

O que é necessário para começar a vender com o gmx ?

Muitos clientes nos fazem a pergunta acima então vamos deixar aqui no nosso blog tudo o que você precisa para começar a vender com o gmxCheckout.

O processamento das transações de venda via cartão de crédito na Cielo e Rede só podem ser feitas após dois passos fundamentais:

  1. Credenciamento: É o cadastro da pessoa ou empresa junto a adquirente (Cielo ou Rede). Se você já trabalha com maquinetas de cartão, podemos considerar que você já é credenciado.
  2. Homologação: É a afiliação a um plano de e-commerce junto a adquirente. Normalmente não cobra mensalidades, cobrando apenas um percentual sobre cada venda realizada. O processo de homologação envolve definir as APIs e serviços que serão disponibilizados pela adquirente, configurar a integração entre o gmx e a adquirente e realizar testes de homologação por ambas as equipes (gmx e adquirente).

A Cielo aceita credenciar e homologar pessoas físicas ou jurídicas porém a Rede trabalha apenas com pessoas jurídicas, ou seja, você precisa ter uma empresa aberta com CNPJ ativo.

Segue então os passos

  1. Decidir se suas vendas serão feitas através de uma pessoa física ou jurídica
  2. Ter uma conta bancária aberta em nome da pessoa física ou jurídica em um dos bancos abaixo, lembrando que contas conjuntas podem não ser aceitas.
  3. Entrar no site https://www.gmxcheckout,com.br , clique em “Inscreva-se Agora!” e selecione um dos planos
    1. Caso já possua as chaves de integração para integrar com Cielo ou Rede, ou seja, já é credenciado e homologado, selecione o plano “Simples”
    2. Se já for credenciado mas nunca usou o e-commerce da Cielo ou da Rede, escolha o plano “Homologação”
    3. Se ainda não teve nenhum relacionamento com Cielo ou Rede, escolha o plano “All Inclusive”
  4. Faça o pagamento do plano selecionado. Você receberá um e-mail de confirmação de compra e outro com o usuário e senha temporária para logar no nosso sistema.
  5. Faça o login no gmxCheckout e preencha os dados que vamos precisar para fazer o credenciamento, homologação e configuração da sua conta, dependendo do plano que você selecionou!
Código do Banco Bancos Autorizados à Prestação de Serviços de Credenciamento
001

237

399

104

341

033

041

756

748

634

021

745

389

218

707

246

084

003

755

743

224

741

376

082

213

004

Banco do Brasil

Banco do Bradesco

Banco HSBC

Caixa Econômica Federal

Banco Itaú

Banco Santander

Banco do Estado do Rio Grande do Sul – Banrisul

Banco Cooperativo do Brasil – Bancoob

Banco Sicredi

Banco Triângulo – Tribanco

Banco do Estado do Espírito Santo – Banestes

Banco Citibank

Banco Mercantil do Brasil – BMB

Banco Bonsucesso

Banco Daycoval

Banco ABC Brasil

Cooperativa de Crédito do Norte do Pará – Unipride

Banco da Amazônica – BASA

Bank Of America

Banco Semear

Banco Fibra

Banco Ribeirão Preto

JP Morgan

Banco Topazio

Banco ARBI

Banco Nordeste

422

070

025

604

655

Banco Safra

Banco de Brasília – BRB

Banco Alfa de Investimento

Banco Industrial do Brasil

Banco Votorantim

Se ficou alguma dúvida entre em contato com a nossa equipe !

Boas vendas!

Prevenção de ataques de força-bruta

“Ataque de força bruta” é um método utilizado por potenciais fraudadores para obter informações válidas de pagamento com a intenção de comprar bens e serviços e não pagar pelos mesmos, prejudicando empresas e consumidores que possuem cartões de crédito.

Com dados válidos de cartões de crédito, fraudadores realizam compras pela internet, recebem os produtos comprados mas a conta vai para o dono do cartão de crédito utilizado. Isso é geralmente chamado de “clonagem de cartões de crédito” e acarreta grandes prejuízos.

E como isso funciona ?

Utilizando um computador conectado a internet, fraudadores utilizam scripts desenvolvidos em alguma linguagem de programação que realizam centenas de tentativas de pagamentos por minuto, até obterem uma resposta positiva do e-commerce vítima do ataque.

Isso pode levar a adquirente (ex: Cielo, Rede e outras) a bloquear o estabelecimento até que medidas preventivas sejam adotadas para evitar o acesso de páginas de pagamento por bots utilizados para gerar uma base de dados de cartões de créditos que foram clonados.

Como funciona com o gmxCheckout ?

O gmxCheckout está preparado para prevenir ataques de força-bruta para clientes que utilizam nossa API e para aqueles que usam as páginas de pagamento disponibilizada pela a nossa plataforma.

Caso você utilize as nossas páginas de pagamento dentro do próprio sistema, isso já está automaticamente ativado para você mas caso utilize a nossa API o processo é um pouco diferente.

Vendas via Página de Pagamento no sistema

Caso o fraudador faça mais que 3 tentativas de pagamento sem sucesso na última hora, o sistema solicitará que o cliente faça algo que somente uma pessoa poderia fazer, como identificar todas fotos com veículos dentre um conjunto, identificar palavras em imagens, dentre outras – saiba mais em https://pt.wikipedia.org/wiki/CAPTCHA.

Caso as tentativas com falha ultrapassarem o número 5 nos últimos 60 minutos o sistema não processará a transação.

Vendas via chamadas de API

Para os clientes que usam a nossa API, o processo tem mais detalhes então fique atento.

Mas antes de falar da regra de bloqueio, vamos apresentar para você uma funcionalidade importante. A validação de IPs de clientes.

No gmxCheckout, é possível aumentar o nível de segurança do seu estabelecimento restringindo os endereços IPs dos servidores que submetem as transações de vendas com cartão de crédito. Assim somente os seus servidores poderão tentar processar transações junto a gmxCheckout, evitando o problema de ataque de força-bruta.

Para isso, basta acessar “Configurações” -> “Dados da Empresa”, clicar na aba “Avançado” e selecionar “Valida o IP do Cliente para chamadas via API?” e clicar em “Salvar”.

Validação de IPs para chamadas via API

Mas mesmo que você não tenha feito isso ainda, para uma maior proteção do seu estabelecimento junto as adquirentes, se recebermos mais que 5 transações que forem negadas nos últimos 60 minutos, iremos impedir que as próximas vendas sejam processadas até que esse número caia. Isso ocorre a medida que o tempo passa, pois a janela de tempo é dinâmica.

Então, para que isso não ocorra e você não perca vendas, recomendamos que cadastre os endereços IP dos servidores que enviam as requisições para o gmxCheckout em “API / Integração”-> Liberação de IPs.

Liberação de IPs para API

Como já foi dito, se isso não for feito, as vendas poderão ser negadas se houver mais do que 5 transações com erro na última hora.

Caso o fraudador ultrapasse 5 tentativas sem sucesso nos últimos 60 minutos o sistema não processará a transação e retornará a mensagem de erro
“Ultrapassou o número de requisições 5 em 1 hora(s). Cadastre o IP origem em API/Integração -> Liberação de IPs.”

Com o cadastro do IP dos seus servidores suas transações não serão mais bloqueadas e isso pode ser um problema pois a sua proteção contra ataques de força-bruta não estará mais ativa.

Mas como faço para as duas proteções e sem o risco de perder vendas legítimas ?

É simples: tendo ativado a validação de IPs e cadastrado os IPs dos seus servidores, precisamos sua aplicação passe a nos enviar o endereço IP e o browser do cliente que preencheu os dados de venda utilizando os campos abaixo:

Se estiver gerando uma venda, inclua os campos venda.ipOrigem e venda.browser.

Se estiver gerando uma recorrência considere os campos recorrencia.ipOrigem e recorrencia.browser.

Dessa forma faremos a validação e o bloqueio considerando o IP de quem estiver fazendo o pagamento usando o cartão de crédito.

É isso por hoje. Se tiverem quaisquer dúvidas entrem em contato com o nosso suporte clicando em “Precisando de Ajuda?” ou enviem um e-mail para o nosso suporte em [email protected]

Para mais informações, estamos compartilhando o Comunicado da VISA sobre Ataques de força-bruta.

Boas vendas!

Alterar descrição na fatura do cliente

É muito comum no Brasil o uso de nomes fantasias em empresas, de forma que a razão social seja algo mais formal e que os nomes comerciais ou produtos tenham um enfoque mais relacionado ao marketing envolvido.

Para exemplificar, consideremos um cliente nosso cuja a razão social é Pagamento Expresso Ltda. mas o seu principal produto tenha o nome Delivoro. A empresa deseja que o nome Delivoro seja exibido nas faturas dos cartões de crédito dos clientes pois fica mais fácil de relacionar a despesa com um produto que o cliente conhece e usa, ao invés do nome da empresa, que não é tão amplamente divulgado quanto o nome do próprio produto.

O problema é que ao homologar um estabelecimento junto a CIELO, não é mais possível solicitar que o nome da empresa apareça de outra forma na fatura do cartão de crédito do cliente. O padrão é que seja exibida um subconjunto da razão social, composta por até 13 caracteres alfa-numéricos.

Felizmente é possível enviar um parâmetro para a API durante o processamento de uma venda que determinará como aquela cobrança aparecerá na fatura do cartão de crédito do cliente. Esse parâmetro é o venda.descricaoFatura.

Mas ter que sempre enviar esse parâmetro é uma estratégia que possui um ponto de falha. Caso o desenvolvedor se esqueça de incluir esse campo nas transações, o nome que apareceria na fatura do consumidor seria a razão social.

Para evitar esse problema, agora é possível digitar uma descrição padrão nas faturas dos clientes acessando o menu Configurações -> Dados da Empresa e clique na aba Avançado.

Alterar a descrição padrão nas faturas

Aí basta digitar o nome desejado no campo Descrição na Fatura, lembrando que apenas letras, números e espaços em branco são permitidos, não podendo digitar símbolos como pontos, por exemplo.

Fica mais essa dica para os nossos usuários. Boas vendas !

Atualização de número de cartão em recorrência

Uma funcionalidade interessante que o gmxCheckout oferece é a possibilidade de se trocar o cartão que está sendo utilizado para processar uma recorrência, sem a necessidade de se criar uma nova recorrência.

Para isso basta submeter uma nova transação de venda e informar o número identificador da recorrência, o nome, CPF e os dados do cartão na requisição para a nossa API POST e/ou REST.

Se a transação for bem sucedida, ocorrerá a atribuição do novo cartão de crédito a recorrência. Caso falhe, o cartão utilizado para cobrar aquela recorrência não será alterado. É possível submeter transações de troca de cartão de crédito quantas vezes forem necessárias, embora na prática é usual que se faça isso somente quando necessário.

Existem dois cenários de uso da troca de um cartão. Uma ocorre quando a recorrência já venceu, teve pagamentos reprovados e a cobrança não ocorreu no dia base da recorrência o dia. A outra ocorre quando a troca do cartão foi feita sem que a recorrência tivesse vencido.

No primeiro caso (recorrência vencida), deve-se realizar a troca do cartão, conforme o exemplo abaixo, sem informar o campo venda.capturaAuto, ou informando o mesmo com o valor true. Isso fará com que a venda seja cobrada no novo cartão imediatamente e o dia base da recorrência seja atualizado para o dia atual.

Por exemplo, suponha que a recorrência tenha sido criada no dia 14 de fevereiro de 2016 e que as cobranças mensais foram realizadas com sucesso até 20 de março de 2017. Considere que o cartão era válido até o mês de março de 2017, então houveram 2 tentativas de cobrança nos dias 20 e 21 de abril e que o gmxCheckout enviou a notificação de falha de cobrança da recorrência para o sistema do cliente duas vezes. O sistema do cliente solicitou que o consumidor disponibilizasse um novo cartão de crédito. O consumidor fez a troca do cartão no dia 22 de março e a transação foi processada com sucesso. Nesse caso, o novo dia base da recorrência será o dia 22 para evitar que hajam duas cobranças em período inferior a 30 dias.

Segue abaixo um exemplo utilizando o cartão de crédito teste disponibilizado pela CIELO para a troca do cartão em que se deseja que o cliente seja cobrado pela transação no momento da troca do cartão e o dia base seja corrigido.

curl -X POST “https://www.gmxcheckout.com.br/txn/post” \
-d “restApi=true” \
-d “empresa.hashEmpresa=bb9d89029ue771” \
-d “venda.recorrencia.idRecorrencia=00012” \
-d “cartaoCredito.numero=4012001037141112” \
-d “cartaoCredito.bandeira=visa” \
-d “cartaoCredito.mesValidade=05” \
-d “cartaoCredito.anoValidade=2018” \
-d “cartaoCredito.codSeguranca=123” \
-d “venda.consumidor.nome=Teste” \
-d “venda.consumidor.cpf=12312312312” \
-d “venda.valor=9800”

Na segunda situação, o consumidor realiza a troca do cartão antes de ocorrer o vencimento da recorrência. Nesse caso é desejável que não haja seja gerado débito no cartão do cliente, apenas que o cartão seja substituído e que o dia base de cobrança não seja alterado.

Para isso, considere o exemplo abaixo, que utiliza o campo venda.capturaAuto=false para realizar uma troca sem cobrança no cartão.

curl -X POST “https://www.gmxcheckout.com.br/txn/post” \
-d “restApi=true” \
-d “empresa.hashEmpresa=bb9d79969fe771” \
-d “venda.recorrencia.idRecorrencia=63783” \
-d “cartaoCredito.numero=4012001037141112” \
-d “cartaoCredito.bandeira=visa” \
-d “cartaoCredito.mesValidade=05” \
-d “cartaoCredito.anoValidade=2018” \
-d “cartaoCredito.codSeguranca=123” \
-d “venda.consumidor.nome=Teste” \
-d “venda.consumidor.cpf=12312312312” \
-d “venda.valor=100”
-d “venda.capturaAuto=false”

Vale destacar que, mesmo que não seja gerado um débito no cartão do cliente, o sistema tentará realizar uma autorização no cartão do cliente para verificar se o cartão informado é válido antes de atualizar a recorrência no sistema. Por isso recomendamos que seja utilizado um valor simbólico para o processamento, de forma a não inviabilizar a verificação ao exceder o limite do cartão de crédito do cliente, levando ao um falso-negativo onde o cartão é válido mas a troca não foi autorizada pois o valor utilizado para verificar o cartão foi muito alto.

É isso por ora. Fiquem ligados me mais novidades do gmxCheckout nos próximos posts.

Mais algumas melhorias

Hoje por volta das 16:00 publicamos mais melhorias a pedido dos nossos clientes.

  • Captura de leads na página default de oferta. Agora é possível remunerar os afiliados por  cada lead que se cadastrar através do seu link de afiliado.
  • Permitir alterar dia base da recorrência pela interface administrativa.
  • Adicionamos a opção de limitar quantidade de vendas de uma oferta.
  • Adição do campo venda.produto ao notificar uma venda via requisição HTTP (também conhecido como urlCampainha) e nas integrações da oferta.
  • Melhorias no retorno de erros via API REST/JSON.
  • Exibir dados dos adquirentes ativados (default e backup) no header do painel administrativo.
  • Contagem de visualizações na página da oferta.
  • Melhoria nas listagem de comissões dos afiliados.

Agradecemos aos clientes que sempre nos solicitam novas funcionalidades, tornando o gmxCheckout uma plataforma completa de pagamentos digitais.

 

Atualizações pequenas mas importantes

Se você esta entrando pela primeira vez no nosso blog talvez não entenda todas essas informações/melhorias deste post, mas hoje por volta das 10:30h o gmxCheckout passou por um processo de atualização. Liberamos algumas novas funcionalidades e correções que deixaram nossos clientes mais satisfeitos.

  • Galeria de imagens e mensagem de devolução de dinheiro em 30 dias caso o cliente não goste no caso de uso de ofertas.
  • Agora as mensagens de impossibilidade de cancelamento de uma transação por parte do adquirente tem mensagens diferentes para cada um deles (CIELO e REDE).
  • Link para detalhes da recorrência dentro do detalhes de venda para facilitar a navegação dentre as suas vendas e recorrências.
  • Agora é possível realizar testes no ambiente de teste da CIELO e REDE mais facilmente através do gmxCheckout mesmo a partir dos servidores de produção, útil para fase de testes da criação da páginas de pagamento.
  • Ao receber uma requisição de venda ou recorrência de uma página de checkout transparente, torna-se obrigatório o envio dos parâmetros restAPI=true ou urlBack e urlFrom.
  • Melhoria na logica de criação de recorrência com data futura que faça uma transação teste no cartão de credito para validar autenticidade do cartão de crédito utilizado.
  • Possibilidade de criar ofertas com pagamento recorrente e com inicio de cobrança no futuro.
  • Para evitar notificações duplicadas ao criar uma nova recorrência e se estiver utilizando a opção de API REST, não é mais chamada a URL campainha no primeiro processamento para evitar informar o status de uma transação de forma duplicada.

Algumas dessas funcionalidades foram sugestões de clientes e outras foram melhorias antecipadas pela nossa equipe. Com isso estamos sempre construindo um produto abrangente de forma a atender a todos.

E por hoje é só pessoal,  vejo vocês nos próximos posts.

Novos campos na notificação de venda realizada

O gmxCheckout possui uma funcionalidade que permite notificar outros sistemas quando uma venda é realizada. Através dessa funcionalidade o nosso sistema faz uma requisição HTTP/POST para qualquer outro sistema com as informações da venda.

Este recurso é bastante utilizado pelos nossos clientes que possuem suas próprias páginas de pagamento e que estão hospedadas fora da nossa infraestrutura.

Segue um exemplo da página de pagamentos do KlickMembers um cliente gmxCheckout: https://pagamento.ignicaodigital.com.br/klickmembers/expert/

Pagina de pagamento Klickmembers

Pagina de pagamento Klickmembers

Para utilizar esta funcionalidade basta adicionar um campo hidden contendo a URI (Universal Resource Identifier) a ser invocada quando uma venda for processada. Até mesmo as vendas reprovadas são notificadas através desse mecanismo. Segue um exemplo de como utilizar essa funcionalidade abaixo.

Codigo-fonte exemplo de formulario de pagamento do gmxCheckout

Código-fonte exemplo de formulário de pagamento do gmxCheckout

As seguintes informações são enviadas para o destino HTTP definido no campo venda.urlCampainha

venda.dataRegistro – data do processamento da venda no formato dd/MM/yyyy. Alfa-numérico.
venda.valor – valor cobrado do cliente no formato String e sem ponto (ex: 12345 significando R$ 123,45).
venda.valorCobrado – valor cobrado do cliente no formato numérico (ex: 123.45 significando R$ 123,45).
venda.idVenda – número identificador da venda no gmxCheckout. Numérico.
venda.idVendaEmpresa – número identificador da venda no sistema do cliente. Alfa-numérico.
venda.status – Estado do processamento na adquirente: APROVADA: 5, REPROVADA = 6, CAPTURADA = 1, ERRO DE COMUNICAÇÃO = 7. Numérico.
venda.tid – ID da Transação (CIELO) ou código de autorização (REDE). Idenfica unicamente a transação na adquirente. Alfa-numérico.
venda.nsu – NSU (CIELO) ou NUMCV (REDE) controle interno da adquirente, utilizado para agrupar lógicamente as transações. É informado pela adquirente para transações APROVADAS ou CAPTURADAS.
venda.lr – Código que informa a razão da reprovação de uma transação. Teremos um novo post para isso em breve para CIELO e REDE. Numérico.
venda.lrDescricao – Descrição da causa da reprovação de uma transação.
venda.lrOrientacao – Orientacao para o cliente que está efetuando a tentativa de pagamento.
venda.cartaoCredito.numeroMask – Número do cartão de crédito, com apenas os 4 últimos dígitos.
venda.formaPagamento – Bandeira do cartão de Crédito utilizado
venda.cliente.idClienteEmpresa – Número identificador do cliente no sistema do cliente
venda.msgErro – Mensagem de erro, se ocorrer algum problema com o processamento da transação. A descrição e a orientação LR são acrescentadas a esse campo.

Atendendo a pedidos, acrescentamos mais dois campos que estão presentes na resposta da CIELO e deixamos a disposição dos nossos clientes.

venda.arp – Código de autorização retornado pelo banco emissor do cartão.
venda.eci – Eletronic Commerce Indicator. Retornado apenas pela CIELO. Representa o quão segura é uma transação. Esse valor deve ser levado em consideração pelo cliente para decidir sobre a captura da transação.

Seguem os possíveis valores que esse campo pode assumir:

AUTENTICADO = 1: O consumidor digitou os dados do cartão, foi encaminhado para o sistema de autenticação do banco e digitou a senha do cartão corretamente.

BANCO EMISSOR NÃO SUPORTA = 2: O banco emissor do cartão de crédito não tem suporte a autenticação via Internet

AUTORIZADO SEM AUTENTICAÇÃO = 3: O cliente gmxCheckout optou por não solicitar a Autenticação da transação, aprovando sem a necessidade de senha. É o caso mais comum.

AUTENTICAÇÃO FALHOU = 4: O consumidor digitou os dados do cartão, foi encaminhado para o sistema de autenticação do banco e digitou a senha do cartão porém a senha não confere com a senha do cartão.

Mas o que significa Captura ?

Uma transação com cartão de crédito possui duas fases distintas:

  1. Autorização: A transação, com as informações do cartão de crédito e do pedido, é submetida para a adquirente. A adquirente irá verificar a validade do cartão e a existência de limite para a compra. Havendo limite, este é alocado para esta compra e a transação entra no estado AUTORIZADA. Transações podem permanecer nesse estado por até 5 dias na CIELO e até as 23:59 do dia atual na REDE. Um fato muito importante é que caso a transação não seja capturada até o prazo máximo acima, a mesma será automaticamente cancelada pelo banco emissor e o limite alocado se torna disponível novamente para o cliente.
  2. Captura: A transação autorizada pode ser capturada e o débito no cartão de crédito do cliente é confirmado. Este é o estágio final e confirma de fato a compra.

O padrão do gmxCheckout é operar com a Captura Automática, a menos que o cliente queira que a transação seja apenas autorizada num primeiro momento e depois capturada.

Voltando aos novos campos: Considerando uma transação com captura manual e havendo a falha de autenticação no cartão, o cliente gmxCheckout pode optar por não capturar a transação e não aprovar a venda. Transações autenticadas são menos suscetíveis a contestações junto aos bancos emissores.

 

Como fazer a primeira venda ?

O gmxCheckout é uma plataforma transparente de pagamento onde os valores são depositados diretamente na conta do produtor e para realizar a primeira venda é necessário que o produtor tenha preenchido os dados da sua empresa no primeiro acesso ao sistema e que a homologação junto a CIELO e/ou Rede tenha sido completada com sucesso.

A partir daí, é possível criar a primeira página de pagamento em alguns minutos. Segue um passo-a-passo que pode ajudar a compreender como é simples criar uma página de venda com suporte a afiliados.

Tendo feito o login no sistema, clique em Páginas de pagamento => Ofertas e depois em “Nova Oferta”.

Adicionar oferta

Preencha os campos apresentados na aba Oferta. Em caso de dúvidas do que deve ser colocado em cada campo, passe o mouse sobre o ícone ao lado do nome do campo para obter mais informações.

Clique na aba Pagamento e defina como funcionará o parcelamento e o pagamento de comissões a afiliados.

Opções sobre Parcelamento, comissões de afiliados, etc

A partir desse ponto, sua página de pagamento já funciona sem problemas. Caso queira limitar o período de exibição da sua oferta, defina uma data de início e de término para a oferta, assim como os textos que serão exibidos antes da página estar aberta ou após o seu fechamento.

É possível adicionar testemunhos com fotos na aba Testemunhos e adicionar um vídeo explicativo na aba Vídeo ou até mesmo inserir um código de rastreamento do Google Analytics na aba Avançado.

Para finalizar, clique em Salvar.

Ofertas ativas

Serão exibidas as ofertas. Para cada uma será exibido um gráfico e logo abaixo o faturamento, os links para a página da oferta e para a retirada de link de afiliado. Também é possível acompanhar os afiliados que já retiraram seus links, as comissões a serem pagas para os afiliados, as integrações com outros sistemas como área de membros e e-mail marketing.

Os links para as ofertas são links minificados como o link a seguir https://gmx.to/HF13OC

Página de pagamento

Nos próximos posts, ensinaremos como o afiliado pode retirar seu link de afiliado e como as comissões são contabilizadas e como as integrações podem ser configuradas.