Skip to main content
구독을 사용하면 자동 갱신을 통해 지속적인 액세스를 판매할 수 있습니다. 유연한 청구 주기, 무료 체험, 플랜 변경 및 추가 기능을 사용해 고객별로 가격을 맞춤 설정하세요.

Upgrade & Downgrade

일할 계산 및 수량 업데이트로 플랜 변경을 관리하세요.

On‑Demand Subscriptions

지금 mandate를 승인하고 나중에 사용자 지정 금액을 청구하세요.

Customer Portal

고객이 플랜, 청구 및 취소를 직접 관리할 수 있도록 하세요.

Subscription Webhooks

생성, 갱신 및 취소와 같은 lifecycle 이벤트에 대응하세요.

구독이란 무엇인가요?

구독은 고객이 일정에 따라 구매하는 반복 상품입니다. 다음과 같은 경우에 적합합니다.
  • SaaS 라이선스: 앱, API 또는 플랫폼 액세스
  • 멤버십: 커뮤니티, 프로그램 또는 클럽
  • 디지털 콘텐츠: 강좌, 미디어 또는 프리미엄 콘텐츠
  • 지원 플랜: SLA, 성공 지원 패키지 또는 유지 관리

주요 이점

  • 예측 가능한 수익: 자동 갱신을 지원하는 반복 결제
  • 유연한 주기: 월간, 연간, 사용자 지정 간격 및 체험 기간
  • 유연한 플랜 관리: 업그레이드 및 다운그레이드에 대한 일할 계산
  • 추가 기능 및 좌석: 선택적이고 수량화 가능한 업그레이드 연결
  • 원활한 checkout: 호스팅 checkout 및 customer portal
  • 개발자 중심: 생성, 변경 및 사용량 추적을 위한 명확한 API

구독 생성

Dodo Payments 대시보드에서 구독 상품을 생성한 다음 checkout 또는 API를 통해 판매하세요. 상품과 활성 구독을 분리하면 가격을 버전별로 관리하고, 추가 기능을 연결하며, 성과를 독립적으로 추적할 수 있습니다.

구독 상품 생성

대시보드의 필드를 구성하여 구독 상품의 판매, 갱신 및 청구 방식을 정의하세요. 아래 섹션은 생성 양식에서 확인하는 항목과 직접 연결됩니다.

상품 세부 정보

  • 상품 이름 (필수): checkout, customer portal 및 인보이스에 표시되는 이름입니다.
  • 상품 설명 (필수): checkout 및 인보이스에 표시되는 명확한 가치 설명입니다.
  • 상품 이미지 (필수): 최대 3MB의 PNG/JPG/WebP입니다. checkout 및 인보이스에 사용됩니다.
  • 브랜드: 테마와 이메일에 사용할 특정 브랜드에 상품을 연결합니다.
  • 세금 카테고리 (필수): 세금 규칙을 결정할 카테고리(예: SaaS)를 선택합니다.
지역별로 정확한 세금을 징수할 수 있도록 가장 적합한 세금 카테고리를 선택하세요.

가격

  • 가격 유형: Subscription을 선택합니다(이 가이드). 대안으로 Single Payment 및 Usage Based Billing이 있습니다.
  • 가격(필수): 통화가 포함된 기본 recurring 가격입니다. 가격은 $1(또는 선택한 통화로 이에 상응하는 금액) 이상이어야 합니다. 이 최소 금액 미만은 지원되지 않으며 subscription이 작동하지 않습니다.
  • 할인 적용 가능(%): 기본 가격에 적용되는 선택적 백분율 할인입니다. checkout 및 인보이스에 반영됩니다.
  • 반복 결제 주기(필수): 갱신 간격입니다(예: 1개월마다). 주기(개월 또는 년)와 수량을 선택합니다.
  • Subscription 기간(필수): subscription이 활성 상태로 유지되는 전체 기간입니다(예: 10년). 이 기간이 끝나면 연장하지 않는 한 갱신이 중지됩니다.
  • Trial 기간(일)(필수): trial 기간을 일 단위로 설정합니다. trial을 사용하지 않으려면 0을 입력합니다. trial이 종료되면 첫 번째 청구가 자동으로 발생합니다.
  • Trial 금액: 유료 trial에 대한 선택적 선불 청구 금액입니다. 무료 trial의 경우 설정하지 않습니다. Paid Trials를 참조하세요.
  • add-on 선택: 고객이 기본 플랜과 함께 구매할 수 있는 add-on을 최대 10개까지 연결합니다.
활성 상품의 가격을 변경하면 신규 구매에 영향을 줍니다. 기존 구독에는 플랜 변경 및 일할 계산 설정이 적용됩니다.
추가 기능은 좌석 또는 스토리지와 같은 수량화 가능한 추가 항목에 적합합니다. 고객이 추가 기능을 변경할 때 허용되는 수량과 일할 계산 동작을 제어할 수 있습니다.

고급 설정

  • 세금 포함 가격: 적용 가능한 세금이 포함된 가격을 표시합니다. 최종 세금 계산은 고객의 위치에 따라 달라집니다.
  • 라이선스 키 생성: 구매 후 각 고객에게 고유 키를 발급합니다. License Keys 가이드를 참조하세요.
  • 디지털 상품 제공: 구매 후 파일 또는 콘텐츠를 자동으로 제공합니다. Digital Product Delivery에서 자세히 알아보세요.
  • 메타데이터: 내부 태그 또는 클라이언트 통합을 위해 사용자 지정 키-값 쌍을 연결합니다. Metadata를 참조하세요.
시스템의 식별자(예: accountId)를 메타데이터에 저장하면 나중에 이벤트와 인보이스를 대조할 수 있습니다.

구독 체험

Trial을 사용하면 고객이 전체 recurring 가격을 결제하기 전에 subscription을 평가할 수 있습니다. trial은 trial 종료 시까지 아무것도 청구하지 않는 무료 방식이거나, 선불로 할인된 금액을 청구하는 유료 방식일 수 있습니다. 두 경우 모두 trial 종료 후 첫 번째 갱신부터 전체 가격이 적용됩니다.

체험 구성

상품 가격 섹션에서 Trial Period Days를 설정합니다(체험을 사용하지 않으려면 0를 사용). 구독을 생성할 때 이 값을 재정의할 수 있습니다.
trial_period_days 값은 0일에서 10,000일 사이여야 합니다.
Trial은 무료일 필요가 없습니다. subscription product의 recurring 가격에 Trial 금액을 설정하면 trial 기간에 대해 할인된 선불 요금을 청구할 수 있습니다. 이후 첫 번째 갱신부터 전체 recurring 가격이 적용됩니다.
trial 기간과 유료 trial을 위한 선택적 trial 금액이 표시된 Subscription 가격 양식
Paid trial은 subscription 또는 checkout session별이 아니라 product의 가격에서 설정합니다:
Paid trial도 checkout을 통해 처리됩니다. trial 금액에는 세금이 부과되고, checkout session 계산 및 payment link 가격에 표시되며, Adaptive Currency markup이 통화별로 적용됩니다. preview endpointtrial_amounttrial_period_days를 반환하므로 subscription이 생성되기 전에 오늘 결제할 금액을 표시할 수 있습니다.
무료 trial은 변경되지 않습니다. Trial 금액을 설정하지 않으면 첫 번째 청구가 0이고 trial 종료 시 전체 가격이 청구되는 기존 동작이 유지됩니다.

Trial 오용 방지

Trial 오용 방지는 고객이 동일한 business에 대해 trial을 반복적으로 신청하지 못하도록 합니다. 이 기능을 사용하면 이미 trial을 사용한 고객은 새로운 trial을 받는 대신 자동으로 유료, trial 없음 구매로 전환됩니다.
Subscriptions 설정 탭의 Trial 오용 방지 토글
SettingsSubscriptions 탭에서 활성화합니다. 활성화하면 다음과 같이 동작합니다:
  • 고객은 정규화된 email을 기준으로 매칭되며 plus-alias가 제거됩니다. 따라서 user+trial@example.comuser@example.com는 동일한 사용자로 처리됩니다.
  • 사용 기록은 trial 활성화 시점에 저장되므로, 같은 날 취소한 고객도 trial을 사용한 것으로 처리됩니다.
  • 기존 고객은 email을 기준으로 과거 trial 기록이 backfill되므로 이전 trial 사용자도 즉시 인식됩니다.
이 설정은 기본적으로 꺼져 있습니다. business 수준의 subscription 제어 항목 전체 목록은 Subscription Settings를 참조하세요.

Trial 상태 감지

현재 trial 상태를 감지할 수 있는 직접적인 field는 없습니다. 다음은 payments를 조회해야 하는 우회 방법이며 비효율적입니다. 더 효율적인 해결 방법을 개발하고 있습니다.
무료 trial subscription이 trial 중인지 확인하려면 해당 subscription의 payments 목록을 가져옵니다. 금액이 0인 payment가 정확히 하나 있으면 subscription은 trial 기간 중입니다:
이 0원 확인 방식은 무료 trial에만 적용됩니다. paid trial의 경우 첫 번째 payment는 0가 아니라 trial 금액과 같습니다. 대신 첫 번째 payment를 subscription의 trial_amount와 비교하거나 next_billing_date가 아직 trial 기간 내에 있는지 확인하세요.

Trial 기간 업데이트

next_billing_date를 업데이트하여 trial을 연장합니다:
next_billing_date를 과거 시점으로 설정할 수 없습니다. 날짜는 미래여야 합니다.

Subscription 플랜 변경

플랜 변경을 통해 subscription을 upgrade 또는 downgrade하고, 수량을 조정하거나, 다른 product로 이전할 수 있습니다. 선택한 proration mode에 따라 변경 시 즉시 청구가 발생하거나 credit이 생성되거나, 청구 조정이 적용되지 않을 수 있습니다.
Dodo Payments dashboard에서 직접 subscription 플랜을 변경하고 다음 billing 날짜를 업데이트할 수 있습니다. API 호출 없이 고객 지원 요청, 프로모션 upgrade 또는 플랜 이전에 맞춰 subscription을 빠르게 조정할 수 있습니다.
셀프서비스 플랜 변경 활성화: 고객이 Customer Portal을 통해 직접 subscription을 upgrade 또는 downgrade하도록 하시겠습니까? subscription product를 Product Collection에 추가하고 Subscription Settings에서 “Allow Subscription Updates”를 활성화하세요.

Product Collections

관련 product를 collection으로 그룹화하여 Customer Portal에서 원활한 upgrade/downgrade 경로를 활성화합니다.

Proration Mode

플랜을 변경할 때 고객에게 청구하는 방식을 선택합니다:
네 가지 proration mode 빠른 비교:

prorated_immediately

현재 billing cycle의 남은 기간을 기준으로 비례 금액을 청구합니다. 사용하지 않은 기간을 반영하는 공정한 청구에 적합합니다.

difference_immediately

가격 차액을 즉시 청구하거나(upgrade), 향후 갱신을 위한 credit을 추가합니다(downgrade). 간단한 upgrade/downgrade 시나리오에 적합합니다.
difference_immediately를 사용한 downgrade의 credit은 subscription 범위에 적용되며 향후 갱신에 자동으로 사용됩니다. 이는 Credit-Based Billing entitlement와는 별개입니다.
고객이 difference_immediately로 downgrade하면 사용하지 않은 금액이 subscription 범위의 credit이 되어 향후 갱신 금액을 자동으로 상쇄합니다:

full_immediately

남은 기간을 무시하고 새로운 플랜의 전체 금액을 즉시 청구합니다. Billing cycle을 재설정할 때 적합합니다.

do_not_bill

청구 조정 없이 새로운 플랜으로 전환합니다. proration 청구도 credit도 없으며 고객은 단순히 새로운 플랜으로 이동합니다. 배려 차원의 이전, 무료 플랜 전환 또는 가격 차액을 부담하려는 경우에 적합합니다.
시나리오: Basic(30/)고객이30일주기의16일째에proratedimmediately를사용하여Pro(30/월) 고객이 30일 주기의 16일째에 `prorated_immediately`를 사용하여 Pro(80/월)로 upgrade합니다.
다음 갱신일은 2월 15일(1월 16일 + 30일)이며 가격은 $80.00/월입니다.
더 자세한 계산 예시와 예외 사례는 전체 Upgrade & Downgrade Guide를 참조하세요.
시나리오: Pro(80/)고객이differenceimmediately를사용하여Starter(80/월) 고객이 `difference_immediately`를 사용하여 Starter(20/월)로 downgrade합니다.
$60 credit은 향후 갱신에 자동으로 적용됩니다:
  • 갱신 1: 2020 − 20(credit) = **0.00(남은credit0.00**(남은 credit 40)
  • 갱신 2: 2020 − 20(credit) = **0.00(남은credit0.00**(남은 credit 20)
  • 갱신 3: 2020 − 20(credit) = $0.00(credit 소진)
  • 갱신 4: $20.00(전체 가격)
credit 관리 방법에 대한 자세한 내용은 Upgrade & Downgrade Guide를 참조하세요.

Add-on을 사용한 플랜 변경

플랜을 변경할 때 add-on을 수정할 수 있습니다. add-on은 proration 계산에 포함됩니다:
기본적으로 (effective_at: 'immediately') 플랜 변경은 즉시 청구를 발생시킵니다. 변경을 다음 billing date에 예약하려면 effective_at: 'next_billing_date'을 전달하세요. 이 경우 pending change는 구독에 scheduled_change로 반환되며, 예약된 플랜 변경 취소를 사용해 취소할 수 있습니다. 청구에 실패하면 구독이 on_hold 상태로 변경될 수 있습니다. 단, on_payment_failure: 'prevent_change'을 전달하면 결제가 성공할 때까지 구독이 현재 플랜으로 유지됩니다. subscription.plan_changed webhook 이벤트를 통해 변경 사항을 추적하세요.

플랜 변경 미리보기

플랜 변경을 확정하기 전에 정확한 청구 금액과 변경 결과 subscription을 미리 확인합니다:

Preview Change Plan API

플랜 변경을 확정하기 전에 미리 확인하세요.

구독 일시 중지 및 재개

일시 중지는 구독을 종료하지 않고 동결합니다. 청구가 중지되고 액세스 권한이 취소되지만, 고객이 중지한 지점에서 정확히 다시 시작할 수 있도록 구독의 요금제와 기록은 유지됩니다. 취소를 대신할 고객 유지 방법으로 사용할 수 있습니다. Sales → Subscriptions에서 활성 구독을 열고 Pause subscription을 클릭합니다. 상태가 paused로 변경되고, 구독이 재개될 때까지 갱신이 중지됩니다.
대시보드의 구독 세부정보 페이지에 Update, Pause subscription 및 Cancel Subscription 버튼이 표시된 모습

일시 중지 시 발생하는 일

  • 갱신이 중지됩니다. 구독이 일시 중지된 동안에는 invoice가 생성되지 않으며 갱신 요금이 청구되지 않습니다.
  • 액세스 권한이 즉시 취소됩니다. 일시 중지하면 구독에 대해 제공된 모든 entitlement grant와 보류 중인 entitlement grant가 취소됩니다. 이에 따라 license keys가 비활성화되고 새로운 digital product 다운로드 URL 발급이 중지됩니다. 재개하면 on_hold에서 복구할 때와 동일한 방식으로 다시 부여됩니다.
  • 청구 시계가 동결됩니다. next_billing_dateexpires_at는 모두 일시 중지된 정확한 기간만큼 뒤로 이동하므로, 고객은 이미 결제한 시간을 그대로 유지합니다.
  • 일시 중지 기간 제한이 없습니다. 일시 중지된 구독은 누군가 재개할 때까지 일시 중지 상태로 유지됩니다. 미리 일시 중지 기간을 설정할 필요가 없습니다.
일시 중지는 청구 기간이 끝날 때가 아니라 즉시 액세스 권한을 취소합니다. 구독이 제품 이용을 제어한다면 고객이 확인하기 전에 이 점을 명확히 안내하세요.
재개하면 구독이 active로 돌아가고 entitlement가 복원됩니다. 시계가 동결되었으므로 다음 갱신은 원래 예정된 시점보다 일시 중지 기간만큼 늦게 발생합니다. 예를 들어 12일 동안 일시 중지된 구독은 12일 늦게 갱신됩니다.

Usage-Based Subscription 일시 중지

usage-based 구독은 일시 중지되는 시점에 기록되었지만 아직 청구되지 않은 usage가 있을 수 있습니다. Settings → SubscriptionsBill Usage at Pause 설정에 따라 처리 방식이 결정됩니다. 이 방식으로 정산되는 것은 metered usage뿐이며, recurring base fee는 일시 중지 시점에 청구되지 않습니다. Standard 및 on-demand subscription에는 정산할 항목이 없으므로 이 설정의 영향을 받지 않습니다.
Bill Usage at Pause는 각 billing cycle별로 기록됩니다. 주기 중간에 설정을 변경해도 이미 진행 중인 주기의 정산 방식은 바뀌지 않으며, 새 값은 다음 주기부터 적용됩니다.
정산 invoice는 다른 invoice와 동일한 방식으로 수금되므로 실패할 수 있습니다. dunning 유예 기간이 지나도록 미납 상태로 남아 있으면 구독은 on_hold로 전환되며, 일시 중지 상태라는 플래그는 계속 유지됩니다.
이 상태의 구독에는 두 가지 해결 방법이 있으며, 미청구 usage를 누가 부담하는지가 서로 다릅니다.
재개는 이 보류 상태에서 벗어나는 유효한 방법이므로, 먼저 정산 invoice를 수금할 필요가 없습니다. 다만 재개하면 미청구 usage를 이월하는 대신 면제하게 된다는 점에 유의하세요.

고객이 직접 구독을 일시 중지하도록 허용

Settings → SubscriptionsAllow Subscription Pause는 고객이 Customer Portal에서 구독을 일시 중지하고 재개할 수 있는지 제어합니다. 기본값은 off이므로 셀프서비스 일시 중지는 별도로 활성화해야 합니다.
Allow Subscription Pause 및 Bill Usage at Pause 토글이 표시된 Subscriptions 설정 탭
이 설정은 Customer Portal에만 적용됩니다. 토글 설정과 관계없이 대시보드 또는 API에서 언제든지 구독을 일시 중지하고 재개할 수 있습니다. 설정을 끄면 고객이 새로 일시 중지하는 것은 막히지만, 이미 일시 중지한 고객의 재개까지 막지는 않습니다. 고객은 자신이 시작한 일시 중지를 계속 재개할 수 있습니다. 직접 시작한 일시 중지는 계속 관리할 수 있습니다.

Pausing from the Customer Portal

확인 대화상자를 포함하여 고객에게 표시되는 내용을 확인하세요.

API를 통한 일시 중지

일시 중지와 재개는 update subscription endpoint의 하나의 pause field로 처리됩니다. 별도의 일시 중지 endpoint는 없습니다.
pause는 다른 모든 field와 함께 사용할 수 없습니다. 다른 항목과 함께 보내면 422 오류가 반환됩니다. statuspaused로 설정해도 구독이 일시 중지되지는 않습니다. 대신 pause field를 사용하세요.
일시 중지하면 subscription.paused가 발생하고, 재개하면 subscription.unpaused가 발생합니다. 두 event 모두 전체 subscription object를 포함하며, 일시 중지 중에는 paused_at가 설정되고 재개 후에는 null가 설정됩니다.

일시 중지와 다른 구독 작업

  • 취소는 계속 작동합니다. 활성 구독과 동일한 방식으로 일시 중지된 구독을 취소할 수 있습니다. 일시 중지로 인해 열려 있는 정산 invoice가 있다면 취소 시 voided 처리됩니다.
  • 예약된 요금제 변경은 삭제되지 않고 지연됩니다. 다음 billing date로 예약된 plan change는 구독이 일시 중지된 동안 그대로 유지되며, 재개 후 변경된 billing date에 적용됩니다. 해당 scheduled_change.effective_at는 예약 당시의 snapshot이므로 일시 중지에 따라 조정되지 않습니다. 따라서 과거 날짜가 표시될 수 있으며, 이를 보장된 날짜가 아닌 “예정되었던 날짜”로 해석하세요. 변경을 적용하지 않고 삭제하려면 Cancel Scheduled Plan Change를 사용하세요.

구독 상태

구독은 수명 주기 동안 정의된 여러 status를 거칩니다. 다음 표는 각 status의 의미와 원인, 복구 가능 여부 및 복구 방법을 정리한 기준입니다.
on_holdfailed를 혼동하는 경우가 많습니다. on_hold는 이미 활성화된 구독의 갱신이 실패했을 때 발생하는 복구 가능한 상태입니다. failed최초 구독 생성이 실패했을 때만 발생하는 terminal 상태이며 재활성화할 수 없습니다.
on_holdpaused도 서로 다릅니다. on_hold는 결제 실패로 인한 비자발적 상태입니다. paused는 판매자 또는 고객이 구독을 동결하기로 선택한 의도적인 상태이며, 일시 중지된 동안에는 갱신이 시도되지 않습니다. usage-based 구독은 일시 중지 시점에 일회성 정산 invoice가 미청구 상태로 남을 수 있습니다. Usage-Based Subscription 일시 중지를 참조하세요.

상태 머신

보류 상태

다음과 같은 경우 구독은 on_hold 상태가 됩니다.
  • 갱신 결제 실패(잔액 부족, 카드 만료 등)
  • 요금제 변경 요금 결제 실패
  • 결제 수단 authorization 실패
  • usage-based 구독의 일시 중지 정산 invoice 미납
구독이 on_hold 상태이면 자동으로 갱신되지 않습니다. 구독을 재활성화하려면 결제 수단을 업데이트해야 합니다.

보류 상태에서 재활성화

on_hold 상태의 구독을 재활성화하려면 결제 수단을 업데이트하세요. 그러면 다음 작업이 자동으로 수행됩니다.
  1. 미납 잔액에 대한 charge 생성
  2. invoice 생성
  3. 새 결제 수단을 사용하여 결제 처리
  4. 결제가 성공하면 구독을 active 상태로 재활성화
유일한 예외는 일시 중지 정산 invoice 미납으로 인해 보류된 경우입니다. 해당 invoice를 정산하면 구독은 active가 아닌 paused로 돌아갑니다. 결제 실패 전 상태가 일시 중지였기 때문입니다. invoice가 정산되면 명시적으로 재개하세요.
on_hold 구독의 결제 수단을 성공적으로 업데이트하면 payment.succeeded event 다음에 subscription.active webhook event가 전송됩니다.

전환별 Webhook Event

각 전환은 webhook을 발생시키므로 polling 없이 entitlement 로직을 구동할 수 있습니다.

Subscription Webhook Payloads

구독 lifecycle event의 전체 payload schema를 확인하세요.

API 관리

POST /checkouts를 사용하면 선택적 trial(subscription_data.trial_period_days) 및 add-on(product_cart[].addons)이 포함된 product에서 programmatically subscription을 생성할 수 있습니다.
POST /subscriptions는 deprecated 상태입니다. 기존 integration은 계속 작동하지만, 새로운 integration에는 Checkout Sessions을 사용해야 합니다.

API Reference

create checkout session API를 확인하세요.
PATCH /subscriptions/{subscription_id}를 사용하여 다음 billing date에 취소하거나, subscription period를 연장하거나, billing details를 업데이트하거나, metadata를 수정할 수 있습니다. quantity를 변경하려면 대신 Change Plan API를 사용하세요. PATCHquantity를 허용하지 않습니다.

API Reference

subscription details를 업데이트하는 방법을 알아보세요.
일시 중지와 재개는 PATCH /subscriptions/{subscription_id} endpoint에서 pause field를 사용하여 처리합니다. pause: true는 활성 구독을 일시 중지하고 pause: false는 재개합니다. 이 field는 동일한 request에서 다른 field와 함께 사용할 수 없습니다. 전체 동작, billing effect 및 관련 business setting은 구독 일시 중지 및 재개를 참조하세요.

API Reference

pause field를 포함한 update subscription API를 확인하세요.
proration control을 사용하여 활성 product와 quantity를 변경하세요.

API Reference

plan change option을 검토하세요.
on-demand subscription의 경우 필요할 때 특정 금액을 청구하세요.

API Reference

on-demand subscription을 청구하세요.
GET /subscriptions를 사용하여 모든 subscription을 나열하고 GET /subscriptions/{id}를 사용하여 하나를 조회하세요.

API Reference

목록 조회 및 단일 조회 API를 확인하세요.
metered 또는 hybrid pricing model에 기록된 usage를 가져옵니다.

API Reference

usage history API를 확인하세요.
subscription의 payment method를 업데이트합니다. 활성 subscription의 경우 향후 갱신에 사용할 payment method가 업데이트됩니다. on_hold 상태의 subscription에서는 미납 잔액에 대한 charge를 생성하여 subscription을 재활성화합니다.새 payment-method link(New request type)를 생성할 때 allowed_payment_method_types를 전달하여 해당 페이지에 고객에게 표시할 payment method를 제한할 수 있습니다. 목록에 없는 method는 고객에게 표시되지 않지만, method를 포함한다고 해서 반드시 표시되는 것은 아닙니다. 사용 가능 여부는 고객의 위치와 business setting 등의 요인에 따라 달라집니다.

API Reference

payment method를 업데이트하고 subscription을 재활성화하는 방법을 알아보세요.

일반적인 사용 사례

  • SaaS 및 API: seat 또는 usage에 대한 add-on을 포함한 tiered access
  • 콘텐츠 및 미디어: introductory trial이 포함된 월간 access
  • B2B support plan: premium support add-on이 포함된 연간 계약
  • 도구 및 plugin: license key 및 versioned release

Integration 예시

Checkout Sessions (subscription)

checkout session을 생성할 때 subscription product와 선택적 add-on을 포함하세요.

proration을 사용한 plan change

subscription을 업그레이드하거나 다운그레이드하고 proration 동작을 제어하세요.

다음 billing date에 취소

현재 billing period가 끝날 때 적용되는 취소를 예약하세요.

subscription period 연장

subscription_period_countsubscription_period_interval에 새 값을 전달하고 PATCH /subscriptions/{subscription_id}를 호출하여 subscription이 실행되는 기간을 연장하세요. subscription expiry는 새 count와 interval을 기준으로 다시 계산됩니다. 예를 들어 고객의 현재 plan에 추가 기간을 제공할 수 있습니다.
subscription period는 늘릴 수만 있으며, 단축할 수는 없습니다.

On-demand subscription

필요할 때 나중에 청구할 수 있는 on-demand subscription을 생성하세요.

활성 subscription의 payment method 업데이트

활성 subscription의 payment method를 업데이트하세요.

on_hold 상태에서 subscription 재활성화

결제 실패로 on hold 상태가 된 subscription을 재활성화하세요.

RBI-Compliant Mandate가 적용된 Subscription

UPI 및 인도 카드 subscription은 특정 mandate 요구사항이 적용되는 RBI (Reserve Bank of India) 규정에 따라 운영됩니다.

Mandate 한도

Mandate type과 amount는 subscription의 recurring charge에 따라 달라집니다.
  • mandate floor 미만의 charge(기본값 ₹15,000): floor amount에 대한 on-demand mandate를 생성합니다. subscription amount는 subscription frequency에 따라 mandate limit까지 주기적으로 청구됩니다.
  • mandate floor 이상인 charge: 정확한 subscription amount에 대한 subscription mandate(또는 on-demand mandate)를 생성합니다.
mandate floor는 mandate_min_amount_inr_paise(INR paise)을 통해 merchant별 또는 request별로 구성할 수 있습니다. 은행에 등록되는 amount는 max(mandate_floor, billing_amount)이므로, billing amount가 더 낮을 때 floor가 사실상 고객에게 표시되는 authorization ceiling이 됩니다. RBI-compliant mandate 및 인도 payment method의 구성 가능한 mandate floor에 대한 자세한 내용은 India Payment Methods 페이지를 참조하세요.

업그레이드 및 다운그레이드 고려 사항

중요: subscription을 업그레이드하거나 다운그레이드할 때 mandate limit를 신중하게 고려하세요.
  • 업그레이드/다운그레이드로 인해 charge amount가 Rs 15,000을 초과하고 기존 on-demand payment limit를 넘으면 transaction charge가 실패할 수 있습니다.
  • 이러한 경우 고객은 올바른 limit로 새 mandate를 설정하기 위해 payment method를 업데이트하거나 subscription을 다시 변경해야 할 수 있습니다.

고액 결제 authorization

Rs 15,000 이상인 subscription charge의 경우:
  • 고객의 은행에서 transaction을 authorize하도록 요청합니다.
  • 고객이 transaction을 authorize하지 못하면 transaction이 실패하고 subscription은 보류 상태가 됩니다.

48시간 처리 지연

처리 일정: 인도 카드 및 UPI subscription의 recurring charge는 고유한 처리 방식을 따릅니다.
  • charge는 subscription frequency에 따라 예정일에 시작됩니다.
  • 고객 계정에서 실제 차감은 payment initiation 후 48시간이 지나야 발생합니다.
  • 은행 API response에 따라 이 48시간의 대기 시간이 추가 2~3시간 연장될 수 있습니다.

Mandate 취소 가능 기간

48시간 처리 기간 동안:
  • 고객은 banking app을 통해 mandate를 취소할 수 있습니다.
  • 이 기간에 고객이 mandate를 취소해도 subscription은 active 상태로 유지됩니다(인도 카드 및 UPI AutoPay subscription에만 해당하는 edge case입니다).
  • 그러나 실제 차감은 실패할 수 있으며, 이 경우 subscription을 on hold 상태로 전환합니다.
Edge Case 처리: charge가 시작되자마자 고객에게 benefit, credit 또는 subscription usage를 제공한다면 애플리케이션에서 이 48시간의 대기 시간을 적절히 처리해야 합니다. 다음을 고려하세요.
  • payment confirmation까지 benefit activation 지연
  • grace period 또는 temporary access 구현
  • mandate 취소를 확인하기 위한 subscription status 모니터링
  • 애플리케이션 로직에서 subscription hold state 처리
subscription webhook을 모니터링하여 payment status 변경을 추적하고 48시간 동안 mandate가 취소되는 edge case를 처리하세요.

Best Practices

  • 명확한 tier로 시작하세요: 차이가 분명한 2~3개의 plan
  • 가격을 명확히 안내하세요: total, proration 및 다음 renewal 표시
  • trial을 신중하게 사용하세요: 단순히 기간만 제공하지 말고 onboarding을 통해 전환
  • add-on을 활용하세요: base plan은 단순하게 유지하고 추가 기능을 upsell
  • 변경 사항을 테스트하세요: test mode에서 plan change와 proration 검증
Subscription은 recurring revenue를 위한 유연한 기반입니다. 단순하게 시작하고 철저히 테스트한 뒤 adoption, churn 및 expansion metric을 기준으로 반복 개선하세요.
마지막 수정일 2026년 8월 21일