[Toss Payments 문의] 결제 승인 전 서버 검증이 필요한 이유에 대한 질문
안녕하세요, 토스페이먼츠를 통해 결제 시스템을 연동하고 있는 개발자입니다.
공식 문서에서 안내해주신 “결제 요청 전에 orderId와 amount를 서버에 저장하고, 승인 전에 다시 검증하라”는 가이드를 보고 궁금한 점이 생겼습니다.
Toss에서는 결제 요청 시
orderId, amount 값을 paymentKey에 바인딩해 저장하고, 승인 요청 시 해당 값이 다를 경우 에러를 리턴하는 것으로 알고 있습니다.
이 경우에도 클라이언트 측에서 금액을 조작하더라도 Toss 자체에서 승인 실패가 발생하기 때문에, 이미 Toss 레벨에서 충분한 검증이 되는 것 아닌가요?
그런데 문서에서는 다시 한 번 서버에 요청 정보를 저장하고 검증하라고 권장하고 있어서 해당 로직의 목적과 Toss의 내부 설계 철학이 궁금합니다.
1. Toss의 내부 검증이 있음에도, 가맹점 서버에서 한 번 더 검증하라고 권장하는 보안적/비즈니스적 이유는 무엇인가요?
2. Toss는 paymentKey를 통해 일치하지 않는 orderId/amount를 검출하고 항상 차단하는지, 혹은 예외적인 케이스가 존재하나요?
명확한 이해를 바탕으로 보다 견고한 아키텍처를 설계하고자 하니, 답변 주시면 감사하겠습니다!5 Replies
⏳ 잠시만 기다려주세요! 곧 답변드리겠습니다
오류 문의일 경우 아래 정보를 미리 전달해주시면, 빠른 답변에 도움이 됩니다.
- 주문번호(orderId) :
- 문의 내용 :
(img를 함께 첨부해주시면 도움이됩니다)
* 계약관련 내용은 1544-7772로 문의주세요.
* 주말/공휴일에는 답변이 늦을 수 있어요.
1. 보안 위협 중 하나인 금액 위변조 공격을 막기위해서입니다.
2. 차단됩니다
약간 더 설명드리면
금액 위변조가 발생하는 경로가
가맹점에서는 정상금액이었다가 PG로 올릴때만 금액이 변경된 경우가 있는데요 이때 가맹점이 금액을 저장해야 비교가가능합니다
결제창을 열기전 금액이 위변조 되면 PG는 금액의 변화를 알지 못합니다
안녕하세요, 이전에 주신 답변을 토대로 결제 보안 구조에 대해 다시 정리해보았는데, 제가 이해한 내용이 맞는지 확인 부탁드립니다.
---
1. Toss에서는 결제 요청(requestPayment) 시점부터 결제 승인까지(paymentKey 기반)의
orderId, amount의 일치를 내부적으로 검증하여 데이터 정합성을 보장하는 것으로 이해했습니다.
2. 하지만, 이 요청 이전(결제창을 띄우기 전) 단계에서 금액이 위조되거나 조작되는 경우에는 Toss에서는 이를 감지하거나 방지할 수 없기 때문에, 가맹점(서버 측)에서 orderId, amount를 사전에 저장하고 승인 전에 다시 검증해야 한다고 이해했습니다.
3. 결국 Toss가 보장하는 건 "결제 요청 이후의 정합성"이고, 요청 이전 단계의 정합성과 비즈니스 유효성(주문자 일치, 결제 가능 상태 등)은 가맹점의 책임 범위라고 이해했는데, 이 정리가 정확할까요?
---
제가 설계하고 있는 결제 플로우가 보안적으로 문제가 없는지 확인하고자 문의드렸습니다.
감사합니다!1. 맞습니다
2. 맞습니다
3. 맞습니다, 코드상으로도 너무 당연한 내용이긴해요
좋은 서비스 만드시길 바랍니다
❤️ 기술문의 경험이 어떠셨나요?!
간단히 코멘트 남겨주세요! 제품 발전에 큰 힘이 됩니다.