지금 JS를 HASH 방식으로 바꿨는데, 그러면 userKey는 어떻게 가져오나요

이 글의 성격은 무엇인가요?

질문 / 문제 해결

내용을 설명해주세요

지금 토스 로그인에서 게임 로그인으로 교체 작업 중입니다.
JS를 HASH 방식으로 바꿨는데, 그러면 userKey는 어떻게 가져오나요

아니면 이 hash 값이 이전의 userKey를 대신해서 사용할 수 있는지도 함께 확인해 주세요

안녕하세요 :slight_smile:
게임 로그인에서는 userKey 값을 제공하지 않습니다.
사용자 식별은 게임 로그인 Hash 값을 기준으로 하시면 됩니다 :slight_smile:

네넵 감사합니다.

그럼 게임로그인으로 작업시 결제는 어느걸 타고 들어가야 할지 가이드 부탁드리겠습니다.

해당 질문을 드리는 이유는 가이드에 따라서 인앱결제

해당 링크로 작업하려하는데 여기서는 또 토스 로그인을 작업해야 한다고 해서 혼선이 오고 있습니다.

게임 로그인을 사용 하셨을 경우, userKey 를 사용하는 API는 이용할 수 없습니다 :cry:

@Roy 님 안녕하세요

주문 조회 API 사용 때문에 그러실까요?

주문 조회 API(/api-partner/v1/apps-in-toss/order/get-order-status)는 토스 로그인을 통해 획득한 userKey 기반으로 확인하실 수 있습니다.

그런데, 토스 로그인이 아닌 게임 로그인을 사용할 경우 주문 조회를 위해서는 API가 아닌 SDK를 사용해 주세요.

getCompletedOrRefundedOrders 함수를 통해 주문을 조회하실 수 있습니다.

넵 답변감사합니다.

시도해보겠습니다.

1개의 좋아요

말씀하신 방식을 검토중에 다음과 같은 질문들이 생각나서 문의드리고자 합니다..

기존에는 토스 로그인을 통해 발급받은 userKey를 기준으로
주문 조회 API(/api-partner/v1/apps-in-toss/order/get-order-status)를
게임 서버에서 호출하여 결제 유효성을 검증하고,
그 결과를 바탕으로 서버에서 최종 발화를 처리해 왔습니다.

다만, 게임 로그인 사용 시에는 userKey가 제공되지 않고
SDK의 getCompletedOrRefundedOrders 함수 사용을 권장해 주셨는데,
해당 방식은 클라이언트(JS/Unity WebGL)에서 호출되는 구조로 이해하고 있습니다.

이 경우 아래 사항에 대해 확인 부탁드립니다.

  1. 게임 로그인 환경에서 게임 서버가 결제 유효성을 검증할 수 있는 서버 간(Server-to-Server) 방식의 공식 API 또는 권장 구조가 있는지

  2. 클라이언트에서 SDK로 조회한 주문 정보를 게임 서버로 전달하여 서버에서 최종 발화 여부를 판단하는 구조가 토스의 권장 아키텍처인지

  3. 게임 로그인 전환 이후에도 결제 검증 및 발화의 최종 책임은 게임 서버에 있어야 한다는 이해가 맞는지

보안 및 중복 발화 방지를 위해
결제 검증 로직을 클라이언트에 두는 것은 어렵다고 판단하고 있어
토스 측의 공식 가이드 또는 권장 아키텍처를 명확히 확인하고자 합니다.

혹시 이에대한 답변을 따로 안내받으셨나요?