Marcel Nicolay
CTO at Malga

Novo release com melhorias e correções no fluxo de tokenização de cartões. Atualmente nossa API realiza uma tentativa de validação dos dados do cartão, porém os bancos podem retornar falha na validação zerodollar mesmo quando o cartão é válido, ocasionando problemas de falso negativo, onde o cartão é retornado como inválido pela instituição financeira, porém os dados estão corretos. Para contornar essa limitação dos bancos, estamos melhorando nosso fluxo de tokenização para ter mais resiliência.

Foi implementado também uma mudança no fluxo de captura e estorno de transações para garantir o correto tratamento dos casos de exceção retornado pelos provedores nestas operações. A partir desse release, ao recebermos erro na captura/estorno, a requisição passa a retornar como HTTP Status Code 201, sendo criado um transactionRequest com o status failed, porém não modifica o status original da transação. **É recomendado que o cliente verifique o status do objeto charge retornado, ou o status do primeiro objeto da lista de transactionRequests para se certificar que a operação foi realizada com sucesso. Até então nossa API retornava um erro 500 não descritivo. **

Melhorias no fluxo de tokenização:

  1. O atributo cvvchecked identifica se o cartão teve ou não seus dados validados na tokenização. Algumas bandeiras como AMEX não permitem validação zero dollar, nesse caso o cartão passa a ser criado como status=active e cvvchecked=false.
  2. O status active continua identificando se o cartão está disponível para uso no fluxo transaciona, porém não é garantia de que um cartão status=active retornar sucesso na cobrança, é possível retorno de falha na cobrança por parte dos bancos.
  3. O status failed continua identificando um cartão que NÃO pode ser usado no fluxo transacional, é um token já identificado como inválido e não poderá ser utilizado.
  4. O status pending passa a identificar os casos de impossibilidade de validação dos dados cartão na sua criação. Enquanto o status estiver pending o cartão pode ser usado para criar transação durante um intervalo de 1hora, garantindo maior resiliência do transacional. Um cartão status=pending ao ser utilizado para uma cobrança, tem seu status atualizado para active se os dados do cartão forem válidos, e atualizado para failed se os dados do cartão forem inválidos. Após 1 hora um cartão criado como pending tem seu token expirado e é atualizado automaticamente para failed ficando invalidado para uso futuro.
  5. Suporte ao envio de CVV no caso de cobrança com cartão tokenizado. É recomendável que sempre que o comprador esteja presente no momento da compra, seja coletado e enviado o código de segurança do cartão na cobrança. Basta incluir o atributo cardCvv no paymentSource.

Versão 23-12-2021

Features

Suporte a validação de dados de cartão para bandeira ELO
Cartões de bandeiras que não permitem validação passam a ser criados como status=active cvvchecked=false, evitando ficarem com status=pending caso não sejam utilizados
Atualizar status do cartão criado como pending sempre ao final do fluxo transacional, mudando para active ou failed.
Cartões com status=pending quando criados e não utilizados dentro de 1h devem ter seu status atualizado para failed
Criação de domínio secundário em produção api.plugpagamentos.com.br como fallback ao domínio principal api.plugpagamentos.com.
Suporte ao envio de CVV no caso de cobrança com cartão tokenizado. Deve incluir o atributo cardCvv no paymentSource sempre que for possível coletar essa informação.

Bug Fixes

  1. Cartões bandeira visa/master que teve falha na validação zero auth, e não é usado em cobrança, ficava travado com status pending, dando erro no fluxo transacional quando usado depois de 1h da criação.
  2. Cartões bandeira AMEX, que não permite validação zero auth, e não é usado em cobrança, ficava com status pending, dando erro no fluxo transacional quando usado depois de 1h da criação
  3. Cartões criados como pending, por falha na validação, ficam como pending, dando erro no fluxo transacional
  4. Cartões criado como pending (seja por erro no zero auth, ou por ser de bandeira que não permite validação), quando é usado para cobrança dentro de 1h tem seu status atualizado somente no caso de sucesso na cobrança, caso a cobrança falhe por qualquer motivo o cartão não tem seu status atualizado, permanecendo com pending para sempre, gerando o erro 404 no charge
  5. O transacional quando não consegue processar uma cobrança por cartão estar no status pending, retorna um erro 404 genérico,
  6. Criar fingerprint de cartão para fluxo de cobrança oneshot, hoje só é criado o fingerprint para cartão tokenizado
  7. Envio do parâmetro statement-descriptor para os provedores
  8. Autorizações de captura e estorno negadas devem retornar erro e não alterar o estado do charge

Was this page helpful?