Cancelamento Assíncrono
ATENÇÃO: Esta página é um documento em construção, sujeita a alterações sem aviso prévio, e ainda desacoplada da nossa documentação completa. Caso queira acessar toda nossa documentação, acesse aqui.
A funcionalidade de cancelamento assíncrono altera o modo como os cancelamentos são tratados. Como resultado, os cancelamentos não são mais processados imediatamente. Em vez disso, eles entram em uma fila de processamento assíncrono aguardando pare serem canceladas. Essa abordagem permite melhorar a eficiência do processamento, especialmente em casos de alto volume de transações.
#
Nota: Esta funcionalidade está disponível apenas para BIN.
Nessa modalidade a resposta inicial de cancelamento ficará como pendente (PEN) e quando processada terá status de confirmado (CON) ou negado (NEG). Em caso de falha do processo, o status de erro (ERR) seria retornado.
#
Nota: O processo de cancelamento assíncrono atualmente não é suportado para pré-autorizações.
#
Configurações necessárias no CaratA loja só conseguirá efetuar o cancelamento assíncrono caso possua permissão para esta operação no back office do Carat. Para isso, é necessário comunicar à equipe de cadastro do Carat a respeito dessa demanda específica.
#
ExemploRequisição:
Resposta:
WebHook:
Carat enviará uma solicitação POST em formato JSON para a URL de uma Loja.
Aviso de status da solicitação:
** Esteja ciente de que - por motivos de segurança - para receber um aviso de status, a URL de recebimento deve validar o POST via mTLS.
Para isso, um certificado de cliente deve ser emitido pelo estabelecimento comercial e enviado para instalação no Carat. Caso não seja possível a utilização de validação por mTLS o lojista deve, por segurança, sempre validar o status da transação utilizando a API de consulta de transação.
** O Carat também pode enviar novos parâmetros sem aviso prévio, o que significa que a aplicação do lojista deve estar preparada para receber campos extras e simplesmente ignorá-los.
Fluxo do WebHook:
A notificação não enviará o status, por motivos de segurança. A consulta por meio da API é obrigatória.
Figura 1 – Sucesso na notificação do webhook.
Figura 2 – As tentativas de notificação do webhook falham.
#
Omnipay API Status vs Treatment & ReturnAuthorizer resp code | Authorizer resp msg | Status Transação |
---|---|---|
0 | OK | CON |
0 | OK | PEN |
03 | Invalid Merchant ID | NEG |
05 | Invalid | NEG |
05 | Error | PEN |
13 | Invalid Amount | NEG |
79 | Invalid Transaction Date | NEG |
79 | Mandatory fields missing | NEG |
93 | Original Transaction not Found | NEG |
98 | Invalid Merchant ID | NEG |
108 | Invalid Merchant Contract Status | NEG |
110 | Invalid Transaction Type | NEG |
112 | Original transaction has a chargeback | NEG |
113 | Insufficient Funds | NEG |
400 | System Error | ERR |
401 | System Error | NEG |