PG 정기결제,
빌링키부터 해지까지 설계

정기 청구와 이용 해지는 별도 상태로 관리합니다. 구독 결제는 발급받은 결제 식별정보와 청구 주기, 이용 기간과 고객의 동의 기록이 연결되는 구조입니다. 결제 서비스를 통해 발급되는 빌링키 등을 사용하고 원래 카드 정보를 직접 보관하지 않는 흐름으로 설계합니다. 동의 기록과 구독 시작일, 청구 일정 · 금액, 변경 · 해지 이력을 준비합니다.

다음 달 이용을 중단하는 요청과 이번 달 결제를 돌려달라는 요청은 처리 결과가 다르므로 화면과 안내 문구를 나눕니다. 일반 일회성 결제 계약에 정기결제 기능이 포함되었다고 가정하지 말고 별도 지원 · 심사 조건을 확인합니다. 별도 계약 또는 권한을 확인한 뒤 청구 예약과 실패 처리, 다음 청구 중단 기능을 구현합니다. 해지 이후 청구 예약이 남지 않는지와 중복 요청이 한번만 반영되는지 확인합니다. 해지한 고객에게 다음 청구가 남지 않는지와 이미 청구된 금액의 환불 정책을 각각 확인합니다.

카드 정보를 직접 받는 흐름은 피합니다. 사업자가 고객의 카드번호나 비밀번호를 일반 문의로 받아 처리하는 방식 대신 계약된 결제 서비스가 제공하는 인증 · 결제 화면을 사용해야 합니다. 필요한 거래 내용과 결제 수단의 민감 정보를 구분해 운영합니다. 접속 도메인과 인증서, 키 저장 위치, 관리자 목록과 접근 권한을 확인합니다.

전화 상담 중 결제를 원하더라도 일반 상담 양식에 카드번호를 적도록 요청하는 대신 지원되는 안전한 결제 경로를 안내합니다. 특정 비인증 결제 방식은 별도 계약 · 관리 기준이 필요할 수 있어 일반 계약에 포함됐다고 가정하지 않습니다. 공식 결제창 또는 승인된 링크로 고객을 안내하고 민감 정보를 일반 폼에 남기지 않게 설명합니다. 공개 코드 · 기록 · 화면에 비밀 값이 없는지, 퇴사자 권한이 회수됐는지 점검합니다. 문의 기록 · 로그 · 화면 공유에 카드 정보나 비밀 값이 남지 않는지 확인합니다.

환불할 대금과 남은 주문을 구분합니다. 전체 환불과 부분 환불은 주문의 남은 의무와 제공 범위가 다릅니다. 고객 요청의 범위를 먼저 확정하고 금액 · 배송비 · 할인 · 이용 내역을 확인해야 실제 결제 취소와 고객 안내를 맞출 수 있습니다. 원주문 구성과 가격 · 할인, 구매 당시 안내와 실제 제공 상태를 준비합니다.

이용권 일부를 사용한 고객의 요청은 결제 전체 취소 버튼을 먼저 누르기보다 이용 내역과 적용 기준을 확인하는 순서가 필요합니다. 환불 금액의 법적 판단이 필요한 경우 일반 산식을 임의로 적용하지 않고 실제 조건 · 규정을 확인합니다. 적용 기준에 따라 환불 금액을 정하고 지원되는 취소 방식으로 처리합니다. 변경 후 잔액 · 제공 범위와 결제 기록, 고객 안내가 맞는지 대조합니다. 남은 주문과 결제 잔액, 재고 · 이용 권한 및 고객 안내가 같은 결과를 보이는지 확인합니다.

실패 재시도 전에 원거래 상태를 조회합니다. 통신 오류나 인증 중단은 결제 자체가 실패했다는 뜻과 같지 않을 수 있습니다. 승인 여부가 불확실한 상태에서 같은 청구를 곧바로 반복하면 고객 안내와 주문 기록이 꼬일 수 있어 확인 순서를 마련합니다. 기록할 작업과 담당자 권한, 거래 식별자 · 시각 · 결과 항목을 정합니다.

정기결제 실패가 카드 만료 때문이라면 무작정 반복 청구하기보다 고객이 결제 수단을 갱신할 수 있는 안내가 필요합니다. 실패 사유별 재시도 가능 여부와 정책은 서비스 문서 · 계약 및 고객에게 안내한 조건을 따릅니다. 거래 조회로 원결제 상태를 확인하고 처리되지 않은 경우에만 정해진 정책으로 재시도합니다. 고객 문의와 실제 처리 내역을 연결할 수 있는지 정기적으로 확인합니다. 성공 처리된 주문에 새 요청이 중복 반영되지 않는지 확인합니다.

구독 상품은 청구 주기와 이용 기간을 맞춥니다. 매달 또는 정해진 회차로 제공하는 상품은 언제 청구하고 언제부터 무엇을 제공하는지 연결되어야 합니다. 체험 · 할인 기간이 있다면 종료 뒤 청구 금액과 해지 방법까지 구매 전에 알 수 있도록 구성합니다. 변경 전후 문구와 적용일, 영향을 받는 상품 · 주문 범위를 정리합니다.

한 달 이용권과 매달 자동 갱신되는 구독은 다른 상품이므로 같은 버튼이나 모호한 안내로 묶지 않고 반복 청구 여부를 표시합니다. 제공 방식과 고객 동의 · 고지에 필요한 세부 기준은 상품과 적용 규정, 결제 계약 조건에 맞춰 확인합니다. 고객 동의를 기록하고 청구 일정과 권한 부여 · 중단을 주문 상태에 연결합니다. 이전 주문에 소급해 다른 조건이 표시되지 않는지와 기록 조회가 가능한지 확인합니다. 요금 변경과 결제 실패, 해지 요청 후 다음 청구가 어떻게 처리되는지 시험합니다.

고객 동의는 실제 청구 조건과 일치해야 합니다. 이용 조건을 설명하는 화면과 실제 결제 금액 · 주기 · 제공 내용이 다르면 문의가 생기기 쉽습니다. 특히 반복 청구나 추후 제공되는 서비스는 고객이 무엇에 동의했는지 확인 가능한 형태로 남기는 것이 좋습니다. 변경 전후 문구와 적용일, 영향을 받는 상품 · 주문 범위를 정리합니다.

체험 뒤 정기 청구로 바뀌는 구독은 첫 결제와 다음 청구 금액 · 시점을 구분해 안내하고 실제 일정도 같이 점검해야 합니다. 동의 문구를 숨기거나 선택 없이 동의한 것으로 처리하지 않고 상품과 법령에 필요한 기준을 확인합니다. 구매 전에 필요한 설명을 보여 주고 선택 · 동의 기록을 주문과 연결합니다. 이전 주문에 소급해 다른 조건이 표시되지 않는지와 기록 조회가 가능한지 확인합니다. 이후 변경 안내나 청구 결과가 동의한 범위와 맞는지 확인합니다.

청구마다 동의와 결과를 이어서 기록합니다. 정기결제 운영에는 고객이 동의한 주기 · 금액과 실제 청구 결과가 연결되어야 합니다. 변경 · 해지 · 실패와 재시도 내역을 같은 구독 식별자에 남겨 고객 문의와 다음 청구의 근거를 확인할 수 있게 합니다. 상품 · 가격 · 주기 · 제공 · 해지 조건과 동의가 필요한 항목을 정리합니다.

할인 종료 뒤 금액이 바뀌는 구독은 다음 청구액을 안내한 내용과 실제 예약 금액을 같이 점검해야 합니다. 동의나 계약 범위를 벗어난 임의의 청구를 실행하지 않고 변경에 필요한 고지 · 동의 기준을 확인합니다. 청구 전 안내와 청구 결과를 기록하고 실패 시 정책에 따라 고객에게 다음 행동을 알립니다. 이후 변경 안내나 청구 결과가 동의한 범위와 맞는지 확인합니다. 해지 이후 청구 예약이 남지 않는지와 중복 요청이 한번만 반영되는지 확인합니다.

반복 결제의 이전은 별도 계획이 필요합니다. 일회성 결제창을 바꾸는 작업과 구독 고객의 다음 청구를 옮기는 작업은 다릅니다. 기존 빌링키의 사용 범위와 이전 가능 여부, 고객 재등록 · 동의 필요성을 확인한 뒤 청구 누락과 중복을 방지해야 합니다. 기본 요금과 주기, 첫 청구일 · 이용 기간, 변경 · 해지 안내와 제공 범위를 적습니다.

새 PG로 일회성 주문을 먼저 옮겨도 구독 청구는 기존 계약에서 일정 기간 유지해야 하는 구성이 될 수 있습니다. 기존 빌링키를 새 서비스에 그대로 복사해 사용할 수 있다고 가정하지 않습니다. 이전 가능 여부를 공식 창구에 확인하고 고객 안내 · 재등록 또는 유지 계획을 나눕니다. 요금 변경과 결제 실패, 해지 요청 후 다음 청구가 어떻게 처리되는지 시험합니다. 전환 기간에 각 고객이 한 경로에서만 청구되고 해지 요청도 올바르게 반영되는지 시험합니다.

공통 기능과 별도 계약 기능을 나눕니다. 서비스 소개에 어떤 기능이 나열되어 있어도 모든 가맹점에 같은 조건으로 열려 있다는 의미는 아닙니다. 현재 신청에 포함된 범위와 추가 심사 · 비용 · 개발이 필요한 기능을 구분해 도입 일정을 잡아야 합니다. 현재 계약 기능과 추가하려는 수단 · 상품 · 채널, 변경 이유를 목록으로 적습니다.

해외 고객의 주문을 받으려면 국내 카드결제가 된다는 사실만으로 충분하다고 보지 않고 해외 카드 지원과 추가 조건을 확인합니다. 표준 기능이라는 표현만 보고 취소 · 정산 · 개발 지원 범위를 임의로 확대 해석하지 않습니다. 현재 계약에 포함되는지와 별도 신청이 필요한지 담당 안내와 문서로 확인합니다. 적용 이후 기존 주문 처리와 새 기능이 서로 영향을 주지 않는지 시험합니다. 화면에 노출한 기능이 실제 사용 가능한 권한과 설정을 갖췄는지 시험합니다.

기존 범위와 새 기능의 차이를 먼저 표시합니다. 결제 기능이나 상품을 바꾸려면 현재 사용 가능한 범위와 추가로 필요한 기능을 분리하는 것이 좋습니다. 기존 설정을 덮어쓰기 전에 별도 신청 · 심사 · 개발과 고객 안내에 어떤 변화가 있는지 확인합니다. 추가 수단의 계약 · 개발 범위, 기존 주문 흐름과 시험 시나리오를 정리합니다.

일회성 판매에 구독을 더한다면 새 청구 기능뿐 아니라 해지 · 알림 · 동의와 운영 권한을 함께 준비해야 합니다. 추가 기능이 메뉴에 보인다는 이유만으로 이미 계약에 포함되었다고 판단하지 않습니다. 기존 기능 유지와 새 기능 검토를 나누어 필요한 작업 · 자료를 확인합니다. 기존 수단의 선택과 결과 반영이 유지되고 명세에서 새 수단을 구분할 수 있는지 확인합니다. 적용 이후 기존 주문 처리와 새 기능이 서로 영향을 주지 않는지 시험합니다.