AWAITING_USER: Autocorrecció per a Transaccions Senyalades (CA)

La part més difícil de la monitorització de transaccions no és detectar el pagament sospitós, sinó què fer a continuació. Rebutjar-lo directament bloqueja un client de pagament que pot ser totalment legítim. Deixar-lo passar accepta el risc que acabes de senyalar. La majoria dels equips ho resolen amb una cua manual: un analista envia un correu electrònic a l'usuari, espera dies per un document i la transacció queda congelada tot el temps.

L'API de Monitorització de Transaccions de Didit té un quart estat dissenyat precisament per a aquesta bretxa: AWAITING_USER. En lloc d'una aprovació o rebuig binaris, una transacció senyalada pot pausar-se, sol·licitar una acció específica de l'usuari —reverificar la identitat, proporcionar prova de fons— i reprendre's automàticament en el moment que la completin. La fricció només es produeix on hi ha risc, i costa els mateixos 0,02 $ per transacció que la resta.

Aquesta guia explica com funciona la ruta AWAITING_USER i com integrar-la al teu flux.

Punts clau

• AWAITING_USER és un dels quatre estats de transacció —juntament amb APPROVED, IN_REVIEW i DECLINED— de manera que la correcció és un resultat de primera classe, no una solució provisional.
• Una transacció senyalada es pausa en lloc de fallar, sol·licita una acció addicional de l'usuari i es reprèn automàticament un cop l'acció s'ha completat.
• L'acció addicional pot ser un re-KYC, una càrrega de prova de fons o qualsevol pas de verificació generat a l'API unificada /v3/.
• Els webhooks impulsen el bucle — transaction.status.updated s'activa quan la transacció entra i surt de AWAITING_USER.
• El mateix estat existeix en la gestió de casos, de manera que un analista pot moure una alerta a AWAITING_USER i deixar que l'usuari la resolgui.
• 0,02 $ per transacció, sense mínims. Un re-KYC o una comprovació AML generada durant la correcció es factura a la seva tarifa publicada.

Què fa AWAITING_USER

Quan una regla s'activa, el motor assigna un estat. Tres dels quatre són familiars: APPROVED permet el pas de la transacció, IN_REVIEW obre una alerta per a un analista i DECLINED la bloqueja. El quart, AWAITING_USER, fa una cosa diferent: suspèn la transacció i indica que l'usuari ha de fer alguna cosa abans que es pugui resoldre.

Concretament: una transferència activa una regla d'alt valor o alta velocitat, el motor retorna AWAITING_USER, la teva aplicació demana a l'usuari que completi el pas sol·licitat (una nova comprovació de vivacitat, una càrrega de document, una declaració de font de fons), i la sessió de verificació s'integra a la plataforma. Un cop el pas es completa, la transacció es reavalua i passa a APPROVED (o s'escala si la nova evidència empitjora les coses). Cap analista ha de supervisar-la.

Per què és important

Els rebuigs directes són costosos. Cada bloqueig per fals positiu és un client legítim frustrat, un tiquet de suport i sovint un compte perdut. Però deixar passar pagaments senyalats és com les empreses acaben en accions d'execució. La solució convencional —una cua de correcció manual— canvia un cost per un altre: temps de l'analista, temps de resposta lent i una transacció congelada durant dies.

AWAITING_USER elimina aquest compromís. L'usuari fa la feina, en el moment, al punt de fricció, exactament quan està motivat per resoldre-ho perquè la seva pròpia transacció està pendent. Tu detectes el risc, mantens el client i no pagues un analista per perseguir un document. És la diferència entre un control de compliment que et costa clients i un que fa la seva feina discretament.

Detalls tècnics

Una transacció que el motor enruta a correcció retorna amb l'estat AWAITING_USER i les regles que la van activar:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "Transferència d'alt valor — primers 30 dies", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Tu reacciones demanant a l'usuari que faci el pas de verificació a l'API unificada /v3/. Quan el pas es completa, un webhook t'indica que la transacció ha avançat:

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

Webhooks. Subscriu-te a transaction.created i transaction.status.updated. L'esdeveniment status-updated s'activa tant quan la transacció entra en AWAITING_USER com quan en surt, de manera que el teu llibre major i la teva interfície d'usuari es mantenen sincronitzats sense necessitat de sondeig.

Preu. 0,02 $ per transacció. El pas de correcció es factura a la seva pròpia tarifa publicada: un re-KYC a les tarifes de Verificació d'Usuaris, una comprovació AML a una part senyalada a 0,20 $.

El bucle de correcció, pas a pas

1. Activa una regla. Una transacció supera un llindar que la teva política diu que s'ha de corregir en lloc de rebutjar, per exemple, una primera transferència d'alt valor des d'un compte nou.
2. Pausa, no fallis. El motor retorna AWAITING_USER en lloc de DECLINED, amb l'acció requerida adjunta.
3. Demana a l'usuari. La teva aplicació mostra el pas addicional —una nova comprovació de vivacitat, una càrrega de document, una declaració de font de fons— i genera la sessió de verificació.
4. L'usuari ho resol. L'usuari completa el pas dins del mateix flux en què ja es trobava.
5. Represa automàtica. La transacció es reavalua amb la nova evidència i passa a APPROVED —o s'escala a IN_REVIEW/DECLINED si l'evidència augmenta el risc. Un webhook transaction.status.updated informa el teu backend en qualsevol cas.

Com que el mateix estat AWAITING_USER existeix en la gestió de casos, un analista que treballa una alerta IN_REVIEW també pot tornar-la a l'usuari en lloc de resoldre-la ell mateix; l'alerta passa per OPEN → INVESTIGATING → AWAITING_USER i es resol un cop l'usuari respon.

Casos d'ús

• Fintech — una primera transferència d'alt valor des d'un compte recentment incorporat es pausa per a una prova de fons en lloc de bloquejar el client.
• Cripto — una transferència sortint a una cartera amb una exposició elevada es pausa per a una declaració de font de fons abans de la liquidació.
• Préstecs — un desemborsament que activa un senyal d'identitat sintètica es pausa per a una comprovació de vivacitat re-KYC.
• Mercats — un pagament a un venedor que activa una regla de velocitat es pausa per a una reverificació abans de l'alliberament dels fons.
• iGaming — un pic de velocitat de dipòsit es pausa per a una comprovació addicional, que també serveix com a punt de contacte per al joc responsable.

Com integrar-se amb Didit

1. Defineix la teva política de correcció. A la Consola de Negoci, estableix quines regles es dirigeixen a AWAITING_USER en lloc de DECLINED, i quina acció addicional sol·licita cadascuna.
2. Envia transaccions. POST /v3/transactions/ a mesura que es mouen els diners, amb un transaction_id estable i vendor_data que vinculen cadascuna amb el seu usuari.
3. Gestiona la pausa. Quan una transacció retorna AWAITING_USER, demana a l'usuari i genera el pas de verificació a l'API /v3/.
4. Escolta la represa. Reacciona a transaction.status.updated per alliberar o retenir la transacció un cop l'usuari ha completat el pas.

Com que tot es troba a l'API unificada /v3/, el KYC de correcció que genera una transacció senyalada és el mateix KYC que utilitzes per incorporar usuaris — una plataforma d'identitat i frau, d'extrem a extrem.

Preguntes freqüents

Què és AWAITING_USER?

És un dels quatre estats de transacció. En lloc d'un rebuig directe, una transacció senyalada es pausa i sol·licita una acció de l'usuari —reverificació o prova de fons— i es reprèn automàticament un cop l'usuari la completa.

La transacció es reprèn sola?

Sí. Un cop el pas sol·licitat s'ha completat, la transacció es reavalua i passa a APPROVED automàticament —o s'escala si la nova evidència augmenta el risc. Un webhook transaction.status.updated s'activa amb el canvi.

Què pot ser el pas addicional?

Qualsevol pas de verificació a l'API unificada /v3/ —una comprovació de vivacitat re-KYC, una reverificació de document, una comprovació AML o una càrrega de prova de fons.

Cal que hi participi un analista?

No. El bucle d'autocorrecció funciona sense analista. Però el mateix estat AWAITING_USER existeix en la gestió de casos, de manera que un analista també pot tornar una alerta a l'usuari quan ho decideixi.

Quant costa?

0,02 $ per transacció. El pas de correcció es factura a la seva pròpia tarifa: un re-KYC a les tarifes de Verificació d'Usuaris, una comprovació AML a 0,20 $.

Llest per començar?

Llegeix la visió general de Monitorització de Transaccions a la documentació, mira com encaixa amb la resta de la plataforma a la pàgina del producte de Monitorització de Transaccions i consulta els preus transparents per trucada a la pàgina de preus. Quan estiguis preparat, comença gratis — 500 comprovacions KYC gratuïtes cada mes i monitorització de transaccions a 0,02 $ per trucada.