자동결제는 고객이 한 번 등록한 결제수단을 billing_key로 바꿔두고, 그 다음부터 서버가 필요한 시점에 다시 청구하는 방식이에요.
카드 정보를 직접 저장하는 기능이 아니라 다시 결제할 권한을 빌링키로 보관하고, 청구 판단은 가맹점 서버가 직접 하는 구조에 가까워요.
핵심 요약
- 자동결제의 공통 준비물은
billing_key예요. 먼저 빌링키 발급으로 고객 결제수단을 등록해요. - 청구 시점, 청구 금액, 재시도, 해지 상태는 가맹점 서버가 관리해야 해요.
- Bootpay API는 빌링키 발급·조회·삭제와 빌링키 결제 요청을 담당해요.
- 원하는 시점의 미래 1회 결제를 맡기고 싶다면 예약결제가 더 단순해요.
- 구독 계약·회차·조정·해지까지 상품 모델로 관리하려면 커머스 구독 가이드를 사용해요.
동작 방식
가맹점 서버는 청구 시점마다 billing_key가 저장된 회원 또는 구독 건을 조회하고, 이번 회차 금액을 확정한 뒤 Bootpay API로 결제를 요청해야 해요. 결제 결과를 받은 뒤에는 receipt_id, 주문 상태, 다음 청구 시각, 재시도 상태를 DB에 저장해요.
이런 상황이라면
| 상황 | 판단 |
|---|---|
| 월 구독료를 매월 같은 날 청구 | 가능. 회차·실패 재시도·해지 상태를 직접 관리해요 |
| 사용량을 집계해서 월말에 과금 | 적합. 청구 직전에 금액을 계산할 수 있어요 |
| 결제 실패 시 1일 뒤, 3일 뒤 재시도 | 적합. 재시도 큐와 고객 알림을 직접 설계해요 |
| 특정 날짜에 한 번만 미래 결제 | 예약결제가 더 단순해요 |
| 구독 신청·회차·조정·해지까지 맡기고 싶음 | 커머스 구독 가이드를 사용해요 |
자동결제 구성 요소
| 구성 요소 | 가맹점이 해야 할 일 | 관련 문서 |
|---|---|---|
| 빌링키 발급 | 고객 결제수단 등록 후 billing_key 저장 |
빌링키 발급 |
| 빌링키 조회 | 발급 결과와 유효 상태 확인 | 빌링키 조회 |
| 빌링키 결제 요청 | 청구 시점마다 결제 요청 | 빌링키 결제 요청 |
| 빌링키 삭제 | 탈퇴·해지·결제수단 제거 시 토큰 삭제 | 빌링키 삭제 |
| 회차 운영 | 다음 청구일, 재시도 횟수, 해지 상태 관리 | 데이터 저장 설계 |
예약결제와의 차이
| 항목 | 자동결제 | 예약결제 |
|---|---|---|
| 빌링키 | 필요 | 필요 |
| 실행 시각 결정 | 가맹점 서버가 청구 시점마다 직접 결정 | 가맹점 서버가 예약 등록 시 reserve_execute_at 지정 |
| 실행 방식 | 가맹점 서버가 해당 시점에 빌링키 결제 요청 API 호출 | 예약 등록 후 PG사가 예약 시각에 실행 |
| 서버 스케줄러 | 필요 | 보통 불필요 |
| 실패 재시도 | 가맹점이 직접 설계 | 예약 실행 결과를 웹훅으로 받고 후속 처리 |
| 대표 사례 | 월 구독, 후불 정산, 사용량 과금 | 체크인 결제, 예약 잔금, 미래 1회 청구 |
빌링키 삭제는 예약 취소가 아니에요