예약결제는 언제 쓰나요?

핵심 요약

• 예약결제는 발급된 빌링키로 지정 미래 시점에 1회 청구를 예약​​하는 구조예요. 자동결제(빌링)와 API는 같지만 목적이 달라요​: 자동결제는 반복 과금, 예약결제는 지정 시점 1회​.
• 청구 시점과 금액이 비교적 고정적이면 빌링키로 결제 예약을 걸어두는 쪽이 편해요. 반대로 시점이나 금액이 자주 바뀌면 자체 cron·스케줄러로 직접 돌리는 쪽이 더 유연할 수 있어요.
• 적합한 서비스: 숙박 체크인 당일 과금, 렌터카 반납 후 정산, 예약금/잔금 분할, 사용량 집계 후 결제, B2B 납기 후 결제​.
• 도입 전 정할 것: 예약 시점 기준 · 금액 변동 처리 · 예약 취소/변경 정책 · 실패 시 재시도 · 웹훅 수신 체계​.

이런 상황이라면

펜션·독채 숙박을 중개하는 플랫폼을 운영해요. 지금까지는 예약 시점에 전체 금액을 미리 결제​​받는 구조였는데, 고객 이탈이 커요. "한 달 뒤 체크인인데 왜 지금 돈을 내냐"는 문의가 자주 나와요. 그래서 예약 시 10% 예약금만 받고, 체크인 당일에 잔금 90%를 결제​​하는 구조로 바꾸려 해요.

개발자분과 논의해보니 "잔금 청구를 서버 cron으로 직접 돌릴 수도 있고, 빌링키로 결제 예약을 걸어둘 수도 있어요​"고 해요. 예약결제가 정확히 뭔지, 자동결제(빌링)와 뭐가 다른지, 도입 전에 뭘 미리 정해야 하는지 정리가 안 돼요.

이 글은 예약결제가 어떤 구조이고, 어떤 서비스에 맞고, 도입 전에 확정해야 할 항목을 다뤄요.

1예약결제는 "지정 시점 1회 청구의 스케줄러 위임"이에요

예약결제는 자동결제(빌링)와 동일한 빌링키를 쓰지만, 사용 방식이 달라요.

• 자동결제​: 서버가 매달/매주 반복 과금​​을 요청해요. 스케줄은 우리 서버가 결정해요.
• 예약결제​: 서버가 미래 특정 시점에 1회 청구를 예약​​해요. 한 번 예약해두면 해당 시점에 PG사 쪽 배치가 알아서 청구를 진행해요.

• 자동결제​​는 동일한 시간축 위에 주기적으로 청구 이벤트가 찍혀요. 서버 cron이 매번 트리거해요.
• 예약결제​​는 같은 기간에 예약 등록 한 번, 지정 시점에 청구 실행 한 번이에요. 트리거는 PG사 배치가 담당해요.

예약결제의 본질은 "청구 시점이 비교적 고정적일 때, 빌링키로 결제 예약을 걸어두고 PG사 쪽 배치에 맡기는 구조"​​라는 점이에요. 반대로 청구 시점이나 금액이 자주 바뀌면 자체 cron이 더 맞을 수 있어요.

2예약결제를 선택하는 5가지 시나리오

시나리오 1. 숙박 체크인 당일 과금

예약 시에는 빌링키만 발급받고, 체크인 당일 오후 2시​​에 전액 또는 잔금을 자동 청구해요. 고객이 노쇼할 때도 빌링키로 청구가 가능하므로 플랫폼 수익을 보호해요.

예약 시점​: 체크인 당일 14:00 금액​: 총액 또는 잔금

시나리오 2. 렌터카·렌탈 반납 후 정산

렌터카·공유 킥보드·장비 렌탈에서 사용 종료 후 실제 사용량·연체료·파손비를 합산해 결제​​해요. 주문 시점에는 빌링키만 확보하고, 반납 시점에 금액을 확정해 예약결제로 청구해요.

예약 시점​: 반납 확인 직후 금액​: 실 사용량 기반 변동

시나리오 3. 예약금 + 잔금 분할

결혼식장, 맞춤 제작, 고가 서비스처럼 계약 시 일부 선결제 + 이행 시 잔금 결제 구조예요. 예약금은 결제창으로, 잔금은 예약결제로 지정 시점에 청구.

예약 시점​: 이행일 또는 납기일 금액​: 사전 확정

시나리오 4. 사용량 집계 후 결제

월 단위 API 사용량, 배달 누적 건수, 데이터 사용량처럼 기간 종료 시점에 누적 금액을 청구​​해요. 자동결제와 비슷해 보이지만 매달 금액이 다르고 집계가 필요​​한 경우 예약결제가 적합해요.

예약 시점​: 정산 마감일 금액​: 집계 결과

시나리오 5. B2B 납기 후 결제

법인 고객과 납기 후 N일 내 결제 계약을 맺는 경우예요. 납품 완료 시점에 빌링키로 청구를 예약하고, 계약된 결제일에 자동 청구돼요. 미수금 리스크가 줄고 영업·회계 부담이 감소해요.

예약 시점​: 납기일 + 계약 결제 기한 금액​: 계약 금액

분할·정기 반복이 섞이면 예약결제가 아니에요. PT 10회권처럼 회차를 쪼개 파는 구조는 분할결제 영역이고, 매달 같은 금액을 반복 청구한다면 자동결제(구독) 영역이에요. 예약결제는 "지정 시점 1회 청구" 본질을 지킬 때 가장 깔끔해요. 복수 회차가 필요하면 각 회차를 독립된 예약 1건으로 등록하는 방식이 나아요.

3도입 전 정할 4가지

① 금액 변동 처리 — 확정 시점은 언제일까요

예약 등록 시점에 금액이 확정​​되는 경우(잔금 결제)와 청구 직전에 금액이 결정​​되는 경우(사용량 기반, 연체료 포함)가 있어요. 금액이 자주 바뀌면 예약결제보다 자체 cron으로 최종 금액을 계산해 직접 청구하는 쪽이 더 다루기 쉬워요. 반대로 금액과 시점이 어느 정도 고정적이라면 예약결제로 미리 걸어두는 편이 단순해요.

② 예약 취소·변경 정책

예약 등록 후 일정·금액 변경​​이나 취소 요청은 분쟁이 가장 많이 발생하는 지점이에요. 청구 실행 전/후로 흐름이 갈리고, 일정 변경은 대부분 "취소 후 재등록"으로 처리돼요. 도입 전에 취소 매트릭스와 변경 트랜잭션 설계를 확정해 둬야 해요.

→ 예약결제 취소 정책

③ 실패 시 재시도 전략

예약 시점에 청구가 실패하는 이유는 다양해요.

• 카드 한도 초과·정지
• 카드 만료
• 빌링키가 이미 삭제됨
• PG 일시 장애

실패 시 어떻게 처리할지​​를 정책으로 정해요.

• 즉시 웹훅 → 고객에게 "결제 수단 업데이트 요청" 알림
• 자동 재시도 N회 → 실패 지속 시 서비스 제한
• 수동 재시도 UI → 관리자가 대체 결제수단으로 재처리

④ 웹훅 수신 체계

여기서는 즉시 응답​​과 미래 시점 실행 결과​​를 분리해서 봐야 해요.

• 예약 등록 시점​: 서버가 예약결제 요청을 보내면, 등록 성공/실패는 즉시 응답​​으로 확인해요.
• 예약 취소 시점​: 취소 요청의 성공/실패도 먼저 즉시 응답​​으로 확인해요.
• 미래 청구 시점​: 실제 예약된 시간이 되어 청구가 실행된 결과는 웹훅​​으로 받아요.

즉 웹훅이 필요한 구간은 나중에 실행되는 청구 결과​​예요. 서버가 웹훅을 받지 않으면, 예약은 걸어뒀지만 실제 청구가 성공했는지 실패했는지 자동으로 알기 어려워요.

실무에서는 아래처럼 나눠서 보면 돼요.

• 예약 등록 성공/실패 → 즉시 응답
• 예약 취소 성공/실패 → 즉시 응답
• 예약 시점 청구 성공 → 웹훅
• 예약 시점 청구 실패 + 사유 코드 → 웹훅

거래량이 적으면 관리자 콘솔에서 수동 확인도 가능하지만, 예약 건이 늘면 미래 시점 청구 결과를 놓치지 않도록 웹훅 수신 체계가 사실상 필수예요.

4세금계산서·현금영수증은 청구 시점에 발행돼요

예약결제는 실제 청구 시점에 승인​​되므로 세금계산서·현금영수증도 그 시점에 발행돼요. 예약 시점이 아니에요. 회계·세무 담당자가 혼동하지 않도록 내부 공지가 필요해요.

빌링키 동기화·일정 변경 트랜잭션·노쇼 처리처럼 취소 쪽에서 자주 놓치는 지점은 예약결제 취소 정책에서 다뤄요.

5우리 서비스에 예약결제가 맞는지 3단계 점검

① 주문 시점과 청구 시점이 분리되는가

예​: 예약결제가 유리. 아니오​: 결제창·자동결제로 충분.

② 청구 시점이 미래의 특정 지점인가 (반복이 아닌)

예 (지정 시점 1회): 예약결제. 아니오 (반복): 자동결제.

③ 자체 스케줄러 운영 부담을 줄이고 싶은가

예​: 예약결제로 PG사 배치에 맡겨요. 아니오 (시점/금액 변동이 잦음): 빌링 직접 + 자체 cron.

세 질문에 모두 "예"라면 예약결제가 구조적으로 가장 맞아요.

실제로 붙이려면

예약결제를 실제로 등록하고 상태를 확인하는 흐름은 다음 문서에서 봐요.

• 결제 예약 — /reserve/charge
• 예약 조회 — /reserve/lookup