크레딧 없이 sandbox에서 테스트하기
Sandbox는 애플리케이션별로 설정하는 모드로, 모든 제공업체가 모의 처리되고 아무것도 청구되지 않으며 필요한 어떤 검증 결과든(approved, declined, in review) 강제로 만들어낼 수 있습니다.
Sandbox는 라이브 애플리케이션 안에 있는 스위치가 아니라, 애플리케이션에 설정하는 모드입니다. sandbox 모드의 두 번째 애플리케이션을 만들어 그 API 키를 사용하면, 모든 검사가 모의 처리되고 아무것도 청구되지 않으며 원하는 어떤 결과든 강제로 만들어낼 수 있습니다. 운영용 애플리케이션만 보인다면 sandbox 애플리케이션을 새로 만들어야 합니다. 모드는 애플리케이션마다 선택하는 것이기 때문입니다.
Didit의 sandbox는 결제 서비스의 테스트 카드와 같은 역할을 합니다. 실제 제공업체를 호출하거나 실제 개인정보를 다루거나 잔액에 손대지 않고도 원하는 검증 결과를 언제든 재현할 수 있습니다.
#Sandbox는 애플리케이션에 설정하는 모드입니다
대부분의 사람이 여기서 헷갈립니다.
Live와 sandbox는 같은 조직 안의 서로 다른 애플리케이션이므로, 테스트 트래픽과 운영 데이터가 절대 섞이지 않습니다.
각 애플리케이션은 live 또는 sandbox 중 하나의 모드를 가집니다.
- 키는 하나의 애플리케이션에 속합니다 - sandbox 애플리케이션의 키는 라이브 세션에 접근할 수 없습니다.
- 라이브 키를 재사용하지 말고 테스트 전용 키를 별도로 만드세요.
- 두 번째 애플리케이션 만들기
콘솔 상단의 애플리케이션 전환 메뉴를 열고 새 애플리케이션을 만드세요. 모드로 sandbox를 선택합니다.
- 그 애플리케이션의 API 키 사용하기
sandbox 애플리케이션이 선택된 상태에서 API & Webhooks에서 API 키를 가져오세요. 라이브 애플리케이션에 별도의 "테스트 키"는 없습니다. 키 자체가 곧 환경입니다.
- 그 안에 워크플로우 만들기
sandbox 애플리케이션은 자체 워크플로우를 가집니다. 테스트하려는 흐름을 다시 만들거나 복사하세요.
- 평소처럼 세션 만들기
동일한 엔드포인트, 동일한 코드 경로입니다. 유일한 차이는 어떤 키를 보내느냐입니다.
콘솔에 운영용 애플리케이션만 보이고 sandbox를 추가할 방법이 없다면, 조직에 sandbox 애플리케이션 생성을 활성화해 달라고 지원팀에 요청하세요. 이는 계정 수준 설정이지, 여러분이 잘못 구성한 것이 아닙니다.
#Sandbox가 바꾸는 것, 바꾸지 않는 것
| Sandbox | Live | |
|---|---|---|
| 외부 제공업체 | 전부 모의 처리 - 실제 제3자는 절대 호출되지 않음 | 실제 |
| 과금 | 절대 청구되지 않음, 잔액 확인도 건너뜀 | 완료된 feature마다 청구 |
| 세션 생성 한도 | 애플리케이션당 24시간에 500회 | 보유 잔액만큼 |
| Webhook 페이로드 | "environment": "sandbox" | "environment": "live" |
| 추출된 데이터와 상태 | 선택한 시나리오로 시뮬레이션됨 | 실제 캡처에서 도출됨 |
| 캡처된 미디어 | 라이브 세션과 똑같이 실제로 저장됨 | 저장됨 |
Sandbox는 라이브 세션과 마찬가지로 캡처한 미디어(문서, 셀피, 라이브니스 영상, 주소 증명 파일)를 실제로 저장합니다. 결과는 시뮬레이션되지만 업로드는 실제이므로, 실제 신분증이나 실제 개인정보가 아니라 흐름이 제공하는 샘플 문서와 테스트 데이터를 사용하세요.
결과가 픽셀에 좌우되지 않으므로, 일부러 나쁜 사진을 올려도 sandbox에서는 거절로 이어지지 않습니다. 결과를 결정하는 것은 시나리오입니다.
#결과 선택하기
세션을 만들 때 sandbox_scenario로 시나리오 슬러그를 전달하거나, 테스터가 직접 고르게 할 수도 있습니다.
호스팅된 흐름의 sandbox 세션에서는 캡처가 시작되기 전에 카드 안에 시나리오 선택기가 표시되고, 업로드 컴포넌트 아래에 샘플 문서 목록이, 그리고 항상 "test data only" 배너가 함께 표시됩니다.
시나리오는 실제로 구현 과정에서 필요한 결과들을 다룹니다.
| 테스트하려는 것 | 시나리오 |
|---|---|
| 모두 승인 | approve |
| 만료된 문서 | decline_document_expired |
| 판독 불가능한 문서 | decline_could_not_recognize_document |
| MRZ 체크섬 실패 | decline_mrz_validation |
| 최소 연령 미달 | decline_minimum_age |
| 얼굴 대조 점수 부족 | decline_face_match_low_similarity |
| 라이브니스 프레젠테이션 공격 | decline_liveness_attack |
| AML 제재/PEP 히트 | decline_aml_hit |
| 차단된 IP 주소 | decline_ip_blocklist |
| 주소 증명 주소 불일치 | decline_poa_address_mismatch |
| NFC 칩 무결성 검증 실패 | decline_nfc_chip_not_verified |
| 데이터베이스 검증 결과 없음 | decline_database_no_match |
| 수동 심사 필요(AML) | review_aml_possible_match |
| 수동 심사 필요(경계선 얼굴 대조) | review_face_match_borderline |
| 수동 심사 필요(부분 주소 일치) | review_poa_partial_match |
| KYB 등기 정보 불일치 | decline_kyb_registry_mismatch |
review_* 시나리오는 거절 수준의 입력값 없이도 전체 수동 심사 경로 - 콘솔 심사 큐, In Review webhook, 재제출을 요청하거나 승인하는 리뷰어 - 를 그대로 연습해 볼 수 있도록 존재합니다.
시나리오와 매직 값의 최신 카탈로그는 API 자체에서 GET /v1/sandbox/scenarios/로 제공됩니다.
여기 있는 슬러그가 오래되어 보인다면 이 엔드포인트를 신뢰하세요.
전체 레퍼런스: sandbox testing.
#자신의 코드에서 둘을 구분하기
모든 webhook에는 "sandbox" 또는 "live"값을 가진 environment 필드가 포함됩니다.
키로 환경을 추측하려 하지 말고 이 필드로 분기하면, 테스트 세션을 실제 고객으로 착각하는 일이 없습니다.
#Sandbox가 하지 않는 것
- 실제 기업에 대한 실제 등기 데이터를 반환하지 않습니다. Sandbox의 KYB는 모의 등기 응답을 사용합니다.
- 실제 SMS나 이메일을 보내지 않습니다. 전화번호와 이메일 인증은 모의 처리되므로, sandbox로는 실제 메시지 전달 여부를 미리 볼 수 없습니다.
- 매월 무료 한도를 소모하지 않습니다. 즉 sandbox 실행 결과로는 남은 무료 검사 횟수를 알 수 없습니다.
#실제 테스트 검증이 필요하다면
특정 국가의 데이터베이스 서비스가 계정에 프로비저닝되어 있는지 확인하거나 특정 통신사로 SMS가 실제로 전달되는지 확인하는 등, 실제로 라이브 호출이 필요한 경우도 있습니다. 이런 경우에는 sandbox가 아니라 라이브 애플리케이션에 소액을 충전해야 합니다. 지출하기 전에 지원팀에 문의해, 해당 서비스가 실제로 계정에서 활성화되어 있는지 먼저 확인받으세요.