# anonKey 서버 인증 기반 소모품 IAP의 주문 소유관계 검증 방법 문의 **URL:** \ **Category:** 개발\ **Created:** [10월 29, 2026, 7:10오전 UTC](https://techchat-apps-in-toss.toss.im/t/anonkey-iap/5097 "2026-10-29T07:10:53Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![oksktmdgus](https://avatars.discourse-cdn.com/v4/letter/o/4bbf92/32.png) [@oksktmdgus](https://techchat-apps-in-toss.toss.im/u/oksktmdgus)\ **Post date:** [10월 29, 2026, 7:10오전 UTC](https://techchat-apps-in-toss.toss.im/t/anonkey-iap/5097/1 "2026-10-29T07:10:53Z")
### 이 글의 성격은 무엇인가요? 질문 / 문제 해결 ### 내용을 설명해주세요 안녕하세요. 출시 전인 미니앱의 소모품 IAP를 설계하고 있습니다. anonKey 인증코드를 서버에서 교환해 사용자 세션을 만들고, mTLS로 주문을 조회한 뒤 결제 확인과 지급을 처리하려고 합니다. 지원팀에서는 이 인증 방식으로 IAP 구매·복원이 가능하다고 답변해 주셨고, 주문과 사용자의 소유관계를 구체적으로 검증하는 방법은 개발자 커뮤니티에 문의하도록 안내받았습니다. 다음 사항에 대한 공식 권장 방식을 확인 부탁드립니다. 1. 서버에서 조회한 orderId가 현재 인증된 사용자의 주문임을 확인하는 공식 방법이 있나요? mTLS 주문 조회 응답만으로 대조할 수 있는 식별 필드가 있는지, 별도의 API나 서버에서 검증할 수 있는 서명된 증거가 제공되는지 궁금합니다. 2. 클라이언트가 전달한 orderId를 신뢰하지 않고, 다른 사용자의 주문 ID가 재사용되어 지급되는 것을 막으려면 어떤 서버 검증을 해야 하나요? 3. 복원 시 동일 SKU의 소모품 주문이 여러 건 있을 때, 각 주문을 올바른 인증 사용자와 매칭하고 지급 여부를 확인하는 권장 흐름이 있나요? 주문 상태 확인과 구매자 소유관계 확인은 별개로 보고 있습니다. 현재 지원되는 API·SDK 버전과 관련 문서 또는 권장 예제를 안내해 주시면 감사하겠습니다. 현재 제공되지 않는 기능이라면, 출시 전에 적용할 수 있는 공식 대안이 있는지도 부탁드립니다. 유료 결제는 아직 출시 전이며, 이 검증 방법을 확인한 뒤 진행하려는 설계 질문입니다. ---
**Author:** ![Dylan](https://yyz1.discourse-cdn.com/flex007/user_avatar/techchat-apps-in-toss.toss.im/dylan/32/597_2.png) [@Dylan](https://techchat-apps-in-toss.toss.im/u/Dylan)\ **Post date:** [10월 30, 2026, 2:06오전 UTC](https://techchat-apps-in-toss.toss.im/t/anonkey-iap/5097/2 "2026-10-30T02:06:35Z")
안녕하세요 🙂 이 [문의](https://techchat-apps-in-toss.toss.im/t/webview-sdk-3-8-0-50/5026)와 동일한 내용으로 보여 연결해둡니다. 1. 현재 제공되고 있는 구매자 검증 API는 없습니다. mTLS 주문 조회 응답에도 구매자에 대한 정보가 포함되어 있지 않아, IAP 개선 버전에서 말씀주신 부분 고려하여 개발 예정입니다. 2. 최초 주문 생성시 orderId와 anonKey를 매핑하여 저장하고, 주문별 지급 이력을 관리해주시는걸 권유드립니다.또 동일 미니앱의 `orderId`에 유일성 제약을 두어, 사용자가 달라도 같은 주문으로 두 번 지급되지 않게 처리 부탁드립니다. 3. 동일 SKU를 여러 번 구매했더라도 각 구매 건은 서로 다른 `orderId`로 구분합니다. `getPendingOrders`로 해당 사용자의 미결 주문 목록을 조회한 뒤, 각 `orderId`를 서버의 지급 이력과 대조하는 방식으로 처리하면 됩니다. `getPendingOrders` 는 해당 사용자의 미지급 주문만 반환합니다. ---
**Author:** ![oksktmdgus](https://avatars.discourse-cdn.com/v4/letter/o/4bbf92/32.png) [@oksktmdgus](https://techchat-apps-in-toss.toss.im/u/oksktmdgus)\ **Post date:** [10월 30, 2026, 3:33오전 UTC](https://techchat-apps-in-toss.toss.im/t/anonkey-iap/5097/3 "2026-10-30T03:33:33Z")
답변 감사합니다. 안내해 주신 주문별 사용자 매핑과 중복 지급 방지를 적용하며, 출시 절차와 최초 매핑에 관해 두 가지 추가 확인 부탁드립니다. 1. 현재는 무료 버전만 출시돼 있고, IAP 상품 등록의 최소 지원 버전 목록에는 기존 출시 버전만 표시됩니다. 실제 IAP 연동 코드를 포함하되 판매는 비활성인 버전을 먼저 검토·출시한 뒤 비노출 상품을 등록·연결하는 순서가 맞을까요? 상품 등록 전 신규 IAP 버전을 검토하거나 QR에서 검증할 수 있는 공식 절차도 안내 부탁드립니다. 2. 구매자 검증 API가 없는 현재 구조에서, 최초 orderId–anonKey 매핑은 인증된 사용자 세션과 SDK 구매 완료 콜백/getPendingOrders 결과를 기준으로 서버에 저장하는 방식이 공식 권장인가요? 다른 사용자의 orderId가 최초 제출되는 경우를 방지하기 위해 사용할 수 있는 서버 검증값이나 권장 검증 절차가 있는지 궁금합니다. 중복 지급 방지와 별도로 최초 매핑의 신뢰 범위를 확인하고 싶습니다. ---
**Author:** ![Dylan](https://yyz1.discourse-cdn.com/flex007/user_avatar/techchat-apps-in-toss.toss.im/dylan/32/597_2.png) [@Dylan](https://techchat-apps-in-toss.toss.im/u/Dylan)\ **Post date:** [11월 2, 2026, 1:30오전 UTC](https://techchat-apps-in-toss.toss.im/t/anonkey-iap/5097/4 "2026-11-02T01:30:14Z")
1. QR 테스트 환경(`intoss-private`)에서는 실제 결제까지 테스트할 수 있어요. 상품을 먼저 등록하고 신규 버전에 IAP 연동 코드를 포함한 뒤, QR로 결제를 검증하는 과정에서 어떤 부분이 막히셨는지 확인 부탁드려요. 상품 등록과 코드 반영을 나눠서 진행하시려는 다른 이유가 있을까요? 2. 넵 맞습니다. `createOneTimePurchaseOrder` 의 성공 콜백이 호출되면 processProductGrant를 통해 상품 지급 프로세스를 진행하고 true를 반환해주시면 돼요. 이 시점에 orderId와 구매한 유저의 데이터를 자체 서버에 저장해주세요. ---
**Author:** ![oksktmdgus](https://avatars.discourse-cdn.com/v4/letter/o/4bbf92/32.png) [@oksktmdgus](https://techchat-apps-in-toss.toss.im/u/oksktmdgus)\ **Post date:** [11월 2, 2026, 8:05오전 UTC](https://techchat-apps-in-toss.toss.im/t/anonkey-iap/5097/5 "2026-11-02T08:05:40Z")
답변 감사합니다. QR에서 실제 결제까지 테스트할 수 있다는 안내 확인했습니다. 현재 상태를 다시 확인해 설명드립니다. 1. 콘솔의 인앱 상품 목록은 비어 있고 등록 폼에는 접근할 수 있습니다. 다만 필수 항목인 ‘최소 지원 버전’에는 기존 출시 버전 20261027-17과 20261020-13만 표시됩니다. 두 버전은 IAP를 지원하지 않는 무료판입니다. 상품 문안·이미지와 IAP 관련 로컬 구현은 준비 중이며, 판매는 비활성 상태이고 실기기 결제 검증은 아직 하지 않았습니다. 기존 무료판을 IAP 지원 버전으로 지정하지 않으려 등록 순서를 여쭤봤습니다. 등록 오류가 발생한 것은 아닙니다. 이 경우 기존 출시 버전을 최소 지원 버전으로 지정하고 ‘등록 후 바로 상품 노출’은 끈 채 상품을 먼저 등록한 뒤, IAP 코드를 넣은 신규 QR 버전에서 해당 상품을 테스트하는 것이 맞을까요? 기존 무료판의 노출·구매에 영향을 주지 않는 공식 절차를 안내 부탁드립니다. 1. createOneTimePurchaseOrder 성공 콜백과 processProductGrant에서 지급을 처리하고, orderId와 구매 사용자 데이터를 서버에 저장한 뒤 true를 반환하는 흐름은 이해했습니다. 남은 질문은 최초 매핑의 신뢰 근거입니다. 서버가 인증한 사용자와 클라이언트가 전달한 orderId의 실제 구매자가 같은 사람인지, 서버에서 독립적으로 검증할 공식 API·검증 필드·서명된 증거 또는 권장 절차가 있을까요? 다른 사용자의 주문번호가 최초로 제출되는 경우를 막는 방법을 확인하려는 질문입니다. 이미 저장된 주문의 중복 지급 방지와는 별개로 보고 있습니다. 현재 제공되는 검증 수단이 없다면, 콜백 기반 최초 매핑에서 서버가 신뢰해야 하는 범위와 권장 보완 절차를 알려주시면 감사하겠습니다.