Correção Automática para Transações Sinalizadas: O Status AWAITING_USER (PT-BR)

A parte mais difícil do monitoramento de transações não é detectar o pagamento suspeito — é o que você faz em seguida. Recusá-lo diretamente bloqueia um cliente pagante que pode ser totalmente legítimo. Deixá-lo passar significa aceitar o risco que você acabou de sinalizar. A maioria das equipes resolve isso com uma fila manual: um analista envia um e-mail ao usuário, espera dias por um documento, e a transação fica congelada durante todo o processo.

A API de Monitoramento de Transações da Didit possui um quarto status criado exatamente para essa lacuna: AWAITING_USER. Em vez de uma aprovação ou recusa binária, uma transação sinalizada pode pausar, solicitar uma ação específica do usuário — verificar novamente a identidade, fornecer prova de fundos — e retomar automaticamente no momento em que ele resolver. A fricção ocorre apenas onde há risco, e custa os mesmos $0.02 por transação que todo o resto.

Este guia explica como o caminho AWAITING_USER funciona e como integrá-lo ao seu fluxo.

Principais pontos

• AWAITING_USER é um dos quatro status de transação — ao lado de APPROVED, IN_REVIEW e DECLINED — para que a remediação seja um resultado de primeira classe, não uma solução alternativa.
• Uma transação sinalizada pausa em vez de falhar, solicita uma ação de "step-up" do usuário e retoma automaticamente assim que a ação é concluída.
• O "step-up" pode ser um re-KYC, um upload de prova de fundos ou qualquer etapa de verificação gerada na API unificada /v3/.
• Webhooks impulsionam o loop — transaction.status.updated é acionado quando a transação entra e sai de AWAITING_USER.
• O mesmo status existe no gerenciamento de casos, para que um analista possa mover um alerta para AWAITING_USER e deixar o usuário resolvê-lo.
• $0.02 por transação, sem mínimos. Um re-KYC ou verificação AML gerado durante a remediação é cobrado pela sua taxa publicada.

O que o AWAITING_USER faz

Quando uma regra é acionada, o motor atribui um status. Três dos quatro são familiares: APPROVED permite a transação, IN_REVIEW abre um alerta para um analista e DECLINED a bloqueia. O quarto, AWAITING_USER, faz algo diferente — ele suspende a transação e sinaliza que o usuário deve fazer algo antes que ela possa ser resolvida.

Concretamente: uma transferência aciona uma regra de alto valor ou alta velocidade, o motor retorna AWAITING_USER, sua aplicação solicita ao usuário que complete a etapa solicitada (uma nova verificação de vivacidade, upload de documento, declaração de origem de fundos), e a sessão de verificação alimenta a plataforma. Assim que a etapa é concluída, a transação é reavaliada e passa para APPROVED (ou escala se a nova evidência piorar as coisas). Nenhum analista precisa monitorá-la.

Por que isso importa

Declínios rígidos são caros. Cada bloqueio de falso positivo é um cliente legítimo frustrado, um ticket de suporte e, muitas vezes, uma conta cancelada. Mas deixar pagamentos sinalizados passarem é como as empresas acabam em ações de fiscalização. A solução convencional — uma fila de remediação manual — troca um custo por outro: tempo do analista, demora na resolução e uma transação congelada por dias.

AWAITING_USER elimina essa desvantagem. O usuário faz o trabalho, no momento, no ponto de fricção — exatamente quando está motivado a resolver, porque sua própria transação está esperando. Você detecta o risco, mantém o cliente e não paga um analista para buscar um documento. É a diferença entre um controle de conformidade que custa clientes e um que faz seu trabalho silenciosamente.

Detalhes técnicos

Uma transação que o motor direciona para remediação retorna com o status AWAITING_USER e as regras que a acionaram:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "Transferência de alto valor — primeiros 30 dias", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Você reage solicitando ao usuário e gerando a etapa de verificação na API unificada /v3/. Quando a etapa é concluída, um webhook informa que a transação avançou:

# payload do webhook: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhooks. Assine transaction.created e transaction.status.updated. O evento "status-updated" é acionado tanto quando a transação entra em AWAITING_USER quanto quando sai — para que seu livro-razão e sua interface permaneçam sincronizados sem a necessidade de polling.

Preço. $0.02 por transação. A etapa de remediação em si é cobrada pela sua taxa publicada: um re-KYC nas taxas de Verificação de Usuário, uma verificação AML em uma parte sinalizada a $0.20.

O loop de remediação, passo a passo

1. Acione uma regra. Uma transação ultrapassa um limite que sua política diz que deve ser remediado em vez de recusado — por exemplo, uma primeira transferência de alto valor de uma nova conta.
2. Pause, não falhe. O motor retorna AWAITING_USER em vez de DECLINED, com a ação necessária anexada.
3. Solicite ao usuário. Sua aplicação exibe o "step-up" — uma nova verificação de vivacidade, um upload de documento, uma declaração de origem de fundos — e inicia a sessão de verificação.
4. Usuário resolve. O usuário completa a etapa dentro do mesmo fluxo em que já estava.
5. Retoma automaticamente. A transação é reavaliada com a nova evidência e passa para APPROVED — ou escala para IN_REVIEW/DECLINED se a evidência aumentar o risco. Um webhook transaction.status.updated notifica seu backend de qualquer forma.

Como o mesmo estado AWAITING_USER existe no gerenciamento de casos, um analista trabalhando em um alerta IN_REVIEW também pode enviá-lo de volta ao usuário em vez de resolvê-lo ele mesmo — o alerta passa por OPEN → INVESTIGATING → AWAITING_USER e é resolvido assim que o usuário responde.

Casos de uso

• Fintech — uma primeira transferência de alto valor de uma conta recém-integrada pausa para prova de fundos em vez de bloquear o cliente.
• Cripto — uma transferência de saída para uma carteira com exposição elevada pausa para uma declaração de origem de fundos antes de ser liquidada.
• Empréstimos — um desembolso que aciona um sinal de identidade sintética pausa para uma verificação de vivacidade de re-KYC.
• Marketplaces — um pagamento de vendedor que aciona uma regra de velocidade pausa para reverificação antes da liberação dos fundos.
• iGaming — um pico de velocidade de depósito pausa para uma verificação de "step-up", que também serve como um ponto de contato para jogo responsável.

Como integrar com a Didit

1. Decida sua política de remediação. No Console de Negócios, defina quais regras devem ser direcionadas para AWAITING_USER em vez de DECLINED, e qual ação de "step-up" cada uma solicita.
2. Envie transações. POST /v3/transactions/ conforme o dinheiro se move, com um transaction_id estável e vendor_data ligando cada um ao seu usuário.
3. Lide com a pausa. Quando uma transação retorna AWAITING_USER, solicite ao usuário e inicie a etapa de verificação na API /v3/.
4. Ouça a retomada. Reaja a transaction.status.updated para liberar ou reter a transação assim que o usuário concluir a etapa.

Como tudo está na API unificada /v3/, o KYC de remediação que uma transação sinalizada gera é o mesmo KYC com o qual você integra usuários — uma plataforma de identidade e fraude, de ponta a ponta.

Perguntas frequentes

O que é AWAITING_USER?

É um dos quatro status de transação. Em vez de uma recusa total, uma transação sinalizada pausa e solicita uma ação do usuário — reverificação ou prova de fundos — e retoma automaticamente assim que o usuário a conclui.

A transação retoma sozinha?

Sim. Uma vez que a etapa solicitada é concluída, a transação é reavaliada e passa para APPROVED automaticamente — ou escala se a nova evidência aumentar o risco. Um webhook transaction.status.updated é acionado na mudança.

Qual pode ser o "step-up"?

Qualquer etapa de verificação na API unificada /v3/ — uma verificação de vivacidade de re-KYC, uma reverificação de documento, uma verificação AML ou um upload de prova de fundos.

Um analista precisa estar envolvido?

Não. O loop de auto-remediação funciona sem um analista. Mas o mesmo estado AWAITING_USER existe no gerenciamento de casos, então um analista também pode enviar um alerta de volta ao usuário quando desejar.

Quanto custa?

$0.02 por transação. A etapa de remediação é cobrada pela sua própria taxa — um re-KYC nas taxas de Verificação de Usuário, uma verificação AML a $0.20.

Pronto para começar?

Leia a visão geral do Monitoramento de Transações na documentação, veja como ele se encaixa no resto da plataforma na página do produto Monitoramento de Transações e verifique os preços transparentes por chamada na página de preços. Quando estiver pronto, comece gratuitamente — 500 verificações KYC gratuitas todos os meses e monitoramento de transações a $0.02 por chamada.