이벤트 수집은 옵트인입니다. Transactions → Settings → Event monitoring에서 켜야 합니다.
켜기 전까지는 아무것도 바뀌지 않습니다. 기존 거래 규칙은 계속해서 거래에만 적용되며, 규칙은 이벤트를 명시적으로 포함하지 않는 한 거래에만 적용되므로 실수로 이벤트에 적용되는 규칙이 만들어지는 일은 없습니다.이 기능을 켜기 전까지 모든 쓰기 경로(
POST /v3/events/, POST /v3/events/batch/, POST /v3/events/sdk-token/, 그리고 /v1/events/ 기기 경로)는 {"code": "event_monitoring_disabled"}와 함께 403을 반환하며, 아무것도 저장, 보강 또는 평가되지 않습니다. 조회에는 영향이 없습니다.엔드포인트
/v3/ 경로는 서버 경로이며, 거래 API의 나머지 부분과 동일한 x-api-key 인증을 사용합니다. /v1/events/ 경로는 기기 경로이며, 자세한 내용은 SDK 이벤트 전송을 참조하세요.
엔벨로프
카테고리
최상위 카테고리는 10개이며, 각 카테고리에는 타입이 지정된 유효성 검사와 관리형 규칙 필드가 있습니다.auth는 제품 전반을 아우르는 넓은 카테고리입니다. security는 계정 탈취 규칙이 읽는 순서가 정해진 수명 주기를 가진 위험 등급 하위 집합입니다.
필수 페이로드 키
일부 작업은 특정 키 없이는 상관 분석할 수 없습니다. 따라서 검증 단계에서 아무도 연결할 수 없는 증거를 저장하는 대신 해당 이벤트를 거부합니다.예시: P2P 정산
예시: 차지백
dispute 이벤트로 기록합니다.
멱등성
event_id는 애플리케이션마다 고유하며, 멱등성 계약 그 자체입니다.
- 같은
event_id, 같은 내용이면"idempotent_replay": true와 함께200을 반환하며, 처음 저장된 이벤트를 돌려줍니다. 원하는 만큼 다시 시도할 수 있습니다. - 같은
event_id, 다른 내용이면409를 반환합니다. ID를 실수로 재사용한 경우입니다.
배치
POST /v3/events/batch/는 최대 500개의 이벤트를 받습니다. 배치는 설계상 부분 성공을 허용합니다. 형식이 잘못된 페이지 조회 하나 때문에 바로 옆의 차지백 이벤트까지 실패해서는 안 됩니다.
207 Multi-Status이고, 모든 이벤트가 저장되면 201 Created입니다.
상태
correlation_pending: true는 여러 주체를 대상으로 하는 규칙이 아직 실행되어야 함을 뜻합니다. 상관 분석은 몇 분 안에 완료되며, 이벤트의 상태와 점수는 그 자리에서 갱신됩니다. 비동기 규칙을 참고하십시오.
보존
이벤트는 거래보다 훨씬 많으므로, 각 이벤트는 도착할 때 보존 클래스에 분류됩니다.
이 표에서 다음 두 가지 규칙이 도출됩니다.
- 규칙에 일치하는 이벤트는 증거이므로 자동으로
risk_relevant로 승격됩니다. - 결제 및 분쟁 이벤트는 거래 보존 기간을 유지합니다. 이벤트 일정에 따라 만료되지 않으며, 클래스별 재정의로 기간을 단축할 수 없습니다.
IP 보강
이벤트에도 거래와 동일한 IP 보강 정보가 포함됩니다. 국가, ASN, VPN/프록시 및 데이터 센터 플래그가 여기에 해당합니다. 보강 정보는 이벤트마다 조회되지 않고 고유 IP 주소마다 조회됩니다. 한 주소에서 200번의 페이지 조회가 발생하는 세션이라도 해당 주소는 한 번만 조회됩니다. 낮은 가치의 텔레메트리는 한 걸음 더 나아갑니다. 다른 이벤트가 이미 해당 주소를 조회한 경우에만 보강 정보를 읽습니다. 자체적으로 조회를 트리거하는 일은 결코 없습니다.GET /v3/events/enrichment-metrics/는 그 결과를 보고하며, 콘솔은 이벤트 목록 위에 같은 수치를 다음과 같이 표시합니다:
이벤트 조회
event_category, action_type, status, retention_class, subject_vendor_data, business_vendor_data, session_id, device_fingerprint, ip_address, game_id, round_id, affiliate_code, payment_reference_id, counterparty_vendor_data, matched_only, occurred_from, occurred_to, search. 여러 값을 지정하는 필터는 매개변수를 반복해서 사용합니다(?status=A&status=B).
한 주체의 타임라인
vendor_data는 엔티티 유형 안에서만 고유합니다. 같은 ID가 사용자와 기업을 가리킬 수 있으며, Didit은 이를 서로 다른 두 주체로 처리합니다. entity_type은 조회하려는 대상을 지정합니다. individual(기본값) 또는 company를 사용할 수 있습니다. 기업 ID에 이 값을 생략하면 두 타임라인이 모두 반환되지 않고 개인의 타임라인이 반환됩니다. 동일한 목록 필터를 사용할 수 있습니다.
GET /v3/events/{event_uuid}/는 페이로드, 기기 컨텍스트, IP 정보 보강, 주체의 캐시된 위험 신호, 그리고 모든 규칙 일치 항목과 근거를 추가로 반환합니다. 각 일치 필드가 서버에서 도출되었는지, SDK에서 도출되었는지, 고객이 제공했는지도 함께 표시됩니다.
DELETE /v3/events/{event_uuid}/delete/는 이벤트 하나를 삭제합니다. 삭제된 이벤트는 모든 조회에서 더 이상 반환되지 않으며, 삭제는 되돌릴 수 없습니다.
다음
이벤트 규칙
이벤트 데이터에 대한 속도, 비율, 순서 및 상관관계 규칙입니다.
SDK 이벤트 제출
범위가 제한된 자격 증명을 사용하여 기기에서 직접 이벤트를 캡처합니다.