자동결제는 언제 쓰나요?

핵심 요약

• 일반 결제는 결제할 때마다 고객이 카드사 앱 등을 통해 인증하고, 자동결제는 결제수단을 한 번 등록한 뒤 간편하게 결제해요.
• 가맹점은 카드번호를 직접 저장할 수 없기 때문에 PG사에서 빌링키​​를 발급받아요. 이후 가맹점은 이 빌링키​​를 저장해 두었다가 원하는 시점​​에 원하는 금액​​으로 승인 요청할 수 있어요.
• 결제 시점과 금액을 반복적으로 설정​​하는 구조가 자동결제예요. 기술적으로 다음 회차 결제일과 금액은 가맹점이 변경할 수 있어요​. 다만 구독 계약 건에서 금액을 변경할 때는 고객 동의·약관·고지 정책까지 함께 설계해야 해요.

이런 상황이라면

월 9,900원짜리 SaaS를 준비하는 PM이 있어요. 처음에는 “결제 연동만 붙이면 매달 자동으로 돈을 받을 수 있겠지”라고 생각했어요. 그런데 개발자와 이야기하다 보니 결제수단 등록​, 빌링키​, 조건에 따른 결제 금액 변동​, 회차 청구​, 재시도 정책 같은 단어가 나와요. 일반 결제를 매달 반복하는 것과는 다른 구조처럼 느껴져요.

이 글은 그 차이를 정리해요. 자동결제는 “일반 결제를 매달 한 번씩 다시 실행하는 기능”이 아니에요. 고객이 결제수단을 한 번 등록하면, 가맹점이 빌링키를 저장해 두고 정해진 조건에 따라 결제 시점과 금액을 반복적으로 승인 요청하는 구조예요.

그래서 자동결제를 붙인다는 말은 결제창 하나를 추가한다는 뜻이 아니에요. 결제수단 등록, 빌링키 저장, 구독 회차, 금액 변경, 회차 청구, 실패 재시도, 해지 정책​​을 함께 설계한다는 뜻에 가까워요.

1일반 결제와 자동결제는 인증 방식부터 달라요

일반 결제는 고객이 결제할 때마다 직접 인증해요. 고객이 결제 버튼을 누르고, 카드사 앱이나 카드사 인증창을 거쳐 결제를 승인해요. 다음에 다시 구매하면 이 과정이 다시 반복돼요.

자동결제는 처음에만 고객이 결제수단을 등록해요. 이후에는 고객이 매번 카드사 앱을 열거나 결제창에서 다시 인증하지 않아도, 가맹점 서버가 빌링키로 결제를 요청해요.

고객 입장에서는 “한 번 등록해 두면 알아서 결제되는 것”처럼 보여요. 하지만 가맹점 입장에서는 일반 결제보다 더 많은 운영 로직이 필요해요. 고객이 결제 버튼을 누르지 않는 시점에도 결제가 일어나야 하기 때문이에요.

이 차이를 가능하게 만드는 것이 빌링키​​예요.

2빌링키는 카드번호 대신 저장하는 결제용 키예요

자동결제에서 가장 먼저 이해해야 할 개념이 빌링키예요.

가맹점은 고객의 카드번호를 직접 저장할 수 없어요. 카드번호, 유효기간, 생년월일, 비밀번호 등 결제수단 인증에 필요한 민감 정보는 PG사가 처리해요. 대신 PG사는 해당 결제수단으로 다시 결제를 요청할 수 있는 키를 가맹점에 내려줘요. 이 키가 빌링키​​예요.

흐름은 이렇게 보면 돼요.

즉 가맹점이 저장하는 것은 카드번호가 아니라 빌링키​​예요. 이후 결제할 때도 카드번호를 다시 받는 게 아니라, 저장해 둔 빌링키로 PG사에 승인 요청을 보내요.

이 구조 때문에 자동결제에서는 백엔드 역할이 중요해요. 결제수단 등록 화면은 처음 한 번이지만, 그 이후의 청구 시점 계산, 금액 결정, 승인 요청, 실패 재시도, 구독 상태 변경은 서버에서 계속 처리해야 해요.

3자동결제의 핵심은 “언제, 얼마를 받을지”예요

자동결제를 “매달 9,900원 받는 기능”으로만 이해하면 부족해요. 실제 핵심은 더 넓어요.

저장된 빌링키를 기준으로, 원하는 시점에 원하는 금액을 반복적으로 승인 요청하는 것.

그래서 자동결제 설계에서 가장 먼저 나오는 질문은 두 가져요.

• 언제 결제할 것인가?
• 얼마를 결제할 것인가?

예시는 이렇게 나뉘어요.

여기서 중요한 점은 회차 결제일과 금액이 기술적으로 고정값이 아니라는 거예요. 가맹점은 정책에 따라 다음 회차 결제일을 바꿀 수 있고, 청구 금액도 조건에 따라 다르게 요청할 수 있어요.

예를 들어 이런 경우가 가능해요.

• 무료체험 종료 후 첫 결제일에 9,900원 청구
• 다음 달부터 프로 플랜으로 변경되어 19,900원 청구
• 사용량 초과분이 붙어 이번 달만 43,200원 청구
• 전기차 충전이 끝난 뒤 실제 충전량 기준으로 18,700원 청구
• 택시가 처음 정한 목적지·예상 요금에서 벗어나거나 장시간 지연되어 추가 요금만 후불 청구
• 정기배송 상품 구성이 바뀌어 다음 회차 금액 변경
• 연간 결제로 전환하면서 다음 회차부터 연 99,000원 청구

다만 “기술적으로 변경 가능해요”와 “서비스가 마음대로 바꿔도 돼요”는 달라요. 특히 이미 체결된 구독 계약 건에서 금액을 변경할 때는 고객 동의, 약관, 사전 고지 정책을 함께 설계해야 해요.

4결제 금액 변동 조건을 먼저 정해야 해요

자동결제에서 금액은 생각보다 자주 바뀌어요. 처음에는 정액제처럼 보여도 운영을 시작하면 여러 조건이 붙어요.

• 무료체험이 끝나면 유료 금액으로 전환
• 월간 플랜에서 연간 플랜으로 변경
• 베이직 플랜에서 프로 플랜으로 업그레이드
• 사용량 초과분 추가 과금
• 전기차 충전량·충전 시간에 따른 금액 산정
• 택시 경로 이탈·장시간 지연에 따른 추가 후불 금액 산정
• 쿠폰·프로모션 종료 후 정상가 청구
• 정기배송 상품 수량 변경
• 일시정지 후 재개 시 다음 결제일 조정

이런 조건을 정하지 않고 결제 연동부터 시작하면 개발 중간에 질문이 계속 나와요.

“업그레이드하면 오늘 바로 차액을 받을까요, 다음 결제일부터 받을까요?”

“쿠폰이 끝나면 자동으로 정상가를 청구해도 되나요?”

“사용량 초과분은 매일 계산하나요, 월말에 합산하나요?”

“결제 실패 후 재시도할 때도 같은 금액으로 요청하나요?”

자동결제는 단순히 “반복 결제”가 아니라 조건에 따라 청구 금액이 달라지는 운영 구조​​예요. 그래서 결제 연동 전에 금액이 바뀌는 조건을 먼저 적어두는 편이 좋아요.

5일반 결제를 매달 반복하면 안 되나요?

가능은 하예요. 매달 결제 링크를 보내거나, 고객이 매달 직접 결제 버튼을 누르게 만들 수도 있어요. 하지만 그건 자동결제라기보다 “반복 구매 유도”에 가까워요.

문제는 세 가져요.

첫째, 고객 이탈이 커져요. 매달 고객이 직접 결제해야 하면 한 번 귀찮아지는 순간 결제가 끊겨요. 구독의 핵심인 “마찰 없는 연속성”이 사라져요.

둘째, 청구 시점이 고객 행동에 묶여요. 직접 결제는 실패하면 고객이 결제창에서 다른 결제수단으로 다시 결제할 수 있어요. 문제는 매달 그 고객을 다시 결제 화면까지 데려와야 한다는 점이에요. 회차 청구 구조는 정해진 시점에 가맹점 서버가 먼저 승인 요청을 보낼 수 있지만, 직접 결제 방식은 고객이 들어와 결제 버튼을 누르기 전까지 청구가 시작되지 않아요.

셋째, 운영 기준이 흐려져요. 고객은 “구독”이라고 보면 자동결제를 기대해요. 그런데 매달 결제 링크를 보내면 SaaS 구독이라기보다 인보이스 청구에 가까워져요.

그래서 결제 시점과 금액이 반복적으로 발생하는 서비스라면, 일반 결제를 매달 반복하는 방식보다 빌링키 기반 자동결제 구조를 먼저 검토하는 편이 나아요.

6구독형 서비스는 라이프사이클까지 봐야 해요

자동결제는 결제 성공 한 건으로 끝나지 않아요. 특히 SaaS나 멤버십 같은 구독형 서비스에서는 고객 한 명의 구독이 신청 → 활성 → 회차 결제 → 실패·재시도 → 해지​​로 흘러요.

• 신청 → 활성​: 고객이 결제수단을 등록하고 빌링키가 발급돼요.
• 활성 → 회차 청구​: 정해진 회차 결제일에 빌링키로 승인 요청해요.
• 회차 청구 → 재시도​: 카드 만료·한도 부족 등으로 결제가 실패해요.
• 재시도 → 활성 또는 해지​: 재시도 성공 시 활성으로 돌아가고, 실패가 누적되면 해지 처리해요.
• 활성 → 일시정지·해지​: 고객 요청이나 운영 정책에 따라 상태가 바뀌어요.

기획 단계에서는 “결제가 성공했나?”보다 “구독 상태가 지금 어디에 있나?”를 먼저 정리해야 해요. 상태가 정리되어야 회차 청구, 실패 재시도, 해지 처리가 흔들리지 않아요.

실제로 붙이려면

빌링키 인프라는 payments, 구독 라이프사이클은 commerce 쪽에 있어요.

• 빌링키 발급 — /billing/key-issue
• 구독 플랜 계약 — /subscription/plan/contract