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 statusDocumentation Index
Fetch the complete documentation index at: https://docs.malga.io/llms.txt
Use this file to discover all available pages before exploring further.
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:
- O atributo
cvvcheckedidentifica 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 comostatus=activeecvvchecked=false. - O status
activecontinua identificando se o cartão está disponível para uso no fluxo transaciona, porém não é garantia de que um cartãostatus=activeretornar sucesso na cobrança, é possível retorno de falha na cobrança por parte dos bancos. - O status
failedcontinua 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. - O status
pendingpassa 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ãostatus=pendingao ser utilizado para uma cobrança, tem seu status atualizado paraactivese os dados do cartão forem válidos, e atualizado parafailedse os dados do cartão forem inválidos. Após 1 hora um cartão criado comopendingtem seu token expirado e é atualizado automaticamente parafailedficando invalidado para uso futuro. - 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
cardCvvnopaymentSource.
Bug Fixes
- 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.
- 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
- Cartões criados como pending, por falha na validação, ficam como pending, dando erro no fluxo transacional
- 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
- O transacional quando não consegue processar uma cobrança por cartão estar no status pending, retorna um erro 404 genérico,
- Criar fingerprint de cartão para fluxo de cobrança oneshot, hoje só é criado o fingerprint para cartão tokenizado
- Envio do parâmetro statement-descriptor para os provedores
- Autorizações de captura e estorno negadas devem retornar erro e não alterar o estado do charge