김[Toss Payments 문의] 결제 승인 전 서버 검증이 필요한 이유에 대한 질문
안녕하세요, 토스페이먼츠를 통해 결제 시스템을 연동하고 있는 개발자입니다.
공식 문서에서 안내해주신 “결제 요청 전에 orderId와 amount를 서버에 저장하고, 승인 전에 다시 검증하라”는 가이드를 보고 궁금한 점이 생겼습니다.
Toss에서는 결제 요청 시
이 경우에도 클라이언트 측에서 금액을 조작하더라도 Toss 자체에서 승인 실패가 발생하기 때문에, 이미 Toss 레벨에서 충분한 검증이 되는 것 아닌가요?
그런데 문서에서는 다시 한 번 서버에 요청 정보를 저장하고 검증하라고 권장하고 있어서 해당 로직의 목적과 Toss의 내부 설계 철학이 궁금합니다.
1. Toss의 내부 검증이 있음에도, 가맹점 서버에서 한 번 더 검증하라고 권장하는 보안적/비즈니스적 이유는 무엇인가요?
2. Toss는 paymentKey를 통해 일치하지 않는 orderId/amount를 검출하고 항상 차단하는지, 혹은 예외적인 케이스가 존재하나요?
명확한 이해를 바탕으로 보다 견고한 아키텍처를 설계하고자 하니, 답변 주시면 감사하겠습니다!
공식 문서에서 안내해주신 “결제 요청 전에 orderId와 amount를 서버에 저장하고, 승인 전에 다시 검증하라”는 가이드를 보고 궁금한 점이 생겼습니다.
Toss에서는 결제 요청 시
orderIdorderId, amountamount 값을 paymentKeypaymentKey에 바인딩해 저장하고, 승인 요청 시 해당 값이 다를 경우 에러를 리턴하는 것으로 알고 있습니다.이 경우에도 클라이언트 측에서 금액을 조작하더라도 Toss 자체에서 승인 실패가 발생하기 때문에, 이미 Toss 레벨에서 충분한 검증이 되는 것 아닌가요?
그런데 문서에서는 다시 한 번 서버에 요청 정보를 저장하고 검증하라고 권장하고 있어서 해당 로직의 목적과 Toss의 내부 설계 철학이 궁금합니다.
1. Toss의 내부 검증이 있음에도, 가맹점 서버에서 한 번 더 검증하라고 권장하는 보안적/비즈니스적 이유는 무엇인가요?
2. Toss는 paymentKey를 통해 일치하지 않는 orderId/amount를 검출하고 항상 차단하는지, 혹은 예외적인 케이스가 존재하나요?
명확한 이해를 바탕으로 보다 견고한 아키텍처를 설계하고자 하니, 답변 주시면 감사하겠습니다!
