Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alteraçõesCategorias de transação
Cada transação tem umtransaction_category que determina a forma como as regras e as análises a tratam:
Detalhes da transação
O objetotransaction_details contém os dados financeiros:
Sujeito e contraparte
Cada transação tem um sujeito (obrigatório) e uma contraparte (opcional). Ambos utilizam 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, o country_code dessa parte é devolvido como null.
Quando o vendor_data corresponde a um utilizador ou a uma empresa existente, a Didit liga automaticamente a transação ao perfil dessa entidade, o que permite a avaliação de regras entre sessões e as verificações de frequência e volume.
Na resposta, ambas as partes são devolvidas no array parties, com as funções APPLICANT e COUNTERPARTY.
Métodos de pagamento
Associe umpayment_method a cada parte para descrever o instrumento utilizado por essa parte:
Nas 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 montante, na moeda predefinida da sua aplicação, não é inferior a threshold_amount, a transferência passa diretamente para UNCONFIRMED_OWNERSHIP e para o fluxo de prova de titularidade. Consulte Carteiras autocustodiadas declaradas.
Nas transações de criptoativos, inclua os endereços em account_id e defina currency_kind como crypto, para que a triagem na blockchain seja executada automaticamente. A direção determina a carteira que é analisada: a triagem pré-transferência de entrada utiliza a carteira do remetente em counterparty.payment_method.account_id; a triagem de saída utiliza a carteira de destino em counterparty.payment_method.account_id. Se 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 predefinição da triagem de criptoativos
Utilizeinclude_crypto_screening no nível superior do pedido para substituir a predefinição configurada em Transações > Definições na Consola:
Contexto do dispositivo
Inclua informações do dispositivo na parte sujeita (e, opcionalmente, na contraparte) para alimentar as regras de inteligência de dispositivo. O campo do pedido édevice_context em cada parte; o alias em camelCase device também é aceite e é o que o formato de transmissão do SDK utiliza. A resposta devolve-o como device em cada parte no array parties.
browser_family e platform não são derivados de user_agent. Têm de ser enviados como chaves explícitas de primeiro nível dentro de device_context para que as regras de inteligência de dispositivo sejam acionadas. Se utilizar o SDK da Didit, estes campos são recolhidos 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 primeiro nível também é integrado em network_context.
O contexto do dispositivo permite regras como a deteção de multicontas (mesma impressão digital em sujeitos diferentes), a deteção da combinação de novo browser com novo IP, transferências de valor elevado com idade de sessão baixa e a pontuação de risco baseada na localização.
Propriedades personalizadas
Adicione quaisquer pares chave-valor adicionais no objetocustom_properties. As regras podem referenciar estes campos nas respetivas condições, o que é útil para transmitir contexto específico do negócio, como a categoria do produto, o ID do comerciante ou o canal.
custom_values.<key>. Por exemplo, o payload acima corresponde a custom_values.product_category eq "electronics". No criador de regras da Consola, as chaves vistas em transações recentemente recebidas aparecem no seletor de campos de condição em Propriedades personalizadas, e Introduzir propriedade personalizada no mesmo grupo permite introduzir manualmente qualquer chave (sensível a maiúsculas e minúsculas). Consulte Regras e pontuação para mais detalhes.
Exemplo de pedido
Resposta
A API devolve a transação criada com os resultados da avaliação inicial:
Consulte a Referência da API para o esquema completo do pedido e da resposta, e a referência do esquema de resposta para uma explicação anotada de um payload.
Atribuir uma transação a um revisor
Atribua uma transação retida a um membro da sua aplicação, ou desatribua-a, com uma chave de API que tenha o privilégiowrite:transactions.
Cada alteração é registada na linha temporal da transação como TRANSACTION_ASSIGNED.
Ambas as chamadas recebem
assignee_email, o e-mail de um membro da aplicação que tenha iniciado sessão no Didit.
Envie null ou uma cadeia de caracteres vazia para desatribuir.
A chamada em massa recebe também 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 este responsável atribuído), ou 404 quando a transação não existe na aplicação.
A chamada em massa devolve transactions (uma entrada como a acima), 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 a um destes valores: me, unassigned, rules (decidida apenas pelas regras, sem intervenção de revisor) ou o e-mail de um membro.
Idempotência
Otxn_id (o transaction_id que envia) é único por aplicação.
Reenviar um transaction_id que já existe devolve 400 com A transaction with this transaction_id already exists. no campo transaction_id, e dois pedidos idênticos enviados em simultâneo devolvem 409 ao segundo.
Nenhuma das respostas devolve a transação existente.
Para repetir o envio com segurança, trate um 400 ou 409 para um transaction_id duplicado como “já criada” e consulte a transação existente em vez de a reenviar: 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 do seu txn_id.
Gere sempre o txn_id do seu lado (por exemplo, o ID da sua base de dados de transações, um UUID ou um hash determinístico).
Carregamento histórico
Envie umtxn_date anterior à data atual para importar transações históricas. Por predefinição, as regras continuam a ser avaliadas. Se quiser ignorar a avaliação de regras durante carregamentos históricos em massa, use a importação CSV da consola com o modo dry-ingest. Consulte o guia de integração.
Próximos passos
Regras e pontuação
Como as transações enviadas são avaliadas em função das regras.
Esquema da resposta
Payload completo da resposta, com anotações.
Triagem de criptoativos
Triagem automática de carteiras e transações para transações cripto.
Travel Rule
Anexar dados de conformidade da Travel Rule às transferências de ativos virtuais.
Enriquecimento de IP
Contexto derivado do IP disponível para as regras.
Referência da API
Esquema completo do pedido para o endpoint de criação de transação.