현재 제공되고 있는 구매자 검증 API는 없습니다. mTLS 주문 조회 응답에도 구매자에 대한 정보가 포함되어 있지 않아, IAP 개선 버전에서 말씀주신 부분 고려하여 개발 예정입니다.
최초 주문 생성시 orderId와 anonKey를 매핑하여 저장하고, 주문별 지급 이력을 관리해주시는걸 권유드립니다.또 동일 미니앱의 orderId에 유일성 제약을 두어, 사용자가 달라도 같은 주문으로 두 번 지급되지 않게 처리 부탁드립니다.
동일 SKU를 여러 번 구매했더라도 각 구매 건은 서로 다른 orderId로 구분합니다. getPendingOrders로 해당 사용자의 미결 주문 목록을 조회한 뒤, 각 orderId를 서버의 지급 이력과 대조하는 방식으로 처리하면 됩니다. getPendingOrders 는 해당 사용자의 미지급 주문만 반환합니다.
답변 감사합니다. 안내해 주신 주문별 사용자 매핑과 중복 지급 방지를 적용하며, 출시 절차와 최초 매핑에 관해 두 가지 추가 확인 부탁드립니다.
현재는 무료 버전만 출시돼 있고, IAP 상품 등록의 최소 지원 버전 목록에는 기존 출시 버전만 표시됩니다. 실제 IAP 연동 코드를 포함하되 판매는 비활성인 버전을 먼저 검토·출시한 뒤 비노출 상품을 등록·연결하는 순서가 맞을까요? 상품 등록 전 신규 IAP 버전을 검토하거나 QR에서 검증할 수 있는 공식 절차도 안내 부탁드립니다.
구매자 검증 API가 없는 현재 구조에서, 최초 orderId–anonKey 매핑은 인증된 사용자 세션과 SDK 구매 완료 콜백/getPendingOrders 결과를 기준으로 서버에 저장하는 방식이 공식 권장인가요? 다른 사용자의 orderId가 최초 제출되는 경우를 방지하기 위해 사용할 수 있는 서버 검증값이나 권장 검증 절차가 있는지 궁금합니다. 중복 지급 방지와 별도로 최초 매핑의 신뢰 범위를 확인하고 싶습니다.
QR 테스트 환경(intoss-private)에서는 실제 결제까지 테스트할 수 있어요.
상품을 먼저 등록하고 신규 버전에 IAP 연동 코드를 포함한 뒤, QR로 결제를 검증하는 과정에서 어떤 부분이 막히셨는지 확인 부탁드려요. 상품 등록과 코드 반영을 나눠서 진행하시려는 다른 이유가 있을까요?
넵 맞습니다. createOneTimePurchaseOrder 의 성공 콜백이 호출되면 processProductGrant를 통해 상품 지급 프로세스를 진행하고 true를 반환해주시면 돼요. 이 시점에 orderId와 구매한 유저의 데이터를 자체 서버에 저장해주세요.
답변 감사합니다. QR에서 실제 결제까지 테스트할 수 있다는 안내 확인했습니다. 현재 상태를 다시 확인해 설명드립니다.
콘솔의 인앱 상품 목록은 비어 있고 등록 폼에는 접근할 수 있습니다. 다만 필수 항목인 ‘최소 지원 버전’에는 기존 출시 버전 20261027-17과 20261020-13만 표시됩니다. 두 버전은 IAP를 지원하지 않는 무료판입니다. 상품 문안·이미지와 IAP 관련 로컬 구현은 준비 중이며, 판매는 비활성 상태이고 실기기 결제 검증은 아직 하지 않았습니다. 기존 무료판을 IAP 지원 버전으로 지정하지 않으려 등록 순서를 여쭤봤습니다. 등록 오류가 발생한 것은 아닙니다.
이 경우 기존 출시 버전을 최소 지원 버전으로 지정하고 ‘등록 후 바로 상품 노출’은 끈 채 상품을 먼저 등록한 뒤, IAP 코드를 넣은 신규 QR 버전에서 해당 상품을 테스트하는 것이 맞을까요? 기존 무료판의 노출·구매에 영향을 주지 않는 공식 절차를 안내 부탁드립니다.
createOneTimePurchaseOrder 성공 콜백과 processProductGrant에서 지급을 처리하고, orderId와 구매 사용자 데이터를 서버에 저장한 뒤 true를 반환하는 흐름은 이해했습니다. 남은 질문은 최초 매핑의 신뢰 근거입니다.
서버가 인증한 사용자와 클라이언트가 전달한 orderId의 실제 구매자가 같은 사람인지, 서버에서 독립적으로 검증할 공식 API·검증 필드·서명된 증거 또는 권장 절차가 있을까요? 다른 사용자의 주문번호가 최초로 제출되는 경우를 막는 방법을 확인하려는 질문입니다. 이미 저장된 주문의 중복 지급 방지와는 별개로 보고 있습니다. 현재 제공되는 검증 수단이 없다면, 콜백 기반 최초 매핑에서 서버가 신뢰해야 하는 범위와 권장 보완 절차를 알려주시면 감사하겠습니다.
