핵심 요약
- 예약결제 취소는 청구 실행 전/후로 완전히 갈려요. 청구 전은 예약 해지(과금 예정 제거), 청구 후는 결제 취소(이미 승인된 건)다. API·비용·시점 제약이 전부 달라요.
- 일정·금액 변경은 "수정"이 아니라 취소 후 재등록이에요. 예약결제 API 대부분이 수정을 지원하지 않아요. "취소는 됐는데 재등록은 실패"한 상태가 생기지 않도록 트랜잭션 설계가 필요해요.
- 빌링키 삭제·고객 탈퇴·카드 만료가 생기면 예약된 청구는 그대로 실패해요. 이 변화를 사전에 자동으로 알려주는 이벤트는 없고, 실패 건은 사실상 CS 이슈예요. 결제 링크 재전송·새 빌링키 발급 안내·예약 자동 해지(서비스 정지) 같은 CS 대응 시나리오를 가맹점이 먼저 정해 둬야 해요.
1청구 실행 전인지 후인지부터 갈라 봐요
"예약결제 취소"라는 한 단어 안에는 실은 두 개의 다른 작업이 섞여 있어요. 청구 실행 시점이 지났는지 아닌지에 따라 호출하는 API, 비용, 시점 제약이 전부 달라져요.
| 구분 | 청구 전 — 예약 해지 | 청구 후 — 결제 취소 |
|---|---|---|
| 호출 API | 예약 해지 API | 결제 취소 API |
| 대상 | 미래 시점에 잡혀 있는 과금 예정 | 이미 승인된 결제 건 |
| 고객 체감 | 청구 자체가 일어나지 않음 | 카드 내역에 결제 → 취소가 찍힘 |
| 비용 | 거의 없음 | PG 취소 수수료·카드사 정책 |
| 시점 제약 | 청구 실행 직전까지 | 결제 후 N일 이내 (PG·카드사별) |
숙박 예시로 보면 명확해요. 예약 시점에 결제된 예약금 10%는 이미 승인된 건이라 되돌리려면 결제 취소 API를 호출해야 해요. 체크인 당일로 잡혀 있는 잔금 90% 자동청구는 아직 실행 전이라 예약 해지만 하면 끝나요. 한 건의 취소 요청이 두 개의 다른 API를 타야 하는 구조예요.
용어 구분: 이 문서에서 "결제 취소"는 PG API로 이미 승인된 결제를 되돌리는 작업을 말해요. 가상계좌 입금 후처럼 카드 취소 API가 통하지 않아 고객 계좌로 직접 돈을 송금해야 하는 상황은 "환불"로 별도 구분해요. 예약결제는 대부분 빌링키(카드) 기반이라 실무에선 "결제 취소"가 기본 경로예요.
고객 입장에서는 청구 전이든 후든 똑같이 "취소"로 느끼지만, 내부적으로는 API가 완전히 달라요. 그래서 UI 라벨과 CS 문구도 용어를 다르게 쓰길 추천해요. 예를 들어 청구 전 흐름은 "예약 취소", 청구 후 흐름은 "결제 취소"로 고객 화면부터 구분해 두면 고객·CS·운영 담당자분 사이에서 혼동이 줄어들어요.
참고로 청구 후 결제 취소 버튼을 고객에게 그대로 노출할지는 서비스 정책에 따라 달라요. 이용이 끝난 뒤에는 고객이 직접 취소하지 못하게 막고 CS 문의로만 받는 서비스도 많아요. 노출 방식이 어떻든 내부 처리 흐름은 예약 해지 API와 결제 취소 API 두 개로 분리돼 있어야 해요.
2일정 변경은 수정이 아니라 "취소 후 재등록"이에요
고객이 체크인 날짜를 다음 주로 바꾸자고 하면 "예약 수정"으로 생각하기 쉽지만, 예약결제 API는 대부분 등록된 예약의 시점·금액 수정을 지원하지 않아요. 변경 요청은 실무상 거의 항상 기존 예약 취소 → 새 예약 등록 2단계로 처리돼요.
문제는 이 두 단계가 원자적이지 않다는 점이에요. 흐름이 중간에 깨지면 아래 같은 상태가 생겨요.
- 기존 예약 취소 성공 → 새 예약 등록 실패 → 빌링키만 남고 예약은 없음
- 기존 예약 취소 실패 → 새 예약 등록 성공 → 중복 청구 예정
설계 원칙은 "새로 등록 먼저, 기존 취소 나중" 순서예요.
이 순서라면 "새 예약 등록 실패" 시에도 기존 일정이 그대로 유지되는 안전한 상태가 돼요. "기존 해지 실패"만 관리자가 직접 개입하면 돼요.
사실 ①은 실무에서 거의 발생하지 않아요. 이 시점에는 실제 과금이 아니라 예약만 거는 요청이라 PG 쪽 장애가 아닌 한 대부분 성공해요. 설계 무게중심은 ② 기존 해지 실패 쪽이에요. 그럼에도 ①을 분기로 남겨 두는 이유는 장애 시점에 기존 일정이 그대로 유지되는 상태가 안전망이 되기 때문이에요. 순서를 뒤집어 기존을 먼저 해지해 버리면 같은 PG 장애에도 고객은 예약이 사라진 상태로 노출돼요.
3빌링키·고객 상태 변화는 실패 후에야 알 수 있어요
예약결제는 예약 등록 시점과 청구 실행 시점 사이에 시간이 있어요. 그 사이에 빌링키가 삭제되거나 카드가 만료되면 예약은 그대로 실패하는데, 이 변화를 사전에 자동으로 알려주는 이벤트는 없어요. 결국 내부 탈퇴·빌링키 삭제 플로우 안에서 직접 챙기거나, 청구가 실제로 실패한 뒤에 CS 대응으로 돌리는 두 경로만 남아요.
정해 둘 포인트는 두 가져요.
① 탈퇴·빌링키 삭제 플로우에 예약 해지 포함
탈퇴 워크플로우에 "예약된 결제가 있는지 확인 → 예약 해지 또는 대체 수단 요청" 단계를 반드시 넣어요. 빌링키 삭제도 마찬가져요. 내부 코드에서 직접 붙이는 구간이라 확정적으로 제어 가능한 유일한 지점이에요.
② 청구 실패 시 CS 대응 시나리오
예약결제에는 자동 복구 메커니즘이 없어요. 카드 유효성을 청구 며칠 전에 미리 확인할 수 있으면 좋지만, 예약결제에서 유효성 확인 수단은 "100원 결제 후 취소" 수준뿐이고, 단건 예약이라 "며칠 뒤에 결제돼요"를 사전 공지하기도 애매해요. 결국 실패 건은 CS 이슈로 넘어가요.
핵심은 "CS 담당자분이 알아서 판단하세요"가 아니라 가맹점이 실패 후 접촉 시나리오를 미리 정해 두는 것이에요. 정해져 있지 않으면 같은 실패 건이 담당자별로 다르게 처리돼요. 실무에서 가장 많이 쓰는 추천 순서는 아래와 같아요.
- ① 결제 링크 재전송 — 실패 금액으로 결제 링크를 만들어 알림톡·SMS·이메일로 보내요. 빌링키 없이 즉시 결제 가능해 회수율이 가장 높아요.
- ② 새 빌링키 발급 안내 — "다른 카드 등록 후 재결제" 플로우. 이후에도 예약결제를 계속 쓸 고객이라면 장기적으로 이 경로가 맞아요.
- ③ 기한 내 미결제 시 예약 자동 해지(서비스 정지) + 고객 안내 — 위 두 경로가 닫히면 예약을 끝내고 재고·일정을 다른 고객에게 돌려요. 숙박·렌터카라면 이용 자체를 막는 서비스 정지로도 이어져요.
실패 후 몇 시간 안에 접촉할지, 어느 단계에서 자동 해지로 넘길지를 가맹점 내부 정책으로 못 박아 두면 CS 일관성이 유지돼요.
4우리 서비스에 예약결제 취소 정책이 작동하는지 3단계 점검
① 청구 전/후 취소 흐름이 분리돼 있는가
예: 예약 해지 API와 결제 취소 API가 분리된 흐름으로 운영되고, 고객 화면에도 각각이 다른 결과로 보여요. 아니오: "취소" 버튼 하나가 두 작업을 같이 처리한다 → 청구 전 해지와 청구 후 결제 취소를 정책 문서와 운영 화면에서 먼저 분리.
② 일정 변경이 "새로 등록 → 기존 취소" 순서로 구현됐는가
예: 새 예약 등록 실패 시 기존 일정이 그대로 유지돼요. 아니오: 기존 취소가 먼저 실행된다 → 장애가 나면 고객 예약이 사라진 상태로 노출돼요. 순서부터 뒤집어요.
③ 탈퇴·빌링키 삭제·청구 실패에 CS 대응 시나리오가 정해져 있는가
예: 내부 탈퇴·빌링키 삭제 플로우 안에서 예약 해지를 직접 처리해요. 청구 실패 건은 결제 링크 재전송 → 새 빌링키 발급 안내 → 기한 내 미결제 시 자동 해지(서비스 정지) 순서가 CS 매뉴얼로 박혀 있어요. 아니오: 실패 건이 CS 담당자별로 다르게 처리된다 → 접촉 채널·접촉 기한·기한 내 미결제 시 조치를 한 문서로 고정해요.
세 질문에 모두 "예"라면 예약결제 취소 정책이 운영 문서로 작동하고 있어요.
실제로 붙이려면
취소 정책을 SDK에서 어떻게 호출하는지는 다음에서 봐요.
- 예약 취소 — /reserve/cancel
- 예약 조회 — /reserve/lookup