결제 중복 청구 막기 — 새로고침·두 번 클릭·재시도 대비

중복 청구가 생기는 흔한 장면

카드사에서 실제로 두 번 승인되지 않더라도, 우리 DB 에 이용권이 두 번 생기거나 포인트가 두 번 쌓이는 것도 같은 종류의 문제입니다.

• 손님이 결제 단추를 빠르게 두 번 누름 — 주문이 두 개 만들어지고 결제도 두 번 진행됨
• 결제 완료 화면에서 새로고침하거나 뒤로 갔다 다시 옴 — 완료 화면이 다시 불리며 승인·이용권 지급이 한 번 더 일어남
• 휴대폰 통신이 끊겨 앱이 같은 요청을 다시 보냄
• 결제사가 보내는 알림(웹훅)이 다시 옴 — 토스페이먼츠는 내 서버가 정상 응답(200)을 못 주면 웹훅을 최대 7회까지 다시 보낸다고 안내합니다
• 매일 도는 자동 결제(정기결제 예약 작업)가 동시에 두 번 실행됨

멱등성 — "같은 요청은 몇 번 와도 한 번만"

멱등성은 같은 요청을 여러 번 받아도 결과가 한 번 받은 것과 같게 만드는 성질입니다. 결제에서는 주문번호를 기준으로 삼습니다.

토스페이먼츠는 같은 결제를 다시 승인하려 하면 「이미 처리된 결제」(ALREADY_PROCESSED_PAYMENT) 오류를 돌려줍니다. 또 POST 요청에 Idempotency-Key 헤더를 붙이면, 같은 키로 다시 보낸 요청은 다시 실행하지 않고 첫 응답을 그대로 돌려줍니다(키는 첫 요청부터 15일 유효). 하지만 결제사가 막아 줘도 내 DB 의 "이용권 지급"은 내 코드가 막아야 합니다.

막는 방법

1. 결제 단추를 누르면 바로 단추를 잠그고 "처리 중"으로 바꿉니다(화면 쪽 1차 방어).
2. 결제창을 열기 전에 서버가 주문번호를 먼저 만들어 DB 에 「결제 대기」로 저장합니다. 같은 손님이 같은 상품을 다시 누르면 새 주문 대신 기존 대기 주문을 씁니다.
3. 완료 화면이나 웹훅이 오면, 「결제 대기 → 처리 중」으로 바꾸는 일을 DB 에서 조건부로 한 번에 합니다(예: 상태가 대기일 때만 바꾸기). 바꾸기에 성공한 요청 하나만 승인과 이용권 지급을 진행합니다.
4. 주문번호에 DB 고유 제약(같은 값이 두 번 들어가지 못하게)을 겁니다.
5. 이미 처리된 주문으로 다시 오면 오류 대신 "이미 결제됐습니다" 화면을 보여 줍니다.
6. 시간 초과·연결 끊김처럼 결과를 모르는 응답은 「결과 모름」으로 두고, 주문번호로 결제사에 결제 상태를 조회해 맞춥니다. 바로 "실패"로 적고 다시 결제를 시키면 이중 결제가 됩니다.

내 AI 코딩 도구에 이렇게 맡겨 보세요

자주 묻는 질문

함께 보면 좋은 글

• 결제 금액은 서버가 정해야 하는 이유 — 금액 조작 막기
• 토스페이먼츠 가맹 심사 준비 — 홈페이지에서 꼭 볼 것들
• 예약 발송·정기 결제가 한 건 실패로 전부 멈출 때 막는 법

참고

• 토스페이먼츠 — 멱등키(Idempotency-Key)
• 토스페이먼츠 — 에러 코드
• 토스페이먼츠 — 웹훅 연결하기