상품명에 ‘구독’을 넣었는데, 결제는 한 번만 나갈 때
카페24에서 정기구독몰을 만들려다 막히는 지점은 대개 ‘구독 상품을 등록했는가’가 아닙니다. 기본 주문서·결제는 장바구니에 담고 한 번 결제하고 끝나는 1회 구매 흐름입니다. 상세 제목에 구독이라고 적어도, 다음 결제일·회차·해지 상태가 주문 한 건에 자동으로 붙지는 않습니다.
가능 여부부터 말하면, 같은 상품을 같은 주기로 반복 청구하는 정도는 스토어의 정기결제·정기배송 앱과 PG 정기결제(빌링)로 되는 경우가 있습니다. 반대로 이번 달만 건너뛰기, 회차마다 구성·금액이 바뀌기, 결제 실패 후 N회 재시도 뒤 혜택을 끊기, 구독 중일 때만 배송비 면제 같은 회원 상태가 필요하면 기본 기능만으로는 부족합니다. 그때는 구독 상태를 별도 서버에서 관리하고 카페24 주문·회원과 맞추는 커스텀을 검토합니다.
한눈에 보는 핵심 답변
경로만 먼저 보면 아래와 같습니다. 구현 세부와 제한은 이어서 정리합니다.
- 카페24 기본 주문서는 1회 결제입니다. 구독 상태(회차·다음 결제일·해지) 마스터는 없습니다.
- 상품명·스킨에 ‘구독’만 넣는 것은 카피입니다. 청구가 따라가지 않으면 구독몰이 아닙니다.
- 같은 SKU·같은 주기만이면 정기결제·정기배송 앱 또는 PG 빌링부터 봅니다.
- 건너뛰기·회차 구성 변경·실패 재시도·구독 중 혜택은 앱 설정 밖에 남는 경우가 많습니다.
- 그때는 별도 서버에 구독 상태를 두고 카페24 API로 주문·회원과 맞춥니다.
- 토큰은 스킨에 두지 않습니다. PG 정기결제는 계약·심사가 쇼핑몰 화면과 별개입니다.
기본·앱·PG·커스텀으로 나누는 구현 경로
첫 경로는 카페24 기본 기능입니다. 상품 등록, 일반 주문서, 1회 결제, 배송·취소는 여기로 충분합니다. 운영자가 매달 수동으로 주문을 넣어 주는 방식도 기본 범위입니다. 사람 손이 주 1회 이하이고 실수가 드물면, 구독몰 개발보다 이 수작업이 비용이 적을 수 있습니다.
둘째는 앱스토어의 정기결제·정기배송류 앱입니다. 앱이 정한 주기·상품 고정·해지 화면이 우리 운영 문서와 같으면 초기 비용·일정에서 유리한 경우가 많습니다. 다만 구독 숫자·다음 결제일이 앱 DB에만 있으면, 카페24 관리자 주문과 어느 쪽이 원본인지가 이후 CS에서 갈립니다. 앱을 끄면 과거 회차 이력이 빠질 수 있는지도 설치 전에 확인하는 편이 안전합니다.
셋째는 PG 쪽 정기결제입니다. 카드 빌링키로 같은 금액을 반복 청구하는 계약이 되면, ‘돈이 주기적으로 나간다’는 문제는 앱·PG가 맡습니다. 그래도 건너뛰기·회차 구성 변경·실패 후 며칠 더 혜택을 둘지는 PG 화면만으로 우리 규칙이 되지 않는 경우가 많습니다. PG 정기결제 가능 여부는 계약·심사가 따로라, 쇼핑몰 스킨만 고친다고 생기지 않습니다.
커스텀이 필요해지는 구성
우리 몰만의 구독 규칙을 코드로 옮길 때는 보통 카페24 API + 별도 서버 + 구독 DB가 한 세트입니다. 서버가 회원별 구독 상태(활성·해지·건너뛰기·다음 결제일·회차)를 보관하고, 주기가 되면 카페24에 주문을 만들거나 결제 결과를 받아 상태를 갱신합니다. 토큰·시크릿은 스킨이 아니라 서버에 두고, 웹훅·실패 재시도·운영 로그도 서버가 맡습니다. 고객용 마이페이지와 운영자용 회차·이상 건 화면은 이 상태를 보여 주는 층입니다.
스킨만으로 ‘구독처럼’ 보이게 할 때
상세·마이페이지에 구독 문구와 다음 회차 안내만 넣는 것은 디자인(스킨) 작업에 가깝습니다. 화면에 날짜가 보여도 실제 결제가 나가지 않거나, 반대로 문구는 ‘이번 달 쉼’인데 청구는 그대로면 CS가 납니다. 실결제·주문 생성과 문구를 같은 규칙으로 묶지 않으면, 스킨 수정은 구독몰이 아니라 카피 작업입니다.
핵심 체크리스트
상담·검수 전에 아래로 표시해 보세요. ‘예’가 두 개 이상이면 기본 주문서만으로 구독몰을 보기 어렵고, 앱으로도 빈 구간이 클 가능성이 큽니다.
- 고객이 마이페이지에서 다음 결제일과 해지를 봐야 하는가
- 이번 주기만 쉬거나(건너뛰기), 회차마다 상품·금액이 다른가
- 결제 실패 후 재시도 횟수·혜택 유지 기간을 우리 약관대로 둘 것인가
- 앱을 켜 두고도 매달 수동 주문을 넣거나 엑셀로 회차를 맞추는가
- 구독 중 혜택(배송비·할인)이 주문 한 건이 아니라 회원 상태에 묶이는가
- PG 정기결제(빌링) 계약·심사가 되어 있는가. 스킨만으로 생기지 않는가
- 앱·카페24 관리자 중 어느 쪽 숫자가 원본인지 정했는가
- 앱을 끄면 과거 회차 이력을 가져올 수 있는가
- 테스트 주문에서 상세 문구·실제 청구·관리자 주문이 같은가
- 렌탈(만기 반납)과 소모품 구독을 한 요청에 섞지 않았는가
기본으로 버티기 어려운 제한과 검수
기본 주문서에 없는 대표적인 규칙은 건너뛰기(이번 주기만 청구하지 않음), 회차마다 다른 구성·가격, 결제 실패 후 재시도 횟수와 혜택 종료 시점, 해지 후 ‘이미 낸 기간까지 혜택이 남는지’입니다. 회차별 구성·금액은 별도 설계 주제이고, 해지·연기 UX도 화면만의 문제가 아닙니다. 이 글에서는 그 규칙들이 기본 주문 한 건에 들어 있지 않다는 한계만 짚습니다.
앱으로 갈 때도 제한이 있습니다. 앱 설정과 우리 약관이 한 줄만 달라도, 운영자는 엑셀로 예외를 메우게 됩니다. 쿠폰·적립·부분취소가 회차 주문에 어떻게 붙는지는 앱·PG마다 달라, ‘구독 주문도 일반 주문과 같다’고 가정하면 정산이 어긋납니다. 카페24 API를 쓸 때는 호출 제한·필요 스코프·테스트몰/실몰 분리를 전제로 두고, 프론트에 인증 정보를 두지 않아야 합니다.
실무에서 이런 문제가 발생할 수 있습니다
헬스케어·건기식처럼 재구매 리듬이 필요한 몰에서, 쿠팡 와우형으로 ‘가입하면 혜택이 이어진다’를 원했던 경우가 있습니다. 기본 주문서와 범용 앱만으로는 주기·회원 상태·다음 결제일·해지를 한곳에 모으기 어려웠고, 구독 상태를 별도 서버에 두고 카페24 주문·회원과 맞추는 쪽으로 갔습니다. 과제·구성은 정기구독 시스템 개발사례에 따로 있습니다.
다른 유형은, 출고 표에는 이번 달을 빼 두었는데 카드 청구는 그대로 나가는 운영입니다. 앱은 같은 SKU를 반복 청구하고, 운영은 회차마다 구성을 바꾸거나 건너뛰기를 엑셀로 처리합니다. 문구만 ‘쉼’이고 빌링은 멈추지 않으면 CS가 결제 문자로 시작합니다. 이런 요구라면 건너뛰기·회차 변경을 서버 상태에 넣지 않는 한, 앱만으로 표와 청구가 같아지지 않습니다.
커스텀이 과한 경우, 현실적 대안
SKU 하나, 주기 하나, 건너뛰기·구성 변경이 없고 앱 문서와 운영이 같으면 앱·PG부터 쓰는 편이 맞습니다. 예외가 월 몇 건이면 1차는 앱 + 엑셀 검수로 두고, 상태가 매일 쌓일 때 서버 구독을 2차로 올려도 됩니다. 렌탈(만기 반납)과 소모품 구독을 한 요청에 섞지 않는 것도 범위를 지키는 방법입니다.
상품명에 구독만 넣으면 정기구독인가요
아닙니다. 상세 문구는 스킨이고, 정기구독은 다음 청구와 상태가 있어야 합니다. 관리자 주문이 한 건으로 끝나면 1회 구매와 같습니다.
정기결제 앱과 정기구독은 같은가요
같지 않은 경우가 많습니다. 정기결제는 같은 금액을 반복 청구하는 쪽에 가깝고, 정기구독은 회차·건너뛰기·해지·회원 혜택까지 포함한 운영 상태에 가깝습니다. 앱 규칙과 우리 약관이 한 줄만 달라도 엑셀이 남습니다.
매달 같은 상품만 보내면 커스텀이 필요한가요
건너뛰기·구성 변경·실패 후 예외가 없고 앱 문서와 같으면 보통 필요하지 않습니다. 앱을 켠 뒤에도 매달 주문을 손으로 넣으면, 그때는 앱이 우리 규칙을 못 따라가는 신호입니다.
건너뛰기는 스킨에 버튼만 만들면 되나요
버튼만으로는 부족합니다. 그 주기 청구가 실제로 나가지 않아야 건너뛰기입니다. 화면에만 ‘쉼’이고 빌링이 돌면 결제 문자 CS가 납니다.
카드 결제가 실패하면 기본 기능에서 어떻게 되나요
1회 주문이면 그 결제 실패로 끝인 경우가 많습니다. 구독이면 몇 번 다시 받을지, 그동안 혜택을 둘지를 약관으로 정해야 합니다. 정해 두지 않으면 고객은 구독 중으로 알고 몰은 멈춘 상태가 되기 쉽습니다.
쿠팡 와우처럼 만들어 달라고 하면 범위가 어떻게 갈리나요
그 한 줄에는 회비, 기간 혜택, 해지 후 종료 시점이 같이 들어 있습니다. 1차에 남길 혜택 한 문장(예: 구독 중이면 배송비 없음)부터 고정하지 않으면 견적 가정이 업체마다 달라집니다.
1차는 앱, 2차는 서버로 나눠도 되나요
됩니다. 예외가 월 몇 건이면 앱과 엑셀로 두고, 상태·CS가 매일 쌓일 때 구독 서버를 올리는 편이 일정에 안전한 경우가 많습니다. 다만 앱 DB만 원본이면 2차에서 회차 이관 비용이 생길 수 있어, 어디에 숫자를 남길지는 1차에서 정해 두는 편이 낫습니다.
옴니어스가 구독몰 요청을 나누는 방식
옴니어스는 ‘구독몰 만들어 주세요’를 바로 전면 개발로 받지 않습니다. 1회 주문으로 충분한지, 앱·PG 정기결제로 주기만 맞으면 되는지, 구독 상태를 서버에 둬야 하는지를 운영 문장으로 먼저 가릅니다. 앱으로 되면 커스텀을 키우지 않고, 빈 규칙만 API·별도 서버·관리 화면으로 설계하는 혼합도 제안합니다.
자료가 없어도 지금 쓰는 앱 이름과 ‘앱으로 안 되는 한 줄’, 원하는 주기·실패 시 처리만 알려 주셔도 범위가 보입니다. 와우형 멤버십처럼 큰 벤치마크는 참고하되, 1차에 넣을 혜택 한 가지부터 문장으로 고정합니다. 거품 없는 범위로 일한 만큼 제안드립니다.
구독 한계 다음에 보면 좋은 글·페이지
실제로 구독 상태를 서버에 두고 붙인 흐름은 정기구독 시스템 개발사례에서 볼 수 있습니다. 앱으로 될 때와 커스텀이 필요할 때는 앱 vs 커스텀 글에, API와 별도 서버가 따라오는 이유는 API 안내 글에, 기본만으로 충분한 몰인지는 커스텀 vs 기본 가이드에 정리해 두었습니다.
서비스·진행 방식·FAQ에서 범위와 순서를 더 확인할 수 있고, 문의 페이지에 주기·예외 규칙만 남겨 주셔도 됩니다. 기본·앱·커스텀 중 어디부터인지 기준으로 안내해 드립니다.