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.

Como tudo começou

Igual a maioria dos caras que fazem cursos de exatas, no meu tempo de escola, eu nunca gostei de história. Geografia até dava pra levar mas história definitivamente nunca foi o meu forte, mas hoje em dia me junto a maioria e gosto de uma boa história e resolvi compartilhar a do gmxCheckout com vocês.

Em 2011 eu estava envolvido com o desenvolvimento de uma startup de venda de refeições pela Internet, o www.gourmex.com. Nessa mesma época desenvolvemos em parceria o Proleiloes VIP, um mashup de informações de leilões de imóveis utilizando o Google Maps para o Érico e o Hugo Rocha, que já estavam realizando lançamentos.

Nessa época os lançamentos do Proleilões utilizavam o iPagare porém havia uma grande quantidade de vendas não aprovadas, até que eles tiveram um problema sério com os pagamentos durante um lançamento no final de 2011.

Era dezembro de 2011 e eu estava passando uma semana em Florianópolis e recebi uma ligação do Érico, preocupado procurando alguma ajuda para resolver esse problema. Com o Gourmex.com nós já tínhamos ganhado bastante experiência com pagamentos com cartão de crédito, integrando diretamente com a Cielo, pagando taxas mais baixas e sem problemas com aprovação de pagamentos.

Ele me passou as necessidades da Ignição Digital para pagamentos, que era basicamente permitir pagamentos à vista, parcelados e recorrentes e ter um mecanismo para notificar o sistema de gestão da IGD (conhecido como ‘a Central’) com as informações dos pagamentos realizados.

Para esse projeto, contatei o melhor desenvolvedor que eu tinha disponível na época, o Alexandre Wiggert e projetamos o novo sistema de pagamentos que seria um ‘fork’ do nosso código já em produção no portal Gourmex.com.

Em fevereiro de 2012 já tínhamos uma versão rudimentar do sistema no ar e começamos a processar os pagamentos do ProLeilões.com com a nova plataforma. Nessa época o sistema ainda não tinha um nome e acabou ganhando o apelido de GMX, pois tinha se originado do código do www.gourmex.com.

O sistema permaneceu inalterado até maio de 2013 em que lançamos um site e batizamos o serviço com o nome de gmxCheckout. Abrimos o acesso para vários outros interessados, porém nossa interface ainda era rudimentar e nosso modelo de atendimento individualizado, acabou não sendo o mais conveniente para a maioria.

Interface administrativa em 2013

Interface do sistema administrativo em 2013

Nos envolvemos em outros projetos e lançamos o www.delivoro.com.br, uma plataforma de comércio eletrônico individual para deliveries e o www.portaldoscegonheiros.com.br, um sistema de gestão de transportadoras de veículos até que decidimos retomar o desenvolvimento do gmxCheckout para se tornar o mais independente possível da nossa equipe de desenvolvimento e suporte.

Acrescentamos suporte a páginas de pagamento criadas usando um editor online, suporte a afiliados, processamento em várias adquirentes (Cielo e Rede) e outras funcionalidades interessantes.

Interface Administrativa em 2016

Interface  do sistema administrativo em 2016

É isso por hoje, vou ficando por aqui. Um grande abraço !