핵심 요약
- 결제 취소는 단순히 환불 버튼 하나의 문제가 아니라, 결제수단별 가능 범위와 정산 시점, 고객 안내까지 함께 다뤄야 하는 운영 흐름이에요.
- 전액 취소와 부분 취소는 같은 취소 API를 쓰더라도 제약과 후속 처리 방식이 달라요.
- 취소 요청은 가맹점 서버에서 시작해 Bootpay와 PG를 거쳐 최종 정산 상태로 반영되며, 이 과정에서 상태 동기화와 중복 방지가 중요해요.
- 이의신청, 재취소, 부분 취소 누적 같은 예외 상황을 처음부터 운영 시나리오로 잡아두어야 고객 문의에 흔들리지 않아요.
이런 상황이라면
고객이 주문을 취소하거나 부분 환불을 요청해요. 결제는 완료됐는데 배송 누락, 오과금, 재고 이슈로 환불을 처리해야 해요. 개발자는 취소 API를 붙였지만 어떤 경우에 전액 취소와 부분 취소를 나눠야 하는지 운영 기준이 필요해요.
이 글은 결제 취소를 실무 시나리오 기준으로 정리하고, 전액 취소, 부분 취소, 이의신청 대응 시 어디를 확인해야 하는지 다뤄요.
1취소 가능 범위
결제 취소는 크게 전액 취소와 부분 취소로 나뉘어요. 기능적으로는 비슷해 보여도 운영 의미는 달라요.
| 구분 | 의미 | 주의할 점 |
|---|---|---|
| 전체 취소 | 결제 금액 전체를 한 번에 취소해요 | 가장 단순하지만, 일부 품목만 취소해야 하는 상황에는 맞지 않는다 |
| 부분 취소 | 전체 금액 중 일부만 나누어 취소해요 | PG 지원 여부, 남은 취소 가능 금액, 면세 금액 계산을 함께 봐야 한다 |
전체 취소는 고객이 주문 전체를 포기하거나, 결제 직후 오류가 났을 때 가장 많이 쓰여요. 상태도 단순해요. 주문을 취소 처리하고, 환불 안내를 보내고, 정산 반영만 확인하면 돼요.
부분 취소는 더 복잡해요. 대표적으로 다음 상황에서 필요해요.
- 여러 상품 중 일부만 품절됐어요.
- 배송비를 제외한 상품 금액만 환불해야 해요.
- 사용자가 옵션 일부만 변경하면서 차액 환불이 필요해요.
이때 중요한 것은 "기술적으로 부분 취소가 가능한가"보다 "회계와 고객 커뮤니케이션까지 맞는지예요. 누적 부분 취소가 여러 번 발생하면 남은 취소 가능 금액 계산과 주문 상태 정의가 금방 꼬여요.
2취소 요청 흐름
취소는 가맹점 관리자 화면에서 버튼을 누르는 행동으로 시작되더라도, 시스템 관점에서는 서버가 상태를 주도해야 안정적이에요.
기본 흐름
| 단계 | 주체 | 하는 일 |
|---|---|---|
| 1 | 가맹점 서버 | 취소 대상 주문과 영수증 ID, 취소 금액을 확인해요 |
| 2 | 가맹점 서버 | 결제 취소 API를 호출한다 |
| 3 | Bootpay | 요청 형식과 상태를 확인하고 PG로 취소를 전달해요 |
| 4 | PG | 실제 승인 취소 또는 환불 가능 여부를 처리해요 |
| 5 | Bootpay | 결과를 서버에 반환하고 필요 시 웹훅으로 상태를 알린다 |
| 6 | 가맹점 서버 | 주문 상태, 취소 이력, 고객 안내, 정산 메모를 갱신해요 |
서버가 꼭 책임져야 하는 것
- 같은 주문에 중복 취소 요청이 들어오지 않게 막아요.
- 부분 취소라면 남은 취소 가능 금액을 선계산해요.
- 취소 성공 후 주문 상태를 정확히 갱신해요.
- 고객에게 전체 취소인지 부분 취소인지 명확히 안내해요.
운영에서는 PG 관리자에서 직접 취소하고 싶은 유혹이 생기지만, 그렇게 하면 서비스 내부 주문 상태와 Bootpay 상태가 쉽게 어긋나요. 취소는 가급적 서비스 서버와 Bootpay API를 중심으로 처리하는 편이 안전해요.
3부분 취소의 케이스
부분 취소는 기능보다 시나리오를 먼저 정리해야 해요. 대표적으로 아래 세 갈래가 많아요.
| 케이스 | 설명 | 체크 포인트 |
|---|---|---|
| 일부 상품 품절 | 주문 중 특정 상품만 제공 불가하다 | 남은 상품 금액, 배송비 재계산, 고객 재동의 여부 |
| 배송비 차감 환불 | 일부 상품 취소로 배송비 정책이 바뀐다 | 취소 금액에 배송비를 포함할지 따로 계산할지 |
| 사후 보상성 환불 | CS 보상이나 가격 조정으로 일부만 환불한다 | 주문 상태는 유지하되 환불 이력만 쌓을지 결정 |
부분 취소를 붙일 때 흔히 놓치는 부분은 주문 도메인과 결제 도메인이 다르다는 점이에요. 결제 시스템은 금액만 취소하지만, 서비스는 상품, 쿠폰, 적립금, 배송 상태까지 함께 다시 계산해야 해요.
그래서 부분 취소는 다음 순서로 보는 편이 좋아요.
- 어떤 품목 또는 비용 항목이 줄어드는지 정해요.
- 남은 주문 금액과 세금, 배송비를 다시 계산해요.
- 그 결과를 기준으로 취소 금액을 확정해요.
- 결제 취소 API를 호출해야 해요.
- 취소 결과를 주문 상세와 고객 안내에 반영해요.
즉 부분 취소는 결제 기능이 아니라 주문 재계산 기능과 함께 설계해야 해요.
4이의신청·재취소
취소가 한 번에 끝나지 않는 경우도 많아요. 고객은 환불이 늦다고 느끼거나, 일부 취소 후 나머지 금액도 다시 환불해달라고 요청할 수 있어요. 이 구간에서 운영 정책이 없으면 CS가 개발 이슈로 번지기 쉬워요.
자주 만나는 예외 상황
- 취소 요청은 성공했지만 카드사 반영이 늦어요.
- 부분 취소 후 남은 금액에 대해 추가 취소 요청이 들어와요.
- 고객은 취소됐다고 생각하지만 실제로는 승인 실패나 보류 상태예요.
- 운영자가 PG 화면과 서비스 화면 중 서로 다른 상태를 봐요.
이의신청 대응에서는 다음 기준이 중요해요.
- 서비스 내부 취소 이력과 Bootpay 응답 이력을 남겨야 해요.
- 취소 요청 시각과 취소 성공 시각을 구분해 저장해야 해요.
- 카드사 반영 지연 가능성을 고객 안내 문구에 포함해야 해요.
- 부분 취소가 누적될 수 있다면 취소 잔액 계산을 자동화해야 해요.
재취소는 특히 부분 취소가 여러 번 일어나는 서비스에서 중요해요. 기술적으로는 "남은 취소 가능 금액"을 기준으로 추가 취소를 판단하면 되지만, 운영적으로는 주문 상태가 무엇인지 더 중요해요. 일부 배송 완료, 일부 환불 같은 중간 상태를 허용할지 먼저 정리해야 해요.
5자주 발생하는 에러
취소에서 자주 만나는 에러는 대부분 상태 불일치나 금액 계산 문제에서 나와요.
| 유형 | 흔한 원인 | 대응 방향 |
|---|---|---|
| 이미 취소된 결제 | 동일 주문에 중복 요청이 들어갔다 | 취소 요청 idempotency와 서버 상태 잠금을 둔다 |
| 취소 가능 금액 초과 | 부분 취소 누적 계산이 틀렸다 | 남은 취소 가능 금액을 서버 기준으로 다시 계산한다 |
| 부분 취소 미지원 | PG 또는 결제수단 제약이 있다 | 전체 취소 가능 여부와 운영 대안을 확인해요 |
| 결제 상태 불일치 | 서비스, Bootpay, PG 상태가 서로 다르다 | 취소 전에 결제 조회로 최신 상태를 다시 확인해요 |
| 고객 체감 지연 | 카드사 반영까지 시간이 걸린다 | 취소 완료와 환불 반영 예정 시점을 분리해 안내해요 |
기술적으로는 에러를 핸들링하면 끝나지만, 실무에서는 고객 안내가 절반이에요. "취소 요청 접수", "취소 완료", "카드사 반영 예정"을 한 문장으로 뭉개지 말고 단계별로 나누는 편이 문의를 줄여요.
API 요청 파라미터와 언어별 예시는 결제 취소 API 레퍼런스에서 확인하면 돼요. 이 문서는 운영 판단과 시나리오에 집중해요.