월 구독 서비스의 정기결제 기능은 일반 결제와 무엇이 다를까?
온라인 서비스에서 월간 또는 연간 요금제를 운영하려면 정기결제 기능이 필요할 수 있습니다.
온라인 서비스에서 월간 또는 연간 요금제를 운영하려면 정기결제 기능이 필요할 수 있습니다.
일반 결제는 사용자가 결제할 때마다 결제창을 열고 직접 인증합니다.
정기결제는 사용자가 처음 등록한 결제수단을 기반으로 다음 결제일에 서비스가 자동으로 결제를 요청합니다.
겉으로는 매달 자동 결제라는 단순한 기능처럼 보이지만 실제로는 다음 상태를 관리해야 합니다.
- 결제수단 등록
- 구독 시작
- 다음 결제일
- 자동 갱신
- 결제 실패
- 재시도
- 해지
- 요금제 변경
- 환불
- 이용 권한
- 관리자 처리
따라서 정기결제 개발은 일반적인 단건 결제보다 운영 정책과 예외 처리가 더 중요합니다.
일반 결제와 정기결제의 차이
| 구분 | 일반 결제 | 정기결제 |
|---|---|---|
| 결제 실행 | 사용자가 매번 진행 | 서비스가 자동 요청 |
| 결제수단 | 매번 입력·인증 가능 | 등록된 결제수단 사용 |
| 이용 기간 | 상품별로 결정 | 월·연 단위 갱신 |
| 실패 처리 | 해당 주문 실패 | 구독 상태에 영향 |
| 해지 | 주문 취소·환불 | 다음 갱신 중단 |
| 권한 | 구매 후 지급 | 결제 상태에 따라 유지 |
| 관리자 | 주문·환불 | 구독·갱신·실패 관리 |
| 알림 | 결제 결과 | 갱신·실패·해지 안내 |
정기결제의 기본 흐름
- 사용자가 요금제 선택
- 결제수단 등록
- 첫 결제
- 구독 활성화
- 다음 결제일 저장
- 결제일에 자동 결제 요청
- 성공 시 이용 기간 연장
- 실패 시 재시도 또는 이용 제한
- 사용자가 해지하면 다음 갱신 중단
프로젝트의 정책에 따라 흐름이 달라질 수 있습니다.
1. 요금제
먼저 어떤 요금제를 운영할지 정해야 합니다.
예시:
- 무료
- 베이직 월간
- 베이직 연간
- 프로 월간
- 프로 연간
- 기업 요금제
요금제별로 다음 정보가 필요할 수 있습니다.
- 가격
- 결제 주기
- 제공 기능
- 사용량 제한
- 사용자 수
- 저장 공간
- 무료 체험
- 환불정책
2. 결제수단 등록
정기결제를 위해 사용자의 결제수단을 등록하는 과정이 필요할 수 있습니다.
서비스는 일반적으로 카드번호 전체를 직접 보관하기보다 결제 서비스가 제공하는 식별값을 이용해 다음 결제를 요청합니다.
관리할 정보 예시:
- 사용자
- 결제수단 식별값
- 카드 정보 일부
- 등록 시각
- 사용 가능 상태
- 최근 결제 결과
민감한 결제정보 처리 방식은 결제 서비스의 정책과 보안 기준을 따라야 합니다.
3. 첫 결제
결제수단 등록과 동시에 첫 결제를 할지 정해야 합니다.
즉시 첫 결제
- 가입 시 바로 결제
- 즉시 유료 기능 활성화
- 다음 달 같은 날짜에 갱신
무료 체험 후 결제
- 결제수단 등록
- 일정 기간 무료 이용
- 체험 종료 후 첫 결제
무료 체험에는 다음 정책이 필요합니다.
- 체험 기간
- 결제 예정일
- 결제 전 알림
- 체험 중 해지
- 한 사용자의 반복 체험 제한
- 결제 실패
4. 구독 상태
정기결제 서비스에서는 구독 상태를 구분해야 합니다.
예시:
무료
체험 중
활성
결제 실패
해지 예정
해지
만료
정지
각 상태에서 사용할 수 있는 기능을 정해야 합니다.
예를 들어 해지 예정 상태는 다음 결제만 중단되고 현재 이용 기간까지는 유료 기능을 사용할 수 있습니다.
5. 다음 결제일
다음 결제일을 어떻게 계산할지 정해야 합니다.
- 가입일 기준
- 매월 고정일
- 연간 결제일
- 무료 체험 종료일
- 관리자 지정일
특정 날짜에 가입했을 때 다음 달에 같은 날짜가 없는 경우의 처리도 필요할 수 있습니다.
예를 들어 31일 가입자의 다음 결제일을 어떻게 정할지 정책이 필요합니다.
6. 자동 결제 실행
정해진 시간에 서버가 결제 대상 구독을 찾아 자동으로 결제를 요청합니다.
필요한 기능:
- 결제 대상 조회
- 중복 실행 방지
- 결제 요청
- 성공 처리
- 실패 처리
- 이용 기간 연장
- 로그
- 관리자 확인
자동화가 두 번 실행되어 중복 결제되지 않도록 해야 합니다.
7. 결제 성공
결제가 성공하면 다음 작업을 처리할 수 있습니다.
- 결제 내역 저장
- 구독 기간 연장
- 다음 결제일 계산
- 사용량 초기화
- 영수증 안내
- 이메일 발송
- 관리자 통계 반영
결제는 성공했지만 기간 연장이 실패한 경우를 추적할 수 있어야 합니다.
8. 결제 실패
정기결제에서 가장 중요한 예외 중 하나입니다.
실패 원인 예시:
- 카드 만료
- 한도 부족
- 분실·정지 카드
- 결제수단 해지
- 외부 서비스 오류
- 서버 오류
실패했을 때 결정해야 할 정책:
- 즉시 기능 중단
- 일정 기간 유예
- 자동 재시도
- 사용자에게 결제수단 변경 요청
- 관리자 수동 처리
- 반복 실패 후 구독 만료
9. 결제 재시도
실패 후 자동으로 다시 결제할 수 있습니다.
예시:
1차 실패: 즉시 안내
2차 시도: 3일 후
3차 시도: 7일 후
최종 실패: 구독 만료
재시도 횟수와 간격, 이용 권한 유지 여부를 정해야 합니다.
10. 유예 기간
결제 실패 즉시 서비스를 차단하면 사용자가 업무를 중단하게 될 수 있습니다.
B2B SaaS에서는 일정 기간 기능을 유지하면서 결제수단 변경을 안내할 수 있습니다.
정할 내용:
- 유예 기간
- 사용할 수 있는 기능
- 파일 다운로드
- 데이터 보관
- 관리자 알림
- 최종 만료
11. 구독 해지
사용자가 정기결제를 중단할 수 있어야 합니다.
즉시 해지
해지 시점에 유료 권한 종료
기간 종료 해지
현재 결제 기간까지 사용하고 다음 결제부터 중단
일반적으로 어떤 방식을 사용할지 정책으로 정해야 합니다.
해지 화면에 보여줄 정보:
- 이용 가능 종료일
- 다음 결제 취소
- 남은 기간
- 데이터 처리
- 재구독
- 환불 여부
12. 해지와 환불은 다릅니다
해지는 미래 결제를 중단하는 것입니다.
환불은 이미 결제된 금액을 돌려주는 것입니다.
사용자가 해지했다고 자동으로 현재 결제가 환불되는 것은 아닐 수 있습니다.
시스템과 환불정책이 일치해야 합니다.
13. 재구독
해지한 사용자가 다시 구독할 수 있습니다.
정해야 할 내용:
- 기존 결제수단 재사용
- 새 결제수단 등록
- 즉시 결제
- 기존 데이터 복원
- 남은 기간
- 할인 적용
- 무료 체험 재사용 여부
14. 요금제 업그레이드
예시:
베이직 → 프로
처리 방식:
- 즉시 변경
- 다음 결제일부터 변경
- 차액 결제
- 일할 계산
- 기존 한도 변경
초기 MVP에서는 복잡한 일할 계산 없이 다음 결제일부터 변경하도록 단순화할 수 있습니다.
15. 요금제 다운그레이드
예시:
프로 → 베이직
문제 상황:
- 현재 사용자가 하위 요금제의 저장 용량을 초과
- 등록된 직원 수가 제한을 초과
- 프로젝트 수가 많음
- 고급 기능 데이터를 사용 중
다운그레이드 적용 시점과 초과 데이터 처리 정책이 필요합니다.
16. 월간에서 연간으로 변경
- 즉시 연간 결제
- 다음 갱신일부터 변경
- 남은 월간 기간 처리
- 할인 적용
- 환불·차액
복잡한 요금제 변경은 개발과 운영 범위를 크게 늘릴 수 있습니다.
초기에는 해지 후 새 요금제 가입 방식으로 단순화할 수도 있습니다.
17. 사용량 제한
요금제별로 다음 제한이 있을 수 있습니다.
- AI 생성 횟수
- 파일 용량
- 프로젝트 수
- 직원 수
- 다운로드 수
- API 호출
- 저장 기간
결제 상태뿐 아니라 사용량을 정확하게 측정하고 차단해야 합니다.
18. 사용량 초기화
월 결제 성공 후 사용량을 초기화할 수 있습니다.
정해야 할 조건:
- 결제일 기준 초기화
- 매월 1일 초기화
- 연간 요금제의 월별 한도
- 미사용량 이월
- 추가 구매
19. 크레딧 방식
사용 횟수가 일정하지 않은 서비스는 크레딧을 사용할 수 있습니다.
- 구독 시 매월 크레딧 지급
- 추가 크레딧 구매
- 사용 내역
- 만료
- 환불
- 기업 직원 배분
구독과 크레딧을 함께 운영하면 상태 관리가 더 복잡해집니다.
20. 결제수단 변경
결제 실패나 카드 변경 시 사용자가 새로운 결제수단을 등록할 수 있어야 합니다.
흐름:
- 새 결제수단 등록
- 기존 결제수단 교체
- 필요 시 실패 결제 재시도
- 결과 안내
관리자에서 결제수단의 민감한 정보를 직접 확인하지 않도록 해야 합니다.
21. 사용자 구독 관리 화면
사용자가 확인할 수 있는 정보:
- 현재 요금제
- 결제 주기
- 다음 결제일
- 결제 금액
- 결제수단 일부
- 사용량
- 결제 내역
- 요금제 변경
- 결제수단 변경
- 해지
22. 관리자 구독 관리
운영자가 확인할 수 있는 정보:
- 사용자
- 기업
- 요금제
- 구독 상태
- 시작일
- 다음 결제일
- 최근 결제
- 실패 횟수
- 해지 여부
- 사용량
- 관리자 메모
가능한 관리 기능:
- 이용 기간 연장
- 구독 정지
- 수동 권한 지급
- 실패 결제 재시도
- 환불
- 요금제 변경
- 크레딧 지급
관리자 권한과 변경 이력을 남기는 것이 좋습니다.
23. 기업 구독
B2B SaaS에서는 기업 단위로 결제할 수 있습니다.
- 기업 관리자 결제
- 직원 수 기준 요금
- 기업별 계약 금액
- 세금계산서
- 수동 입금
- 크레딧 배분
- 사용량 통계
표준 카드 정기결제와 별도 계약 고객을 함께 운영할 수도 있습니다.
24. 구독 알림
사용자 알림 예시:
- 구독 시작
- 무료 체험 종료 예정
- 결제 예정
- 결제 완료
- 결제 실패
- 결제수단 변경 요청
- 해지 완료
- 이용 종료 예정
관리자 알림 예시:
- 반복 결제 실패
- 자동 처리 오류
- 기업 고객 해지
- 권한 지급 실패
- 비정상 중복 결제
25. 정기결제 로그
문제 추적을 위해 다음을 기록할 수 있습니다.
- 결제 실행 시각
- 대상 구독
- 결제 결과
- 실패 사유
- 재시도 횟수
- 구독 상태 변경
- 권한 변경
- 관리자 처리
정기결제 비용을 결정하는 요소
| 기능 | 범위 영향 |
|---|---|
| 월간 요금제 1개 | 비교적 단순 |
| 월간·연간 | 주기·변경 처리 |
| 무료 체험 | 결제 예정·중복 체험 |
| 결제 실패 | 재시도·유예 |
| 해지 | 종료 시점·권한 |
| 업·다운그레이드 | 차액·적용 시점 |
| 사용량 제한 | 측정·차단 |
| 크레딧 | 잔액·사용 이력 |
| 기업 구독 | 조직·직원·계약 |
| 관리자 | 수동 처리·이력 |
| 쿠폰 | 할인 조건 |
| 환불 | 정책·권한 회수 |
MVP에서 단순하게 시작하는 방법
1단계
- 월간 요금제 1개
- 즉시 첫 결제
- 매월 자동 갱신
- 기간 종료 해지
- 전체 환불만 지원
- 기본 관리자
이후 단계
- 연간 요금제
- 무료 체험
- 업그레이드
- 다운그레이드
- 쿠폰
- 크레딧
- 기업 요금제
- 복잡한 재시도
초기 고객에게 실제로 필요한 기능인지 확인한 뒤 확장할 수 있습니다.
정기결제 요구사항 양식
요금제:
월간·연간:
첫 결제 시점:
무료 체험:
다음 결제일 계산:
결제 실패 정책:
재시도:
유예 기간:
해지 적용 시점:
환불정책:
업그레이드:
다운그레이드:
사용량 제한:
크레딧:
기업 구독:
사용자 관리 화면:
관리자 기능:
알림:
검수 체크리스트
[ ] 결제수단 등록
[ ] 첫 결제
[ ] 구독 활성화
[ ] 다음 결제일
[ ] 자동 갱신
[ ] 중복 결제 방지
[ ] 결제 실패
[ ] 재시도
[ ] 유예 기간
[ ] 결제수단 변경
[ ] 해지
[ ] 기간 종료
[ ] 재구독
[ ] 요금제 변경
[ ] 사용량 초기화
[ ] 사용자 결제 내역
[ ] 관리자 구독 관리
[ ] 이메일·알림
[ ] 권한 지급·회수
[ ] 운영 결제 테스트
견적서에서 확인할 항목
- 결제수단 등록만 포함되는가?
- 자동 결제 실행 기능이 포함되는가?
- 결제 실패와 재시도가 포함되는가?
- 해지 기능이 포함되는가?
- 사용자 구독 관리 화면이 있는가?
- 관리자 구독 관리가 포함되는가?
- 요금제 변경이 포함되는가?
- 사용량 제한이 포함되는가?
- 환불과 권한 회수가 연결되는가?
- 정기 작업 실패를 확인할 수 있는가?
마무리
정기결제는 일반 결제를 매달 반복하는 기능만은 아닙니다.
서비스는 결제 상태와 구독 상태, 이용 권한을 함께 관리해야 합니다.
특히 다음 정책을 먼저 정해야 합니다.
- 언제 결제하는가?
- 실패하면 어떻게 하는가?
- 언제 기능을 제한하는가?
- 해지 후 언제까지 이용하는가?
- 요금제를 어떻게 변경하는가?
- 사용량을 어떻게 관리하는가?
정기결제 개발 견적을 받을 때는 월 구독 기능이라고만 설명하기보다 구독의 전체 생명주기와 운영 정책을 함께 전달하는 것이 좋습니다.
