구독 라이프사이클
trial, renewal, past due, cancellation, customer portal 운영 기준
핵심 요약
- 구독 운영의 기준은 결제 성공 여부가 아니라 구독 상태와 서비스 권한의 일관성이며, Paddle status를 내부 billing/entitlement state로 매핑한다.
- 신규 권한은
subscription.created만 보지 말고 관련 transaction 상태와 함께 확인한다. - 결제 실패(past_due)는 회수 기회다. D0~D8+ 단계로 알림·기능 유지·점진적 제한을 적용하고, Enterprise·연간 고객은 운영자 검수 큐를 거친다.
- 무료체험 유료전환·가격 인상·좌석 증액은 Paddle 이벤트만으로 처리하지 말고 고지·동의 또는 고지 이력을 저장한다.
- 해지(미래 갱신 차단)와 환불(과거 결제 취소)을 코드·CS에서 분리하고, 해지 경로를 숨기면 다크패턴 리스크가 생긴다.
SaaS 구독 운영의 기준은 결제 성공 여부가 아니라 구독 상태와 서비스 권한의 일관성입니다. Paddle은
subscription과 transaction을 별도 엔티티로 다루므로 권한을 부여할 때 두 흐름을 함께 읽어야 합니다.
핵심 상태
| 상태 | 의미 | 서비스 권한 |
|---|---|---|
| trialing | 무료 체험 중 | 체험 권한 부여 |
| active | 정상 결제/갱신 가능 | 유료 권한 유지 |
| past_due | 결제 실패 또는 수금 문제 | grace 정책에 따라 제한 |
| paused | 일시정지 | 신규 사용 제한 또는 읽기 전용 |
| canceled | 해지 완료 | 만료 시점 이후 권한 제거 |
Paddle 상태명과 내부 상태명을 1:1로 그대로 쓰기보다, 내부 제품 권한 상태를 별도로 둡니다.
Paddle status -> Billing state -> Entitlement state
active -> paid -> full_access
past_due -> recovery -> grace_access / limited_access
canceled -> ended -> no_paid_access신규 구독
Checkout이 완료되면 transaction이 paid/completed 흐름을 거쳐 subscription이 생성됩니다. 신규 고객 권한은
subscription.created만 보고 열지 말고 관련 transaction 상태를 함께 확인합니다.
| 이벤트 | 처리 |
|---|---|
transaction.created | checkout 시작 또는 결제 시도 기록 |
transaction.updated | paid/completed 등 상태 변경 반영 |
subscription.created | subscription ID 저장, 고객/워크스페이스 연결 |
subscription.updated | status, item, next billing date 동기화 |
갱신 실패와 grace
결제 실패는 고객 이탈이 아니라 회수 기회입니다. 제품 권한을 즉시 끊으면 회수율이 떨어지고 CS가 늘어납니다.
| 기간 | 권장 처리 |
|---|---|
| D0 | 결제 실패 알림, 결제수단 업데이트 CTA |
| D1~D3 | 앱 상단 배너, 이메일 1차, 기능 유지 |
| D4~D7 | 일부 기능 제한, 관리자 알림 |
| D8+ | 유료 기능 잠금, 데이터 보존 정책 안내 |
실제 grace 기간은 Paddle 설정, 상품 정책, 고객 유형에 맞춰 조정합니다. Enterprise나 연간 고객은 자동으로 잠그기보다 운영자 검수 큐를 거치는 편이 안전합니다.
업그레이드와 다운그레이드
| 변경 | 권한 처리 | 재무 처리 |
|---|---|---|
| 월간 Pro → Team | 즉시 권한 확대 | proration 확인 |
| Team → Pro | 다음 갱신일부터 축소 권장 | 남은 기간 credit 여부 확인 |
| 월간 → 연간 | 성공 transaction 이후 연간 권한 | 할인/환불 정책 확인 |
| 좌석 수 변경 | 수량 기반 entitlement 재계산 | 다음 청구액 preview 확인 |
무료 체험·가격 변경 동의
웹서비스 운영을 위한 약관 가이드와 맞춰, 무료 체험 후 유료 전환이나 정기결제 금액 증액은 결제 이벤트만으로 처리하지 않습니다. 고객에게 전환 일시, 변경 전후 가격, 결제 방법, 해지/취소 방법을 먼저 고지하고 동의 또는 고지 이력을 저장해야 합니다.
| 상황 | Paddle 처리 | 내부 증빙 |
|---|---|---|
| 무료 체험 후 유료 전환 | trial/subscription 설정 | 전환 일시, 금액, 동의 버전, reminder 발송 로그 |
| 가격 인상 | price 변경 또는 subscription update | 변경 전후 가격, 적용일, 고객 동의/고지 이력 |
| 좌석 증액 | quantity update와 proration | 관리자 동의자, 시각, 변경 수량, 예상 청구액 |
| 해지 | Customer Portal 또는 내부 경로 | 해지 경로, 처리 시점, 만료일까지 권한 유지 여부 |
해지 경로가 가입·결제보다 과도하게 복잡하면 다크패턴 리스크가 생깁니다. Paddle Customer Portal을 쓰더라도 제품 내부에서 해지/결제관리 진입점을 명확히 제공하고 이동 사실과 처리 결과를 로그로 남깁니다.
해지와 환불의 분리
해지는 미래 갱신을 막는 것이고 환불은 과거 결제를 취소하는 것입니다. 고객센터와 코드에서 두 개념을 분리해야 합니다.
| 요청 | Paddle 처리 | 내부 처리 |
|---|---|---|
| 다음 달부터 해지 | subscription cancellation | 만료일까지 권한 유지 |
| 즉시 해지 | cancellation + 권한 조정 | 데이터/환불 정책 안내 |
| 환불 | adjustment/refund | 권한 회수, credit 제거 |
| chargeback | dispute | 계정 위험 플래그, 증빙 제출 |
Customer Portal 운영
Paddle-hosted customer portal을 쓰면 결제수단 변경, 인보이스 다운로드, 구독 관리 UX를 빠르게 제공할 수
있습니다. 다만 제품 안에서 결제 관리 버튼을 누르면 Paddle로 이동한다는 안내를 함께 보여줘야 합니다.
운영 지표
| 지표 | 의미 |
|---|---|
| renewal success rate | 갱신 결제 성공률 |
| past due recovery rate | 결제 실패 회수율 |
| voluntary churn | 자발 해지 |
| involuntary churn | 결제 실패 이탈 |
| refund rate | 환불 비율 |
| chargeback rate | 분쟁 비율 |