WebSocket 서버의 보안 기능과 로컬 저장소의 사용 범위를 나누어 안내 드립니다.

1. WSS 및 연결 단계의 인증
sdk.websocket.start()로 여는 서버는 WS 방식이며, TLS 인증서·개인키 설정이나 핸드셰이크 단계의 인증 헤더 검증 기능은 제공하지 않습니다.
따라서 해당 서버에 WSS를 설정하거나, SDK의 연결 콜백에서 핸드셰이크 이전에 연결을 거절하는 방식으로 구성할 수는 없습니다.
연결 후 인증 메시지를 확인하고 실패 시 disconnect()로 종료할 수는 있습니다. 이 경우 인증이 끝나기 전에는 결제·취소 명령을 처리하지 않도록 해야 하며, 연결 후 인증만으로 통신이 암호화되는 것은 아닙니다.

2. 암호화가 필요한 경우의 구성
자체 WSS 서버에 POS와 프론트 플러그인이 각각 접속하고, 해당 서버에서 인증과 요청 전달을 처리하는 구성을 검토해 주세요.
프론트 플러그인은 브라우저 표준 WebSocket으로 접속하며, 접속 대상에 맞는 유효한 인증서와 ACL 설정이 필요합니다. 인증서 검증을 해제하는 방식으로 구성하지 말아 주세요.
파트너 시스템 연동 가이드와 WebSocket API를 참고해 주세요. 프론트를 WS 서버로 사용하는 기존 구성은 이전 포럼 답변에서도 안내했지만, 해당 구성이 WSS를 제공한다는 의미는 아닙니다.

3. localStorage와 Storage API
Storage API는 WebView의 localStorage가 아니라 단말기의 별도 네이티브 저장소를 사용합니다.
localStorage 사용 자체를 일괄 금지하는 것은 아니지만, 사용만으로 검수가 승인되거나 데이터 보존이 보장되는 것은 아닙니다. SDK의 키·값 저장 기능이 필요하다면 Storage API를 사용하되, 전환만으로 주문·결제 복구의 안정성이 보장된다고 보시면 안 됩니다.

4. 데이터 유지와 격리
Storage API의 저장된 값은 일반적인 플러그인 새로고침, 앱 재시작 및 단말기 재부팅 후에도 보관하는 구조입니다. 다만 재온보딩 과정에서는 초기화됩니다.
업데이트·로그아웃·삭제·재설치의 모든 경우에 두 저장소의 데이터가 유지된다고 전제하지 말고, 값이 없는 경우 서버에서 복원할 수 있도록 구성해 주세요.
Storage API를 앱·매장·계정별 자동 격리가 보장되는 저장소로 사용하지 마세요. 매장이나 계정이 바뀌었을 때 이전 상태를 그대로 적용하지 않도록 구분과 초기화 처리가 필요합니다.

5. 저장 용량·쓰기 보장·결제 복구
공통으로 보장하는 저장 용량이나, 저장 성공 직후 전원 차단까지 포함한 쓰기 보존·원자성을 제공하는 거래 저장소로 안내 드리기는 어렵습니다. 주문·결제의 기준 데이터는 서버에 저장하고, 로컬 저장소는 비민감 설정이나 복구 보조 상태용으로 사용해 주세요.
인증 토큰·API 키·민감한 결제정보를 보관하는 용도로 사용하지 마세요. Storage API는 암호화 저장소가 아닙니다.
승인 응답이 유실됐다면 동일 단말에서 같은 paymentKey로 getPayment를 호출해 결과를 복구할 수 있습니다. 해당 기능은 최근 성공 승인 결과의 로컬 캐시 조회이므로 영구적인 결제 원장이나 다른 단말의 조회 수단을 대신하지는 않습니다.

Storage API · 프론트 FAQ · 승인 결과 복구 안내