정[결제위젯 V2] 1차 서버 호출(주문 생성)의 필수 여부에 대해 질문합니다.
안녕하세요. 토스페이먼츠 결제위젯 V2 연동 가이드를 보고 질문드립니다.
[문서 링크] https://docs.tosspayments.com/guides/v2/payment-widget/integration
가이드에서는 "결제 요청 전 1차 서버 호출" -> "결제 인증" -> "결제 승인 전 2차 서버 호출"의 흐름을 권장하고 있습니다.
- 1차 호출: amount 등 검증에 필요한 데이터를 서버에 저장 (주문서 생성)
- 2차 호출: 1차에서 저장한 amount와 2차에서 받은 amount를 비교하여 검증 후 승인
[저의 의문점] "왜 1차 서버 호출이 필수적인가?" 입니다.
어차피 최종 결제 승인은 2차 서버 호출에서 일어납니다.
그렇다면, 1차 호출(주문서 생성) 과정을 생략하고, 결제 인증이 완료된 직후 2차 호출 시점에 클라이언트로부터 결제에 필요한 모든 정보(예: productId 또는 cartId, amount, paymentKey, orderId)를 한 번에 받아 검증하면 안 되는 이유가 궁금합니다.
[제가 생각하는 1차 호출이 없는 시나리오]
1. (1차 호출 없음)
2. 클라이언트가 결제 위젯을 띄워 '결제 인증'을 완료하고 paymentKey 등을 받습니다.
3. 클라이언트가 서버의 '결제 승인 API' (2차 호출)에 productId, amount, paymentKey, orderId를 전달합니다.
4. 서버는 이 시점에 실시간으로 다음을 검증합니다.
- productId를 이용해 서버 DB에서 '실제 가격'을 조회합니다.
- 쿠폰/배송비 등이 있다면 함께 계산하여 '최종 결제액'을 확정합니다.
- 서버가 계산한 '최종 결제액'과 클라이언트가 보낸 amount가 일치하는지 비교합니다.
- 일치하면 '결제 승인'을 하고, 불일치하면 승인을 거부합니다. (어차피 승인 전이므로 사용자 돈이 빠져나가지 않습니다.)
[질문 요약]
제가 아는 한, 1차/2차 호출 모두 클라이언트가 API를 호출하는 것이므로, 악의적인 사용자는 1차, 2차 모두 amount를 조작해서 보낼 수 있습니다.
그렇다면 1차 호출에서 amount를 미리 저장하는 것이, 2차 호출에서 productId 기준으로 실시간 검증하는 것보다 보안적으로 어떤 결정적인 이점이 있는지 궁금합니다.
구현 난이도 면에서도 1차 호출과 함께 pending 상태의 order를 미리 생성하는 것보다 2차 호출에서만 검증, 주문 생성, 결제 승인을 모두 처리하는 것이 편할거같습니다.
혹은, 제가 놓치고 있는 재고 문제나, 쿠폰/가격 변동으로 인한 레이스 컨디션, 혹은 UX(사용자 경험) 측면의 심각한 이슈가 있다면 알려주시면 감사하겠습니다.
[문서 링크] https://docs.tosspayments.com/guides/v2/payment-widget/integration
가이드에서는 "결제 요청 전 1차 서버 호출" -> "결제 인증" -> "결제 승인 전 2차 서버 호출"의 흐름을 권장하고 있습니다.
- 1차 호출: amount 등 검증에 필요한 데이터를 서버에 저장 (주문서 생성)
- 2차 호출: 1차에서 저장한 amount와 2차에서 받은 amount를 비교하여 검증 후 승인
[저의 의문점] "왜 1차 서버 호출이 필수적인가?" 입니다.
어차피 최종 결제 승인은 2차 서버 호출에서 일어납니다.
그렇다면, 1차 호출(주문서 생성) 과정을 생략하고, 결제 인증이 완료된 직후 2차 호출 시점에 클라이언트로부터 결제에 필요한 모든 정보(예: productId 또는 cartId, amount, paymentKey, orderId)를 한 번에 받아 검증하면 안 되는 이유가 궁금합니다.
[제가 생각하는 1차 호출이 없는 시나리오]
1. (1차 호출 없음)
2. 클라이언트가 결제 위젯을 띄워 '결제 인증'을 완료하고 paymentKey 등을 받습니다.
3. 클라이언트가 서버의 '결제 승인 API' (2차 호출)에 productId, amount, paymentKey, orderId를 전달합니다.
4. 서버는 이 시점에 실시간으로 다음을 검증합니다.
- productId를 이용해 서버 DB에서 '실제 가격'을 조회합니다.
- 쿠폰/배송비 등이 있다면 함께 계산하여 '최종 결제액'을 확정합니다.
- 서버가 계산한 '최종 결제액'과 클라이언트가 보낸 amount가 일치하는지 비교합니다.
- 일치하면 '결제 승인'을 하고, 불일치하면 승인을 거부합니다. (어차피 승인 전이므로 사용자 돈이 빠져나가지 않습니다.)
[질문 요약]
제가 아는 한, 1차/2차 호출 모두 클라이언트가 API를 호출하는 것이므로, 악의적인 사용자는 1차, 2차 모두 amount를 조작해서 보낼 수 있습니다.
그렇다면 1차 호출에서 amount를 미리 저장하는 것이, 2차 호출에서 productId 기준으로 실시간 검증하는 것보다 보안적으로 어떤 결정적인 이점이 있는지 궁금합니다.
구현 난이도 면에서도 1차 호출과 함께 pending 상태의 order를 미리 생성하는 것보다 2차 호출에서만 검증, 주문 생성, 결제 승인을 모두 처리하는 것이 편할거같습니다.
혹은, 제가 놓치고 있는 재고 문제나, 쿠폰/가격 변동으로 인한 레이스 컨디션, 혹은 UX(사용자 경험) 측면의 심각한 이슈가 있다면 알려주시면 감사하겠습니다.
