생성된(?) orderId와 sku가 값으로 나오는데. sku가 sku_106으로 나옵니다. 이 값은 바뀌지 않는데, 시도 후 실패 했던 sku가 아니라 고정된 sku_106가 나오는 것이 정상인가요? 고정된 임의의 sku가 나오면 어떤 상품을 지급해야 될지 알 수 없게 됩니다.
서버에서의 해당 order status 조회 결과.
{“resultType”:“SUCCESS”,“success”:{“orderId”:“550e8400-e29b-41d4-a716-446655440000”,“sku”:null,“status”:“NOT_FOUND”,“statusDeterminedAt”:null,“reason”:“주문을 찾지 못했어요.”}
orderId 가 나오지만 ‘api-partner/v1/apps-in-toss/order/get-order-status’ 에서 확인시 주문을 확인 할 수 없다고 나옵니다. 이것도 정상인가요? 결제는 성공했지만 개발사 서버에서 상품을 지급하지 못한 경우라 주문을 찾아주고 그 결과에 따라 상품을 지급해야 할 것 같아서요.
샌드박스의 getPendingOrders 는 계속 같은 값이 나오는게 정상인지 (1개만 쌓이고 추가 실패시에도 변동이 없어 보입니다)
만약 이런 것들이 의도했던 바라면 api response나 sku를 샌드박스 테스트시에도 정확한 값으로 리턴 할 계획이 있는지 궁금합니다.
마지막으로 심사시 이와 같은 샌드박스를 사용해 결제 결과를 확인하는지, 실제 스토어의 결제 루틴을 타는지도 알고 싶습니다. 심사에 샌드박스를 이용하지 않는다면 하드코딩으로 자체 테스트가 가능하고 넘길 수 있는데, 심사에서도 더미 값이 전달되는 샌드박스를 사용한다면.. 테스트를 위한 처리가 복잡해질 것 같습니다.
개발이 계속 진행되어 쉽지 않겠지만 업데이트 된 내용을 문서(공지와 함께 문서에도)에 바로 반영을 해주시면 좋겠습니다.
특히 이번 업데이트에서는 실제 라이브 데이터(상품 목록)와 목 데이터 (팬딩 오더)가 섞여서 나오고 있는데, 라이브/샌드박스에서 어떤 값을 기대해야 하는지, 어디까지 테스트가 가능하게 업데이트 되었는지 알지 못하면, 여러 문서와 글들을 전전하며 많은 시간을 보내고 결국 이곳에 오게 됩니다.
자세한 설명 감사합니다.
getPendingOrders → completeProductGrant 까지 새로운 방식으로 처리해 두었습니다!
원래 로컬에 저장해 뒀다가 다시 확인하게 했는데, (기존 네이티브 저장소 기능 활용 시나리오)
getPendingOrders가 강력해서, 서버에서 검증하는 사람은 이걸 꼭 써야 할 것 같아요.
