B2B SaaS billing pause와 service access 정책 분리 매트릭스 2026, Stripe·Paddle·Chargebee를 비교하는 기준

B2B SaaS에서 구독을 pause한다고 해서 결제와 서비스 접근이 항상 함께 멈추는 것은 아닙니다. 결제 수집만 일시 중지하고 구독 상태와 기능 접근은 유지하는 방식도 있고, 다음 청구를 미루면서 서비스도 제한하는 방식도 있습니다. 공급사 API의 paused라는 단어만 보고 내부 정책을 결정하면 청구·접근·재개 일정이 서로 어긋납니다.

이 글의 결론은 간단합니다. pause를 도입할 때는 다음 다섯 가지를 한 행에 기록하되 하나의 상태로 합치지 마십시오.

collection_state, pause_reason, resume_at은 이 다섯 축을 설명하는 보조 필드입니다. 이 이름들은 Stripe·Paddle·Chargebee가 공통으로 보장하는 표준 schema가 아니라 내부 운영 원장에 둘 수 있는 예시 필드입니다. 공급사 객체의 필드명을 그대로 내부 계약으로 취급하지 마십시오.

pause·cancel·suspend를 먼저 구분하기

pause는 재개 가능성을 전제로 한 일시 중지일 수 있지만, 공급사와 계정 설정에 따라 청구만 멈추거나 서비스까지 제한할 수 있습니다. cancel은 구독 종료 또는 다음 갱신 중단을 뜻할 수 있고, suspend는 미납·정책 위반·운영 판단에 따른 접근 차단을 뜻하는 경우가 많습니다. 이름이 비슷해도 효력 시점과 복구 경로가 다릅니다.

따라서 내부 정책표에 아래 항목을 먼저 고정합니다.

• 현재 청구 기간의 서비스 접근을 유지하는가
• 결제 수집만 중지하는가, 구독 자체 상태를 바꾸는가
• 미청구 사용량·추가 좌석·초과 사용료를 pause 중 어떻게 처리하는가
• 다음 invoice 또는 renewal 시점을 연기하는가
• resume이 즉시 효력을 가지는가, 미래 시각에 예약되는가
• pause 해제 시 과거에 누적된 금액을 청구하거나 dunning을 재개하는가

해지 후 권한 회수 시점은 B2B SaaS 구독 해지 후 entitlement 회수 시점 검증 체크리스트의 별도 범위입니다. 이 글은 cancel의 종료 시점을 다시 설명하지 않고, pause 중 결제와 접근 정책을 분리하는 데 집중합니다.

churn 집계는 B2B SaaS 구독 취소·churn reason 추적 감사 체크리스트로 연결하며, 이 글에서는 pause를 churn으로 분류하지 않습니다.

가장 먼저 만드는 정책 매트릭스

공급사별 API 호출보다 먼저 제품 정책을 정합니다. 예를 들어 “결제 수집 중지 + 서비스 전체 유지”와 “구독 pause + 읽기 전용 접근”은 고객에게 전혀 다른 상품 경험입니다.

billing_state=active인데 접근이 denied일 수도 있고, collection_paused인데 접근이 full_access일 수도 있습니다. 이 조합이 허용되는지 금지되는지를 제품·고객지원·재무 운영자가 함께 정해야 합니다.

Stripe: 결제 수집 pause와 구독 상태 변경을 나눠 보기

Stripe의 Pause payment collection은 결제 수집을 중지하는 기능의 동작과 처리 방식을 확인하는 출발점입니다. 결제 수집을 멈추는 것과 구독 객체의 상태를 바꾸는 것은 같은 이벤트가 아닐 수 있습니다. 객체 변경 필드와 요청 결과는 Update a subscription에서 다시 확인해야 합니다. 두 URL 모두 실제 적용 전 현재 공식 문서·API 버전·계정 설정으로 재검증할 링크입니다.

운영자가 기록할 최소 항목은 다음과 같습니다.

• 수집 중지 방식과 적용 시각
• invoice를 생성·보류·취소하는 방식
• pause 중 발생한 사용량이나 추가 좌석의 처리 기준
• resume 요청 시 다음 invoice와 collection 상태가 어떻게 바뀌는지
• Stripe 응답의 원문 상태와 내부 billing_state mapping

Stripe의 Entitlements는 결제 상태와 기능 접근을 연결하는 참고 자료지만, Stripe의 entitlement event나 객체 필드를 내부 제품의 access_policy_state와 동일시하면 안 됩니다. 실제 접근 허용은 애플리케이션 policy와 cache·projection이 결정할 수 있습니다.

Paddle: pause·resume의 효력 시각과 접근 provisioning 분리

Paddle의 Pause a subscription과 Pause subscription API에서는 pause 방식과 예약 효력 시점을 확인합니다. resume이 별도 요청인지, 예약된 변경의 해제인지, effective_from 또는 resume_at이 어떤 의미인지 원문 문서 기준으로 기록합니다. API 호출 시각을 곧 서비스 접근 복구 시각으로 저장하지 마십시오. 두 링크는 적용 전 현재 공식 문서에서 경로·버전·응답을 재검증해야 합니다.

Paddle의 Resume subscription API는 청구 상태의 재개를 확인하는 근거입니다. 실제 고객 기능 접근의 provisioning은 Provision access and handle subscription state 흐름과 내부 application policy를 함께 확인해야 합니다. 이 두 URL도 검증 전 참고 링크로 두고 실제 적용 전에 재확인하십시오.

Paddle 운영표에는 특히 다음을 분리해 둡니다.

• scheduled_change_effective_at: 예약 변경이 효력을 갖는 시각
• resume_requested_at: resume API를 호출한 시각
• access_observed_at: 실제 핵심 API나 화면에서 허용 상태를 관찰한 시각
• next_invoice_at: 다음 청구 예정 시각

이 네 값이 서로 다르다고 해서 곧 오류는 아닙니다. 중요한 것은 그 차이가 제품의 허용 지연 범위와 고객에게 고지한 정책에 맞는지입니다.

Chargebee: pause와 재활성화의 운영 조건 확인

Chargebee의 Pause Subscription은 pause 기간의 갱신·청구와 계정 설정을 확인하는 자료입니다. Reactivation과 Resume a subscription API는 pause 이후 재개 경로를 검토할 때 함께 봅니다. 세 링크 모두 실제 적용 전 현재 공식 문서·API 버전·사이트 설정으로 재검증할 링크입니다.

Chargebee에서도 “구독을 재개할 수 있다”는 사실과 “애플리케이션의 모든 기능을 즉시 열었다”는 사실은 구분해야 합니다. Subscription Entitlements는 plan·feature 연결을 확인하는 근거로 사용하되, 내부 access 정책과 관찰 시각은 별도 기록으로 남깁니다. 이 entitlements URL도 검증 전 공식 참고 링크입니다.

공급사 문서의 경로·상태명·계정별 옵션은 바뀔 수 있습니다. 실제 적용 전 현재 공식 문서와 사용 중인 사이트 설정을 다시 확인하십시오.

내부 원장에 남길 최소 schema

다음은 공급사 공통 schema가 아니라 내부 대사표의 예시입니다.

account_id
subscription_id
pause_request_id
billing_state
collection_state
access_policy_state
scheduled_change_effective_at
resume_at
next_invoice_at
access_observed_at
source_event_id
policy_version
observed_timezone
reconciliation_code

source_event_id는 상태 변경의 근거를 연결하고, policy_version은 당시 접근 정책을 재현하기 위한 값입니다. observed_timezone을 남기면 UTC와 로컬 시간 혼동을 줄일 수 있습니다. 공급사 event 수신 시각과 변경 효력 시각을 하나의 timestamp로 덮어쓰지 마십시오.

불일치 판정 코드

access_observed_at은 권한 action을 발행한 시각이 아니라 실제 web·API·export 등 확인 대상 경로에서 정책을 관찰한 시각으로 정의하는 편이 안전합니다. probe가 실패했다면 정상으로 간주하지 말고 unknown 또는 access_observation_missing으로 남깁니다.

운영 전 체크리스트

• [ ] payment collection pause와 subscription pause를 제품 문서에서 분리했다.
• [ ] pause 중 full access·read-only·denied 중 어떤 정책인지 고객에게 설명할 수 있다.
• [ ] billing_state와 access_policy_state를 별도 필드로 저장한다.
• [ ] 예약 효력 시각, resume 요청 시각, 실제 접근 관찰 시각을 분리한다.
• [ ] next invoice·미청구 사용량·dunning 처리 규칙을 확인했다.
• [ ] 공급사 원문 상태와 내부 정규화 상태를 나란히 보존한다.
• [ ] 중복 pause·resume 요청을 막을 멱등 키와 state version이 있다.
• [ ] web·API·export처럼 서로 다른 접근 경로를 따로 probe한다.
• [ ] 정책 변경 전후의 공식 문서 URL과 확인 날짜를 기록한다.

resume 이후 entitlement 복구 시점 자체를 검증해야 한다면 구독 재활성화·resume 후 entitlement 복구 시점 검증 체크리스트를 별도 참고하십시오. 일반 entitlement·feature flag 변경 감사는 entitlement·feature flag 변경 추적 감사 체크리스트의 범위입니다. webhook replay나 invoice·event 대사는 결제 webhook replay 검증 로그·대사 리포트 템플릿으로 분리합니다.

마무리

pause를 안전하게 운영하는 핵심은 “공급사 상태가 paused인가”를 묻는 데서 끝나지 않습니다. 결제 수집이 멈췄는지, 서비스 접근은 어떤 정책인지, 변경 효력 시각과 실제 접근 관찰 시각이 언제인지, 다음 invoice가 어떻게 처리되는지를 같은 구독 키로 대사해야 합니다.

Stripe·Paddle·Chargebee의 문서와 API는 각각 다른 상태·효력·청구 개념을 제공합니다. 따라서 공급사 이름을 내부 공통 상태로 곧바로 합치기보다 원문 상태, 내부 mapping, access 관찰 결과를 분리해 보존하십시오. 이 글은 도구 도입·운영 검토를 위한 체크리스트이며, 계약·회계·세무 판단이나 특정 공급사의 정책 적용을 대신하지 않습니다.