Certificado SSL – O que é?

cyber-security-2296269_1280

Secure Socket Layer (SSL) é um padrão global em tecnologia de segurança desenvolvida pela Netscape em 1994. Ele cria um canal criptografado entre um servidor web e um navegador (browser) para garantir que todos os dados transmitidos sejam sigilosos e seguros. Milhões de consumidores reconhecem o “cadeado dourado” que aparece nos navegadores quando estão acessando um website seguro.

Quando escolher ativar o SSL no seu servidor web você terá que responder algumas questões sobre a identidade do seu site (ex: a URL) e da sua empresa (ex: a razão social e o endereço). Seu servidor web então criará duas chaves criptográficas – a Chave Privada (Private Key) e a Chave Pública (Public Key). Sua Chave Privada não possui esse nome à toa – ela deve ser mantida privada e segura. Já a Chave Pública não necessita ser secreta e deve ser colocada na CSR (Certificate Signing Request) – um arquivo de dados contendo os detalhes do site e da empresa.

A comunicação entre o site e servidor fica protegida com um certificado criptografado, impedindo que os dados sejam interceptados através de phishing e sites fraudulentos. Assim, dados como login, formulários, e-mails e transações com cartão de crédito são transmitidos de forma segura. O objetivo de um certificado SSL na verdade é impedir que pessoas mal-intencionadas possam capturar informações confidenciais dos usuários, como os dados de acesso na área do cliente em sites de compra ou até mesmo números e senhas dos cartões de crédito.

Esse tipo de tecnologia baseada em criptografia é cada vez mais adotado, principalmente em aplicações financeiras e lojas virtuais onde dados importantes e confidenciais dos visitantes são enviados a todo o momento.

Por que eu preciso de SSL?

  • Ganhar vantagem competitiva por mostrar ser um site confiável e legítimo.
  • Oferecer garantia para os seus consumidores que seus dados não serão adulterados ou forjados.
  • Garantir que os dados importantes dos seus consumidores trafeguem com segurança sob criptografia forte.
  • Garantia contra quebra, ou seja, existe uma garantia em dinheiro estabelecida no caso de quebra do certificado, comprovação de phishing e interceptação de dados.
  • Apareça com mais destaque no Google.

Com a crescente popularidade da internet, mais oportunidades são criadas para os setores comerciais e não-comerciais. A maioria das pessoas não enviarão seus dados confidenciais pela web a menos que saibam que as informações estarão seguras. A melhor maneira de garantir essa segurança e atrair mais consumidores é instalar um certificado SSL para comprovar a identidade do seu site.

Como saber se o meu certificado SSL está funcionando perfeitamente?

  1. Acesse a sua URL via HTTPS:// e clique duas vezes sobre o cadeado que aparece no canto superior direito do Google Chrome.
  2. Em seguida, clique no botão Informações do certificado…
  3. Ao abrir o certificado clique na aba Detalhes 3. Na aba Detalhes clique em Requerente
  4. O tipo do seu certificado está escrito na segunda linha, no primeiro campo

Lembrando que o site do gmxCheckout possui certificado SSL para garantir a segurança dos seus usuários, aumentar a visibilidade do site na hora da busca no Google, proporcionar aumento no tráfego de transações seguras e redução do número de transações abandonadas, mais segurança com a criptografia dos dados que trafegam no site, dentro outros benefícios.

Gostou desse post? Quer saber mais? Ficou com alguma dúvida? É só clicar na opção “Precisando de ajuda?” e entrar em contato conosco. Continue acompanhando o blog para saber mais sobre o gmxCheckout e suas facilidades.

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.