구독 과금 규칙·검증 시나리오 설계서

구독 결제는 같은 금액을 주기적으로 청구하는 작업에서 끝나지 않습니다. 요금제가 바뀌어도 이전 조건의 고객이 남을 수 있고, 청구가 실패해도 계약이나 이용 권한이 곧바로 종료되는 것은 아닙니다. 요금표, 개별 계약, 청구서, 결제 시도, 이용 권한을 구분해 변경 조건의 적용 대상을 확인합니다. 현재 적용 버전과 다음에 적용할 버전을 계약에 기록합니다.

작성 예시는 가상 B2B 월 구독 정책 v1입니다. Basic의 월 요금은 120,000원, Pro는 180,000원으로 두며 산식에서는 세액을 제외합니다. 청구 기간은 Asia/Seoul 기준 매월 1일 00:00부터 다음 달 1일 00:00 직전까지입니다. 종료 시각은 다음 기간에 속합니다. 상향 변경은 예약일 자정부터 적용하되 추가 결제의 승인을 그 전에 확인합니다. 하향 변경은 다음 청구 기간부터 적용하고 해당 월의 차액은 조정하지 않는 정책으로 가정합니다.

이 금액과 조건은 예제의 사업 규칙입니다. 실제 서비스의 세금·증빙·환불·약정 조건은 해당 담당자가 확정합니다. 구현 단계에서는 계약한 결제수단의 기능과 처리 규격을 확인합니다. 토스페이먼츠의 자동결제 연동 문서는 빌링 이용에 필요한 계약과 청구 스케줄 구현을 설명합니다. 카드 등록이나 빌링키 발급이 서비스의 요금제와 해지 정책까지 자동으로 정한다는 뜻은 아닙니다.

요금제 변경에는 요청 시각, 금액을 계산한 시각, 적용 예정 시각, 결제 승인 확인 시각이 있습니다. 같은 날짜 문자열로 이 네 가지를 덮어쓰면 결제가 끝나지 않았는데 이용 권한이 먼저 바뀔 수 있습니다. 변경 요청 ID와 산정 버전을 두고 금액·기간·적용 조건을 함께 확정합니다. 이미 미납인 기간에서 추가 할인이나 조정을 계산할지도 별도 규칙으로 정합니다.

가상 정책의 작성 예시에서 2026년 9월은 30일입니다. Basic에서 Pro로 9월 16일 00:00에 바꾸면 남은 기간은 10월 1일 00:00까지 15일입니다. 추가 청구액은 월 차액 60,000원에 15/30을 곱한 30,000원입니다. 변경 요청 UP-0916에 이 입력과 금액을 기록하고 예정 시각 전에 추가 결제 승인을 확인했을 때 Pro로 전환합니다. 확인이 안 됐다면 전환을 보류하고 기존 조건을 유지합니다.

가상 정책은 실제 달의 일수로 나누며 원 단위 미만은 최종 계산에서 한 번 버립니다. 날짜나 요금이 빠지면 산정 보류, 적용 날짜가 기간 밖이면 입력 오류로 처리합니다. 승인 확인이 늦어 예약 시각을 넘기면 적용일과 금액을 다시 확정합니다. 뒤늦게 승인된 금액이 있으면 먼저 확인해 중복 청구를 막습니다. Stripe의 일할 계산 문서는 미납 청구와 조정 처리를 따로 설명합니다. 이 예제의 산식을 제품 기본값이나 모든 PG의 규칙으로 옮기지 않습니다.

정상 갱신과 실패 처리는 대상이 다른 상태를 함께 움직입니다. 계약은 유지되고 청구서는 미납인 동안 결제 시도는 실패할 수 있으며, 서비스는 유예 정책에 따라 계속 이용할 수 있습니다. 이를 하나의 ‘구독 상태’로만 저장하면 어떤 돈을 받아야 하고 무엇을 다시 시도해야 하는지 알기 어렵습니다. 각 대상에 현재 상태와 변경을 허용할 사건을 적습니다.

작성 예시에서는 계약 S-01의 10월 청구서 INV-1001이 발행됩니다. 10월 1일 첫 결제 시도가 실패하면 청구는 미납, 계약은 유지, 이용은 유예로 기록합니다. 10월 2일 재시도의 승인이 확인되면 같은 청구서를 납부 처리하고 정상 이용으로 바꿉니다. 같은 성공 사건이 두 번 도착해도 청구와 이용권은 한 번만 반영되어야 합니다. 9월 청구의 늦은 성공 통보는 10월 미납을 해결한 근거가 되지 않습니다.

계약 ID, 기간 ID, 청구서 ID, 결제 시도 ID와 외부 거래 ID를 구분합니다. 성공 사건을 반영하기 전에 대상 청구와 금액·통화를 대조합니다. 수신한 기록과 내부 업무 처리 결과도 나누어 관리합니다. 토스페이먼츠의 웹훅 연결 문서에서 이벤트 종류와 전달 방식을 확인하고 실제 연동 규격에 맞춰 처리합니다. 인증·중복·상태 충돌의 일반 준비는 결제 연동 착수 점검표와 연결합니다.

승인 응답이 없다는 사실과 결제가 실패했다는 사실은 다릅니다. 이미 승인됐는데 응답만 잃었을 수 있으므로 새로운 결제 시도를 만들기 전에 원거래를 조회합니다. 결제수단이 만료됐으면 반복 청구보다 수단 변경 안내가 먼저일 수 있습니다. 실제로 확인된 일시 실패는 계약과 결제수단이 허용한 범위에서 재시도합니다. 사유 코드를 서비스의 조치 규칙에 연결하되 코드 의미를 임의로 해석하지 않습니다.

가상 월 구독의 갱신 정책은 10월 1일의 확인된 일시 실패에 대해 10월 2일과 4일 09:00에 재시도 기회를 둡니다. 매번 같은 청구가 아직 미납인지 확인합니다. 10월 5일 00:00까지 납부되지 않았다면 운영 담당의 확인 후 이용을 제한하되 계약은 유지합니다. 이 일정과 유예 기간은 가상 정책의 선택입니다. 실제 결제사에 공통으로 적용되는 재시도 횟수나 고객 권리를 뜻하지 않습니다.

승인 미확인이나 서로 충돌하는 상태는 이 재시도 일정에 바로 넣지 않습니다. 확인 대기와 운영 이관으로 보내 중복 청구와 잘못된 이용 제한을 보류합니다. 고객 안내에도 미납 확정, 처리 확인 중, 수단 변경 필요를 구분합니다. 발송 채널과 개인정보·동의 조건은 서비스가 실제로 사용하는 방식에 맞춥니다. 결제 운영의 조회·진단·승인·실행 권한을 나눠 누가 마지막 상태를 확인할지 정합니다.

기간 말 해지를 예약하면 다음 기간 청구 중단과 현재 이용 종료 시점을 기록합니다. 반면 중도 해지는 언제 이용을 끝내고 어떤 금액을 조정할지 추가 결정이 필요할 수 있습니다. 해지 요청, 내부 검토, 금액 승인, 결제사 처리, 대사 완료는 서로 다른 상태입니다. 요청 접수만으로 환불 완료를 표시하지 않으며 결과가 불명확한 취소를 반복 실행하지 않습니다.

별도 승인된 중도 정산의 작성 예시에서는 Pro 이용을 9월 21일 00:00에 끝내기로 합의합니다. 가상 계약의 담당자가 미사용 10일에 대해 180,000×10/30인 60,000원 조정을 승인합니다. 앞서 납부한 기본 월 요금 120,000원과 변경 청구 30,000원의 합계는 150,000원입니다. 조정이 완료되면 잔여 납부액은 90,000원이며 다음 기간 청구는 생성하지 않습니다. 기록 ADJ-0921에 적용 시점과 승인 근거를 연결합니다.

60,000원은 이 가상 계약의 승인된 예시 금액이며 법정 환불액이 아닙니다. 실제 환불은 원거래별 가능 잔액과 결제수단의 규격을 확인해 배분해야 합니다. 청구 조정과 실제 지급·취소 결과가 같은지도 확인합니다. 원거래, 조정, 취소 사건과 정산 반영을 정산 대사 규칙·운영 런북에 연결하면 재무와 운영 담당이 같은 거래를 추적할 수 있습니다.

검증표에는 상품 담당자가 승인한 규칙 ID, 시험 입력, 기대 금액·상태, 실행 결과와 증거를 적습니다. UP-0916의 추가 결제 승인 확인은 30,000원 추가 청구와 예약일 전환, 승인 미확인은 전환 보류가 기대 결과입니다. 갱신 성공 사건의 중복 수신은 한 청구에 한 번 반영되어야 합니다. 이전 기간의 성공 사건으로 현재 미납이 사라져서는 안 됩니다. 기간 말 해지에서는 다음 청구가 생성되지 않는지 확인합니다.

날짜 경계, 월별 일수, 금액 누락, 0원 차액, 잘못된 적용 기간을 포함해 산식과 상태를 각각 검증합니다. 로컬 산식 확인은 실제 결제 승인이나 환불 완료의 증거가 아닙니다. 결제수단을 연결한 테스트 환경에서는 조회와 재수신, 승인 충돌과 취소 결과를 검증합니다. 실제 운영 개시 전에는 계약 수단과 키 설정, 스케줄, 고객 안내와 조회·환불 권한을 별도로 확인합니다. 미실행 항목에는 완료 표시 대신 담당과 확인 일정을 남깁니다.

IXC의 정기 결제·빌링은 요금제·계약·청구·재시도·해지를 잇는 구축을 제공합니다. PG 연동·결제 시스템 구축과 함께 현재 규칙의 데이터 모델과 연동 범위를 정합니다. 계약 조건과 변경 예제, 미납·해지 처리의 미정 항목을 바탕으로 개발·검증·운영 인수 중 IXC가 맡을 일을 정합니다. 공유용 설계서에는 비밀 키나 실고객 결제정보를 넣지 않습니다.