13 replies

[추가 확인 요청] confirm API 500 응답 관련 문의 (Authorization 처리 관련)

결제연동

안녕하세요, 안내해주신 디스코드 채널로 이동했습니다.

방금 받은 메일 답변과 관련해, 제가 겪은 상황을 조금 더 정확히 전달드리고 추가로 확인하고 싶은 부분이 있어 정리드립니다.

먼저, 제가 이전 메일에서 전달드린 내용과 답변 주신 부분을 간단히 정리드리면:
• 저는 Authorization 헤더에 ${TOSS_SECRET_KEY}와 같이 ${...} 형태의 문자열이 실제 Secret Key로 치환되지 않고 그대로 포함된 credential을 사용한 상태에서 confirm 요청 시 HTTP 500 + 빈 응답이 반환되는 현상을 문의드렸고,
• 답변에서는 “credential 값은 들어왔기 때문에 paymentKey를 확인했고, paymentKey가 없거나 expired되어 500이 반환된 것”이라고 설명해주셨습니다.

제가 처음 겪은 케이스는 paymentKey가 없거나 만료된 경우가 아니었습니다.
• 프론트엔드에서 Toss 결제 위젯을 통해 정상적으로 결제를 완료
• 위젯을 통해 전달받은 실제 유효한 paymentKey를 confirm API에 전달
• 단, 서버 측 Authorization 헤더에 ${TOSS_SECRET_KEY}가 그대로 포함된 상태

이 조건에서 confirm 요청 시 HTTP 500 + 빈 응답 본문이 반환되었습니다.

일반적으로는 Authorization 검증이 요청 처리의 가장 앞단에서 수행되고, 유효하지 않은 Secret Key가 전달된 경우에는 인증 단계에서 401과 같은 응답이 반환되는 것으로 이해하고 있었습니다.
또한 paymentKey 만료의 경우에는 문서상 별도의 4xx 에러 코드가 정의되어 있는 것으로 확인하고, 테스트도 마쳤습니다.

이 점을 고려했을 때, 현재 500 응답이 paymentKey 상태 때문인지, 아니면 Authorization credential 처리 단계에서 발생하는 예외인지에 대해 조금 더 명확히 이해하고 싶습니다.

이후 말씀해주신 내용을 확인하기 위해 추가 테스트를 진행해보았습니다.

paymentKey 필드를 body에 아예 포함하지 않은 경우에도 동일하게 HTTP 500 + 빈 응답이 반환되는 것을 확인했습니다.

응답 헤더에는 다음과 같은 정보가 포함되어 있었습니다.
• HTTP/2 500
• content-length: 0
• x-envoy-upstream-service-time: 6
• server: envoy

위 결과를 종합해보면 paymentKey 검증 단계 이전에서 처리된 것으로 보이는데,
혹시 Authorization credential 처리 과정에서 특정 형식의 값이 들어올 경우 예외적으로 500이 반환될 수 있는 구조인지 확인 부탁드릴 수 있을까요?

참고로, 해당 현상을 추적하며 진행했던 디버깅 과정은 아래 GitHub 이슈에 정리해두었습니다.
내부 확인에 도움이 된다면 참고 부탁드립니다.
• https://github.com/raillo-temp/raillo-backend/issues/167

제가 confirm API의 유효성 검증 순서를 정확히 이해하지 못한 부분이 있을 수도 있어, 내부적으로 어떤 순서로 검증이 이루어지는지도 간략히 설명해주시면 감사하겠습니다.

확인 부탁드립니다. 감사합니다.

GitHub

[BUG] TossPaymentClient onStatus 핸들러에서 에러 응답 body...