정기구독 커머스 CRM: 결제·자격·배송 상태 설계 [2026]
정기구독 CRM에서 계약·청구·결제·서비스 자격·배송 회차를 분리하는 법입니다. 웹훅 중복, 결제 실패, 건너뛰기·해지, 고객 안내와 4자 대사 기준을 정리했습니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
정기구독 커머스 CRM은 고객을 활성·해지로 분류하는 캠페인 도구가 아니라 계약·상품 버전·청구·결제·서비스 자격·배송·고객 동의의 사건을 유효 시점으로 연결하는 운영 시스템입니다. 결제 상태 하나로 배송과 이용 권한까지 추정하면 지연 결제·부분 변경·건너뛰기·해지 예약에서 서로 다른 시스템이 다른 답을 냅니다.
구독은 고객, 구독 계약, 구독 항목, 가격, 청구서, 결제 시도, 서비스 이용 기간, 배송 회차가 각각 다른 생애주기를 가집니다. 결제가 실패해도 재시도 중일 수 있고, 해지를 예약해도 현재 기간의 자격은 남을 수 있으므로 한 필드로 전체 상태를 덮으면 안 됩니다.
CRM의 역할은 결제 시스템을 복제하는 것이 아닙니다. 각 원천의 사건을 공통 고객·구독 ID로 연결하고 다음 행동, 안내 가능 여부, 담당자, 예외와 회복 상태를 보여 주며 마케팅 메시지가 운영 사실보다 앞서가지 않게 하는 것입니다.
고객보다 구독·청구·자격·배송 객체를 먼저 분리한다#
같은 고객이 여러 구독과 회차를 가질 수 있으므로 객체별 식별자와 원천을 보존합니다.
| 객체 | 기준 ID | 책임 상태 | 완료 증거 |
|---|---|---|---|
| 구독 계약 | subscription_id | 시작·변경·일시정지·종료 | 계약 사건 이력 |
| 청구·결제 | invoice/payment_attempt_id | 금액·기한·시도·결과 | PG 거래·대사 |
| 서비스 자격 | entitlement_id | 기능·기간·부여·회수 | 접근 판정 로그 |
| 배송 회차 | fulfillment_cycle_id | 상품·주소·예약·출고·반품 | 물류 사건 이력 |
상태를 고객·운영의 다음 행동과 연결한다#
라벨 수를 늘리는 대신 진입 조건·허용 행동·종료 조건을 상태마다 고정합니다.
| 상태 사건 | 허용할 행동 | 자동화 | 금지할 추정 |
|---|---|---|---|
| 결제 처리 중 | 확인·대기 | 중복 청구 억제 | 실패·성공 확정 |
| 결제 실패 | 수단 수정·재시도 | 배송 보류·안내 | 즉시 해지 |
| 건너뛰기·일시정지 | 재개일 변경 | 회차·재고 재계산 | 고객 이탈 |
| 해지 예약 | 철회·현재 기간 이용 | 종료일 안내·자격 회수 예약 | 즉시 접근 차단 |
실무 시나리오: 결제 실패인데 배송과 이용 권한이 열려 있다#
결제 웹훅이 늦게 도착하고 물류 마감이 먼저 실행돼 상품이 출고 대기 상태가 된 경우를 가정합니다.
| 단계 | 확인 질문 | 조치 | 종료 증거 |
|---|---|---|---|
| 격리 | 어떤 구독·회차·자격이 영향받았나 | 배송·혜택 보류·중복 안내 억제 | 영향 목록 |
| 판정 | 실패·처리 중·인증 필요 중 무엇인가 | PG 사건·서명·시각 대조 | 원천 상태 |
| 복구 | 재결제와 배송 재개 순서는 | 멱등 재시도·자격·재고 재계산 | 사건 연결 |
| 대사 | 청구·결제·자격·배송이 일치하나 | 차이 큐 해소·고객 안내 | 구독 4자 대사 |
구독·청구·결제·자격 상태는 사용 중인 제품에서 각각 확인한다#
Stripe 공식 문서는 Subscription, Invoice, PaymentIntent, Entitlement가 연결되지만 각 상태와 행동이 다르며 구독 활동 대부분이 비동기로 발생해 웹훅 처리가 필요하다고 설명합니다. 이 문서는 객체와 사건을 분리하는 제품 사례이며 국내 PG·구독 계약·전자상거래·개인정보 기준을 대신하지 않습니다. 실제 상태와 재시도·환불·해지 조건은 현재 결제 제품과 계약에서 확인해야 합니다.
- Stripe How subscriptions work: 구독·청구서·결제·자격의 서로 다른 상태와 전이
- Stripe subscription webhooks: 비동기 구독·청구·결제 실패·환불 사건 처리
- Stripe Revenue Recovery: 결제 실패 회복 기능의 제품별 설정 범위
웹훅 inbox·멱등 키·유효 시점·대사 큐를 운영한다#
외부 사건은 서명 검증 뒤 원문 해시·외부 사건 ID·발생 시각·수신 시각·처리 버전과 함께 inbox에 보존합니다. 중복·순서 역전·지연을 가정하고 구독·청구·배송 갱신에는 멱등 키를 사용하세요.
가격·혜택·배송 주기와 메시지 규칙은 시행일이 있는 버전으로 관리합니다. 현재 구독을 바꿀 때 과거 회차를 새 규칙으로 다시 쓰지 말고 effective_at과 recorded_at을 분리해 어느 시점의 고객 상태도 재현합니다.
매일 결제 제품의 구독·청구서·결제 결과와 내부 자격·배송 회차를 대사합니다. 알 수 없는 고객, 결제 성공 뒤 보류, 결제 실패 뒤 출고, 중복 재시도는 이유·담당자·기한·재처리 상태가 있는 예외 큐로 보냅니다.
반복 주문 운영은 이커머스 운영 자동화에서 확장합니다. 결제사 입금 대사는 PG 간편결제 정산과 함께 보세요. 고객·동의·반품 CRM은 D2C CRM 자동화를 참고하세요.
정상 회차보다 경계 시각과 실패 회복을 통과한 뒤 승인한다#
첫 결제, 갱신, 인증 필요, 지연 확정, 재시도 성공·실패, 부분 환불, 상품 변경, 건너뛰기, 일시정지, 해지 예약·철회, 주소 변경과 물류 마감 경계를 표본으로 둡니다.
운영자가 구독 ID 하나로 계약·청구·결제·자격·배송·고객 안내를 재현하고, 누락·중복 사건을 영향 조회해 재처리하며, 고객이 실제 자격과 다른 메시지를 받지 않을 때 CRM 운영을 승인합니다.
핵심 요약
- ✓고객 라벨이 아니라 구독·청구·결제·자격·배송 회차를 별도 객체로 연결한다
- ✓상태마다 진입 조건·허용 행동·자동화·종료 조건을 고정한다
- ✓웹훅의 중복·지연·순서 역전을 inbox·멱등 키·재처리 큐로 복구한다
- ✓가격·혜택·배송·메시지 규칙을 시행일이 있는 버전으로 관리한다
- ✓결제·자격·배송·고객 안내 대사를 완료 기준으로 삼는다
자주 묻는 질문