증거를 요구하세요
귀하의 신청서는 특정 조치에 필요한 증명(예: 18세 이상 또는 담당자 인증)을 요청합니다.
개발자를 위한 체크파이
사이트를 연결하고, Checkify Pass ID를 복사하고, 확인하려는 항목을 선택한 다음, 로그인, 결제, 댓글, 문의 양식 또는 사용자 정의 흐름에 Checkify을 추가하세요.
통합 모델
귀하의 애플리케이션은 증빙 자료를 요구합니다. Checkify이 고객 여정을 실행합니다. 결과를 받으면 다음 단계를 결정합니다.
귀하의 신청서는 특정 조치에 필요한 증명(예: 18세 이상 또는 담당자 인증)을 요청합니다.
Checkify은 충분한 증거가 있는지 또는 고객이 추가 검증을 완료해야 하는지 여부를 결정합니다.
서버는 결과를 확인하고 보호된 작업을 허용, 차단 또는 계속 진행합니다.
리얼 API
고객이 Pass 세션을 완료하면 백엔드에서 request_id를 사이트 API 키와 비교하여 확인합니다. 브라우저 코드에 사이트 API 키를 절대 넣지 마십시오.
요구
POST /v1/qr/results/verify
Authorization: Bearer YOUR_SITE_API_KEY
Content-Type: application/json
{
"request_id": "56a57761-ff5b-42f0-9c97-6c13e223e017",
"required_claims": ["age_over_18"],
"consume": true
}
응답
{
"success": true,
"status": "completed",
"approved_claims": {
"age_over_18": true
}
}
브라우저 또는 플러그인은 request_id(종종 checkify_token으로 저장됨)를 저장합니다. 서버가 권한을 가진 주체이므로, 작업을 허용하기 전에 approved_claims를 확인하십시오.
요청할 수 있는 사항
검증 인프라를 재구축할 필요 없이, 각 여정에 대한 요청 유형이나 필수 클레임을 변경할 수 있습니다.
13세 이상, 16세 이상, 18세 이상 또는 25세 이상과 같은 연령 기준을 요청하세요.
age_over_18양식 작성, 로그인 및 악용 방지 시스템에 실제 담당자가 참여하고 있음을 확인하십시오.
human_verified위험 수준에 맞는 보증 수준(기본 보증부터 고보증까지)을 요청하십시오.
basic → highAssurance보증 수준 및 정확한 증거 옵션은 여정, 장치 및 구성된 정책에 따라 다릅니다. 클레임 이름에 대한 자세한 내용은 서버 확인 가이드를 참조하십시오.
통합 방법
사용하는 스택에 맞는 경로부터 시작하세요. 모든 프로덕션 경로는 동일한 증명 모델을 사용합니다.
WordPress, WooCommerce 및 Joomla/J2Commerce는 일반적인 CMS 및 결제 게이트웨이입니다.
WordPress 가이드 →사용자 정의 웹사이트를 위한 CDN 임베드 및 바인딩폼입니다. 세션을 전달하고 토큰을 폼에 기록합니다.
문서 삽입 →POST /v1/qr/results/verify 및 사이트 API 키(csk_)를 사용하여 결과를 확인하십시오.
서버 확인 →Pass 및 QR 핸드오프를 사용한 장소 및 기기 간 이동 경로.
체육 직원 가이드 →Shopify 및 Wix는 대기 목록에 있거나 출시 예정이며, 여기에는 실제 운영 환경에 통합된 것으로 표시되지 않습니다.
신임장
Checkify는 두 가지 다른 자격 증명을 사용합니다. 잘못된 자격 증명을 잘못된 위치에 사용하는 것이 가장 흔한 통합 오류입니다.
Browser embed, WordPress, Joomla — frontend only
Backend verify API — server only, never in JavaScript
결과 전달
표준 웹사이트 및 결제 흐름의 경우, 보호된 작업이 제출될 때 서버에서 request_id를 확인하십시오. 사용자 지정 프런트엔드의 경우 선택적으로 상태 폴링을 사용할 수 있습니다.
페이지 또는 플러그인이 사이트에 연결된 Checkify Pass 요청을 시작합니다.
고객은 Checkify 앱에서 확인 또는 승인합니다.
verify 엔드포인트를 호출하고 approved_claims를 확인한 후 허용 또는 차단합니다.
일반적인 통합에는 범용 검증 웹훅이 필요하지 않습니다. 파트너 아웃바운드 웹훅(예: GoHighLevel)은 비즈니스 대시보드에서 별도로 구성합니다.
선적 서류 비치
구현에 대한 자세한 내용은 이 가이드를 참조하십시오. 이 페이지는 통합 모델에 초점을 맞추고 있습니다.
Pass를 삽입하고 첫 번째 보호 작업에 대한 양식을 바인딩하세요.
빠른 시작 열기 →검증 및 상태를 포함하여 공개 통합에서 사용되는 엔드포인트입니다.
API 문서를 엽니다 →data-checkify 속성, bindForm 옵션 및 요청 유형.
내장 문서 열기 →사이트 API 키, required_claims, consume 및 signed_result.
오픈 서버 가이드 →