Primeiros passos
Integração / SDKs
Verificação de usuários
Verificação de empresas
Monitoramento de transações
Registro de alteraçõesCategorias de transação
Toda transação tem umtransaction_category que determina como as regras e as análises a tratam:
Detalhes da transação
O objetotransaction_details contém os dados financeiros:
Titular e contraparte
Cada transação tem um titular (obrigatório) e uma contraparte opcional. Ambos usam o mesmo modelo de parte:
A Didit deriva o
country_code da parte a partir de address.country quando address é um objeto. Quando address é uma string, country_code retorna null nessa parte.
Quando vendor_data corresponde a um usuário ou a uma empresa existente, a Didit vincula automaticamente a transação ao perfil dessa entidade, o que permite a avaliação de regras entre sessões e verificações de frequência.
Na resposta, as duas partes são retornadas no array parties com as funções APPLICANT e COUNTERPARTY.
Métodos de pagamento
Anexe umpayment_method a cada parte para descrever o instrumento de pagamento associado a essa parte:
Em transações
travelRule, um método de pagamento da contraparte com method_type: "unhosted_wallet" (alias type) declara a carteira da contraparte como autocustodiada.
Quando a Travel Rule está ativada e o valor, na moeda padrão da sua aplicação, não está abaixo de threshold_amount, a transferência vai direto para UNCONFIRMED_OWNERSHIP e para o fluxo de prova de propriedade. Consulte Carteiras autocustodiadas declaradas.
Para transações cripto, inclua os endereços em account_id e defina currency_kind como crypto para que a triagem na blockchain possa ser executada automaticamente. A direção controla qual carteira é analisada: a triagem de entrada antes da transferência usa a carteira do remetente em counterparty.payment_method.account_id; a triagem de saída usa a carteira de destino em counterparty.payment_method.account_id. Se você enviar um hash da blockchain em transaction_details.payment_reference_id, a triagem de transações de entrada exige o endereço de depósito do seu serviço em subject.payment_method.account_id, enquanto a triagem de transações de saída exige a carteira de destino em counterparty.payment_method.account_id.
Substituição da triagem de cripto
Useinclude_crypto_screening no nível superior da requisição para substituir o padrão configurado em Transações > Configurações no Console:
Contexto do dispositivo
Inclua informações do dispositivo do titular (e, opcionalmente, da contraparte) para alimentar as regras de inteligência de dispositivo. O campo da requisição édevice_context em cada parte. O alias em camelCase device também é aceito e é o que o formato de transmissão do SDK usa. A resposta o retorna como device em cada parte do array parties.
browser_family e platform não são derivados de user_agent. Eles devem ser enviados como chaves explícitas de nível superior dentro de device_context para que as regras de inteligência de dispositivo sejam acionadas. Se você usa o SDK da Didit, esses campos são coletados automaticamente.userAgent, browserFamily, browserVersion, osFamily, osVersion, acceptLang, sessionId, sessionAgeMs. O subobjeto network_context aceita os aliases ip / countryCode3 / lat / lon, e um bloco ipInfo de nível superior também é incorporado a network_context.
O contexto do dispositivo viabiliza regras como detecção de múltiplas contas (mesmo fingerprint em titulares diferentes), detecção da combinação de navegador novo com IP novo, transferências de alto valor com sessão recente e pontuação de risco baseada em localização.
Propriedades personalizadas
Adicione quaisquer pares chave-valor extras no objetocustom_properties. As regras podem referenciar esses campos em suas condições, o que é útil para enviar contexto específico do seu negócio, como categoria de produto, ID do lojista ou canal.
custom_values.<key>. Por exemplo, o payload acima corresponde a custom_values.product_category eq "electronics". No construtor de regras do Console, as chaves vistas em transações ingeridas recentemente aparecem no seletor de campos da condição em Propriedades personalizadas, e Inserir propriedade personalizada, no mesmo grupo, permite digitar qualquer chave manualmente (diferencia maiúsculas de minúsculas). Consulte Regras e pontuação para mais detalhes.
Exemplo de requisição
Resposta
A API retorna a transação criada com os resultados da avaliação inicial:
Consulte a Referência da API para o esquema completo de requisição e resposta, e a referência do esquema de resposta dedicada, que apresenta um passo a passo comentado do payload.
Atribuir uma transação a um revisor
Atribua uma transação retida a um membro da sua aplicação, ou remova a atribuição, com uma chave de API que tenha o privilégiowrite:transactions.
Cada alteração é registrada na linha do tempo da transação como TRANSACTION_ASSIGNED.
As duas chamadas recebem
assignee_email, o e-mail de um membro da aplicação que já fez login na Didit.
Envie null ou uma string vazia para remover a atribuição.
A chamada em massa também recebe transaction_ids, uma lista de 1 a 500 UUIDs de transações.
uuid, transaction_number, assignee e changed (false quando a transação já tinha esse responsável), ou 404 quando a transação não existe na aplicação.
A chamada em massa retorna transactions (uma entrada como a acima por transação), updated_count e not_found_transaction_ids.
Filtre a lista de transações com assignee, uma lista separada por vírgulas em que qualquer valor corresponde: me, unassigned, rules (decididas apenas pelas regras, sem envolvimento de revisor) ou o e-mail de um membro.
Idempotência
txn_id (o transaction_id que você envia) é único por aplicação.
Reenviar um transaction_id que já existe retorna 400 com A transaction with this transaction_id already exists. no campo transaction_id, e, quando duas requisições idênticas concorrem entre si, a segunda recebe 409.
Nenhuma das duas respostas retorna a transação existente.
Para tentar novamente com segurança, trate um 400 ou 409 para um transaction_id duplicado como indicação de que a transação já foi criada e consulte a transação existente em vez de reenviá-la: leia-a com GET /v3/transactions/{uuid}/ usando o uuid da primeira resposta, ou use o transaction_id (o uuid da Didit) que o webhook transaction.created traz junto com o seu txn_id.
Sempre gere o txn_id do seu lado (por exemplo, o ID da transação no seu próprio banco de dados, um UUID ou um hash determinístico).
Carga de dados históricos
Passetxn_date com uma data no passado para ingerir transações históricas. Por padrão, as regras continuam sendo avaliadas: use a importação de CSV do console com o modo dry-ingest se quiser pular a avaliação de regras durante cargas históricas em massa. Consulte o guia de integração.
Próximos passos
Regras e pontuação
Como as transações enviadas são avaliadas em relação às regras.
Esquema da resposta
Payload completo da resposta, com anotações.
Triagem de cripto
Triagem automática de carteiras e transações de criptoativos.
Travel Rule
Anexe dados de conformidade com a Travel Rule a transferências de ativos virtuais.
Enriquecimento de IP
Contexto derivado do IP disponível para as regras.
Referência da API
Esquema completo da requisição para o endpoint Create Transaction.