연결과 운영 확인

서버별 키를 안전하게 관리하기

대시보드 → 내 상품 → 상품 수정 → 연동 정보 → 서버별 연동 키와 권한 관리에서 생성합니다. 생성 직후 한 번만 표시되는 추가 키를 서버 환경 변수에 저장하세요. 추가 키의 원문은 DB에 저장하지 않습니다.

검증 서버는 verify, 결제 서버는 checkout.write·checkout.read·checkout.ack, 고객 포털 연결은 portal.read 권한을 선택합니다. 사용량 기록은 usage.write, 분석은 analytics.read가 필요합니다. 권한을 지정해도 상품·요금제 제한이 해제되지 않습니다.

새 키 생성 → 서버 설정 변경 → 정상 요청 확인 → 이전 키 폐기 순서로 교체하면 중단을 줄일 수 있습니다. «교체»는 이전 키를 즉시 폐기하므로 짧은 중단이 생길 수 있습니다. 기존 기본 키는 전체 권한이며 기본 키 교체도 기존 요청을 즉시 차단합니다.

로컬에서 무료로 준비하기

설정 생성기와 셀프 테스트는 SDK 0.4.0부터 제공합니다. 프로젝트에 SDK를 설치한 뒤 먼저 생성할 파일을 확인하세요.

npm install @saemol/sdk@^0.4.0
# 먼저 출력할 파일만 확인
npx saemol-sdk scaffold --framework next --out ./saemol-connection
# 검토 후 새 폴더에 생성 (기존 파일은 덮어쓰지 않음)
npx saemol-sdk scaffold --framework next --out ./saemol-connection --write
npx saemol-sdk doctor
npx saemol-sdk self-test

생성된 로그인 확인 함수는 기본적으로 구매를 거부합니다. 실제 서비스의 서버 세션에 연결해야 합니다. SQLite 예제는 Node 24 이상과 단일 영구 프로세스가 필요합니다. 다중 인스턴스에서는 공유 DB의 트랜잭션·고유 제약으로 저장소를 바꾸세요.

셀프 테스트는 합성 데이터로 중복 지급·응답 유실·환불 순서·재시작 복구를 검사합니다. doctor는 환경 변수 존재와 API 접속을 확인합니다. 실제 상품의 결제·권한과 판매자 서버의 적용 확인은 별도로 검사하세요.

실패할 때 확인할 순서

401은 키·테스트/운영 환경·만료·폐기를, 403은 추가 키의 권한과 판매자 요금제를 확인하세요. 409는 같은 멱등 키에 다른 요청을 보냈는지 확인합니다. 429는 Retry-After를 기다리고 호출 횟수를 줄이세요. 503이나 응답 유실 뒤에는 쓰기의 성공 여부를 조회해 확인합니다.

API 응답의 X-Request-Id를 문의에 첨부하세요. SDK 0.4.0의 SaemolApiError.requestId와 onResponse에서도 확인할 수 있습니다. 키·웹훅 원문·개인정보는 문의나 로그에 남기지 마세요. 정상 요청마다 별도 진단 DB 기록을 만들지 않습니다.

인증 전 제한은 기존 Cloudflare Workers 환경의 Rate Limit 바인딩을 쓰며 데이터센터별 근사 제한입니다. 금융 한도나 전 세계의 정확한 수량 제한으로 쓰지 않습니다. 인증 후 상품별 DB 제한과 결제·사용량의 원자성은 별도로 유지합니다.

고객의 다음 업무를 놓치지 않기

고객 관리에서 이름·주문 번호·앱 사용자 ID·태그를 검색하고 «조치 필요»와 «후속 일정 도래»를 확인합니다. 고객 상세에서 비공개 메모·태그·담당자·다음 일정을 기록하세요.

자동 사이트 내 알림은 비즈니스 이상에서 선택할 수 있습니다. 기존 5분 복구 작업에서 일정당 한 번 알리고 이메일·문자는 보내지 않습니다. 강등 시 자동 알림은 중지되며 기존 메모와 구매자의 권한은 유지됩니다. 활동 기록은 약 365일 보존하고 내보내기는 한 번에 각 500건입니다. 메모 원문과 비밀 키는 내보내지 않습니다.

구매자는 내 정보 → 이용 중인 서비스에서 본인 주문·권한·구독·기기·문의로 이동합니다. 웹훅 수신 성공과 판매자 서버의 적용 확인은 서로 다른 증거입니다.

PG 계약 후 남는 확인

테스트 시크릿은 PG 테스트 결제를 열지 않습니다. PG 계약·상점/채널·키·웹훅 설정 후 실제 승인·취소·환불·구독 갱신·정산을 검증해야 합니다. 운영 게이트를 유지하며 계약 전에는 실결제 완료로 표시하지 않습니다. 기업 SSO·SCIM은 도입 요청이 들어오면 별도 확장합니다.