결제 기능을 붙이기 전에 무엇을 정해야 하나요?
화면보다 먼저 결제가 끝난 뒤와 실패했을 때의 처리 기준을 정해야 합니다. 무엇을 파는지, 결제가 어디서 시작되는지, 결제 뒤 재고·쿠폰·적립금을 언제 확정하고 취소되면 어떻게 되돌리는지, 실패하면 구매자가 무엇을 누르는지, 주문 상태를 어떻게 나눌지입니다. 이 기준이 없으면 결제는 됐는데 주문이 없거나 입금 전에 상품이 나가는 일이 생깁니다.
결제 이후를 먼저 적습니다
- 무엇을 파는지 — 실물·디지털 이용권·예약금에 따라 배송, 지급, 환불 기준이 달라집니다.
- 결제가 어디서 시작되는지 — 주문서에서 바로인지, 상담 뒤 링크를 보내는지, 구독처럼 자동결제인지.
- 주문서에 보여줄 것 — 상품명, 옵션, 수량, 할인, 배송비, 최종 금액, 약관 동의.
- 결제가 끝나면 — 재고 차감, 쿠폰·적립금 확정, 이용권 개시나 배송 준비를 언제 하는지.
- 취소되면 — 재고를 돌릴지, 쿠폰을 복구할지, 적립금을 회수할지.
성공과 실패만으로는 CS가 안 됩니다
결제창을 띄우는 순간 주문을 결제대기 상태로 먼저 만들어 두어야 합니다. 그래야 "결제했는데 주문이 없어요" 문의가 왔을 때 금액·상품·시도 시각·구매자로 그 건을 찾을 수 있습니다. 여기서 결제완료, 결제실패, 취소완료, 부분취소, 가상계좌 입금대기와 입금완료로 넘어가는 흐름을 잡습니다.
결제완료로 바꾸는 기준은 결제창의 완료 화면이 아니라 서버 검증 통과입니다. 가상계좌는 계좌 발급이 아니라 입금완료 웹훅을 받았을 때 완료로 바꿉니다.
실패 사유는 그대로 보여주고, 다음 행동은 버튼으로
실패 사유는 잔액 부족, 한도 초과, 비밀번호 오류, 카드사 점검처럼 다양해서 문구를 새로 만들 필요가 없습니다. 부트페이가 내려주는 실패 메시지를 그대로 보여주고, 다시 결제하기·다른 결제수단 선택·문의하기 버튼을 붙이면 됩니다.
"오류가 발생했습니다"로 뭉개면 구매자는 무엇을 해야 할지 모르고 운영팀은 원인을 추적하지 못합니다.
웹훅을 받았을 때의 처리도 기획서에 들어갑니다
구매자가 결제창을 닫거나 앱으로 돌아오지 못하면 브라우저 신호가 서버에 닿지 않습니다. 웹훅이 왔을 때 주문 상태를 어떻게 바꿀지, 같은 웹훅이 두 번 오면 어떻게 막을지를 개발 전에 정해 두어야 주문 누락이 생기지 않습니다.