SaaS 구독을 위한 추천 크레딧 시스템 설계

Q: How do you reliably track who referred who?

Use one primary source of truth, typically a referral link token or short code . Best practice is: - Capture the token on the landing page - Store it in first-party storage - Attach it to the account at signup - Optionally allow entering a code once during onboarding if the token is missing

Q: How do we prevent self-referrals and obvious abuse?

Start with simple, explainable blocks: - Same user account - Same verified email - Same payment method fingerprint Then add light abuse controls without punishing normal users: - Require verification + a paid invoice before credits become usable - Rate-limit bursts (many signups in a short window) - Hold suspicious rewards as “pending review” instead of auto-banning

Q: What happens to credits if the referred user gets a refund or chargeback?

Define a clear reversal policy tied to billing events: - If the qualifying invoice is fully refunded or charged back, reverse the referral credit - If an invoice is voided before capture, don’t grant credit For partial refunds, pick one rule and stick to it: - Proportional reversal (fairer, more complex), or - Full reversal (simpler, can feel strict)

Q: How should credits apply to renewals, upgrades, proration, and taxes?

A predictable default is: 1) Calculate subscription charges (including proration) 2) Apply discounts 3) Compute tax 4) Apply credits last Rules that reduce confusion: - Credits can’t make the invoice due less than $0 - Unused credits roll forward - Apply credits oldest-first so results are repeatable

Q: What’s the simplest MVP for a referral credits system that won’t create support chaos?

A minimal MVP that still stays supportable: - One conversion rule (e.g., first successful paid invoice) - One reward rule (flat amount is easiest to explain) - Referral record stored as a first-class object (not guessed from clicks) - Ledger entries for earn/spend/reversal with idempotency keys - A basic support view: timeline of invite → signup → payment → credit After that, add UI and admin tools before adding complicated reward tiers.

로그인 시작하기

SaaS 구독을 위한 추천 크레딧 시스템 설계 | Koder.ai

구축 전 결정해야 할 규칙들

추천 프로그램은 간단해 보이지만 첫 번째 티켓이 도착하면 복잡해집니다: "왜 크레딧을 못 받았나요?" 대부분의 작업은 코드가 아니라 정책입니다.

트리거부터 시작하세요. "초대 발송"은 너무 이릅니다. "가입"은 일회용 계정으로 악용되기 쉽습니다. 일반적인 적절한 지점은 "자격을 갖춘 전환": 이메일 인증 + 첫 번째 유료 인보이스 또는 체험 후 첫 번째 성공 결제입니다. 하나의 트리거를 선택하고 일관되게 유지하면 원장이 깔끔하게 유지됩니다.

다음으로, 금액과 제한을 정하세요. 크레딧은 실감 나야 하지만 무제한 할인 수단이 되어선 안 됩니다. 고정 금액(예: $20 크레딧)인지 청구의 비율인지 결정하고, 한 문장으로 설명할 수 있는 방식으로 상한을 두세요.

나중에 가장 많은 혼란을 막는 결정들은:

어떤 이벤트가 자격을 갖추는가(첫 결제, 첫 갱신 등)
얼마나 많은 크레딧을 주는가(고정 vs 비율, 요금제별 차등 여부)
상한(추천당, 월별, 평생)
어떤 요금제와 거래 유형이 포함되는가
크레딧 만료 여부

자격 규칙은 사람들이 예상하는 것보다 중요합니다. 유료 요금제만 해당된다면 분명히 밝혀야 합니다. 특정 지역이 제외된다면(세금, 규정, 프로모션) 그 또한 명시하세요. 연간 요금제가 자격되지만 월간은 아니라면 분명히 하세요. Koder.ai와 같이 여러 계층이 있는 플랫폼이라면, 무료에서 프로로의 업그레이드가 자격 대상인지, 엔터프라이즈 계약은 수동으로 처리할지 미리 결정하세요.

사용자에게 보여줄 문구를 제품 출시 전에 작성하세요. 각 규칙을 두 문장으로 설명할 수 없다면, 사용자는 오해할 것입니다. 어조는 단호하지만 차분하게 유지하세요: "의심스러운 활동에 대해 크레딧을 보류할 수 있습니다"는 긴 위협 목록보다 명확합니다.

초대에서 자격 전환까지 추천을 추적하는 방법

하나의 기본 식별자를 선택하고 다른 모든 것은 보조 증거로 취급하세요. 가장 깔끔한 옵션은 추천 링크 토큰(공유하기 쉬움), 짧은 코드(입력하기 쉬움), 특정 이메일로 보낸 초대(직접 초대에 적합)입니다. 하나를 진실의 출처로 선택하면 귀속이 예측 가능하게 유지됩니다.

해당 식별자를 가능한 한 일찍 캡처하고 전체 여정에 걸쳐 보관하세요. 링크 토큰은 일반적으로 랜딩 페이지에서 캡처되어 퍼스트 파티 스토리지에 저장되고 가입 시 다시 제출됩니다. 모바일에서는 가능할 때 앱 설치 흐름을 통해 전달하되 가끔 잃을 것을 가정하세요.

비즈니스 규칙에 맞는 소수의 이벤트만 추적하세요. 목표가 "지불 고객이 되었는가"(단순 클릭이 아닌)라면 최소한의 집합으로 충분합니다:

referral_click (토큰 확인)
account_signup (새 사용자 생성)
account_verified (이메일/전화 인증)
first_paid_invoice (첫 성공 결제)
qualification_locked (전환 확정 및 변경 불가)

기기 전환과 차단된 쿠키는 정상입니다. 과도한 추적 없이 이를 처리하려면 가입 중에 청구(claim) 단계를 추가하세요: 사용자가 토큰과 함께 도착하면 새 계정에 첨부하고, 그렇지 않으면 온보딩 중 한 번만 짧은 추천 코드를 입력하게 허용하세요. 둘 다 존재하면 처음 캡처된 값을 기본으로 유지하고 다른 것은 보조 증거로 저장하세요.

마지막으로, 지원팀이 1분 내에 읽을 수 있는 단순한 추천 타임라인을 유지하세요: 추천자, 추천받은 계정(알려질 경우), 현재 상태, 마지막 의미 있는 이벤트와 타임스탬프. 누군가가 "왜 크레딧을 못 받았나요?"라고 물으면 "가입은 되었지만 첫 유료 인보이스가 없었습니다"처럼 사실로 답할 수 있어야 합니다.

읽기 쉽고 디버그 가능한 데이터 모델

추천 프로그램은 데이터 모델이 모호할 때 보통 망칩니다. 지원팀은 "누가 누구를 추천했나?"라고 묻고 청구팀은 "크레딧이 이미 발급되었나?"라고 묻습니다. 로그를 뒤지지 않고 답할 수 없다면 모델을 더 엄격하게 만들어야 합니다.

추천 관계를 파생된 추측이 아니라 일급 레코드로 저장하세요.

저장할 핵심 레코드

간단하고 디버그 가능한 설정은 다음과 같습니다:

referrals: id, referrer_user_id, referred_user_id, created_at, source (초대 링크, 쿠폰, 수동), status, status_updated_at
referral_attribution (선택적): referral_id, invite_code_id 또는 campaign_id, first_seen_ip_hash, first_seen_user_agent_hash
workspaces (팀이 있다면): workspace_id, owner_user_id, created_at
workspace_members: workspace_id, user_id, role, joined_at

referrals 테이블은 작게 유지하세요. 나중에 후회할 수 있는 데이터(원시 IP, 전체 user agent, 이름 등)는 피하거나 단기 해시로만 저장하고 명확한 보존 정책을 두세요.

상태는 명확하고 상호 배타적으로 만드세요: pending(가입했지만 아직 자격 없음), qualified(규칙 충족), credited(크레딧 발급), rejected(검사 실패), reversed(환불/차지백으로 크레딧 회수).

중복 집계 방지 규칙

우선순위를 한 번 결정하고 데이터베이스에서 강제하세요. 그래야 앱이 실수로 중복 지급하지 못합니다. 최소한 다음을 보장하세요:

추천받은 계정당 하나의 추천자만 허용( referred_user_id에 고유 제약 )
추천받은 계정당 하나의 referral만 credited 상태에 도달 가능
여러 접촉이 발생하면 first-touch 또는 last-touch를 선택하고 선택한 referral_id를 저장

팀을 지원한다면 추천이 개인 가입에 붙는지 아니면 워크스페이스 생성에 붙는지 결정하세요. 둘 다 하려 하지 마세요. 실용적인 접근법은 추천을 사용자 계정에 연결하고, 자격 여부는 해당 사용자가(또는 그들의 워크스페이스가) 유료 가입자가 되었는지로 판단하는 것입니다.

크레딧 원장 기본: 정확하고 감사 가능하며 설명 가능하게

Test messy billing cases

Map upgrades, downgrades, proration, and credits order before billing bugs appear.

Plan It

청구 버그와 지원 티켓을 줄이려면 단일 "크레딧 잔액" 필드 대신 원장(ledger)을 사용하세요. 잔액 숫자는 덮어쓰기, 반올림, 이중 업데이트될 수 있습니다. 원장은 항상 합산할 수 있는 항목의 역사입니다.

엔트리 유형은 제한하고 모호함을 없애세요: earn(부여), spend(인보이스에 적용), expire, reversal(회수), manual adjustment(메모와 승인자 표시).

모든 항목은 엔지니어와 지원팀 모두가 읽을 수 있어야 합니다. 일관된 필드를 저장하세요: 금액, 크레딧 유형(크레딧이 현금이 아니라면 단순히 "USD"라고 표기하지 마세요), 이유 텍스트, 소스 이벤트(예: referral_signup_qualified), 소스 ID(사용자, 추천받은 사용자, 구독 또는 인보이스), 타임스탬프, created_by(system 또는 admin).

멱등성(idempotency)은 사람들이 생각하는 것보다 중요합니다. 같은 웹후크나 백그라운드 작업이 두 번 실행될 수 있습니다. 소스 이벤트마다 고유한 idempotency 키를 요구해 재시도해도 중복 크레딧이 발행되지 않게 하세요.

사용자에게 설명 가능하도록 만드세요. 누군가가 "왜 20 크레딧을 받았죠?"라고 물으면 어떤 추천이 그것을 트리거했는지, 언제 게시되었는지, 만료되는지, 이후에 회수가 있었는지 보여줄 수 있어야 합니다. 친구가 업그레이드하면 그 업그레이드 이벤트에 연결된 earn 항목을 추가하세요. 결제가 환불되면 환불 이벤트에 연결된 reversal 항목을 게시하세요.

자기 추천과 일반적인 악용 방지(과도하지 않게)

대부분의 사람은 정직하다고 가정하되 몇몇은 명백한 트릭을 시도할 것입니다. 목표는 쉬운 악용을 막고 규칙을 명확히 하며 같은 Wi‑Fi를 쓰거나 가족 카드로 결제하는 정상 사용자를 차단하지 않는 것입니다.

설명 가능한 간단한 규칙으로 자기 추천 차단

정당화할 수 있는 강력한 차단부터 시작하세요. 추천자와 추천받은 계정이 분명히 같은 사람일 때는 크레딧을 지급하지 마세요. 예를 들면 동일한 사용자 ID, 동일한 검증된 이메일, 동일한 결제 수단 지문 등입니다. 이메일 도메인 규칙은 도움이 될 수 있지만 범위를 좁게 유지하세요. 회사 도메인 전체를 차단하면 합법적인 팀을 해칠 수 있습니다.

그 다음 루프와 대량 가입을 위한 가벼운 탐지 로직을 추가하세요. 초기 단계에 완벽한 사기 점수가 필요하지 않습니다. 몇 가지 강한 신호가 대부분의 악용을 잡습니다: 짧은 시간에 동일 기기에서 많은 가입, 같은 IP 대역에서 반복 사용, 여러 "새" 계정에 같은 카드 사용, 이메일 인증을 거의 하지 않는 계정들, 또는 크레딧 적용 후 빠른 취소‑재가입 패턴.

크레딧이 사용 가능해지기 전에 자격 조건을 요구하세요(예: 이메일 인증 + 유료 인보이스). 이는 봇과 무료 계층 이탈이 노이즈를 생성하는 것을 막습니다.

정상 사용자를 처벌하지 않고 악용을 늦추기

추천 링크와 적립에 대해 레이트 리미트와 쿨다운을 추가하되 필요할 때까지 조용히 유지하세요. 같은 네트워크에서 한 시간에 링크가 20번 사용되면 보상을 일시 중지하고 플래그를 세우세요.

개입할 때는 경험을 차분하게 유지하세요. 결제가 완료될 때까지 크레딧을 보류(pending)로 표시하고 보상이 지연되는 명확한 이유를 보여주며(비난 대신), 지원에 연락할 간단한 방법을 제공하고, 엣지 케이스는 자동 차단 대신 수동 검토로 보내세요.

예시: 스타트업 팀이 한 사무실 IP를 공유합니다. 같은 날 세 명의 동료가 같은 추천으로 가입했습니다. 인증 + 유료 인보이스 + 기본 쿨다운이 있으면 인보이스가 결제된 후에도 크레딧을 받을 수 있고, 봇 같은 급증은 검토 대상으로 보류됩니다.

현실에서 발생하는 복잡한 경우: 환불, 회수, 계정 변경

추천 프로그램은 돈이 "잘못" 움직일 때 단순하지 않게 느껴집니다: 환불, 차지백, 인보이스 무효화, 계정 소유권 변경 등. 이러한 경우를 미리 설계하면 분노한 사용자와 긴 지원 스레드를 피할 수 있습니다.

언제 크레딧을 회수할지(그리고 방법)

크레딧을 단순 가입이 아니라 유료 결과에 기반해 얻는 것으로 간주하세요. 그런 다음 청구 이벤트에 연결된 회수 정책을 정의하세요.

지원팀이 설명할 수 있는 규칙 세트:

원래의 유료 인보이스가 전액 환불되거나 차지백되면 해당 인보이스에 대해 부여된 추천 크레딧을 회수합니다.
인보이스가 결제 캡처 전에 취소되면 크레딧을 부여하지 않습니다.
예를 들어 "인보이스 결제 시" 크레딧을 부여했다면, 회수는 자동으로 이루어지고 명확한 기록을 남겨야 합니다.

부분 환불은 팀들이 자주 막히는 곳입니다. 한 가지 방식을 선택하고 일관되게 유지하세요: 비례 회수(30% 환불에 대해 크레딧의 30%를 회수) 또는 전액 회수(어떤 환불이든 전체 크레딧을 회수). 비례 방식이 공정하지만 설명하고 테스트하기가 더 어렵습니다. 전액 회수는 간단하지만 가혹하게 느껴질 수 있습니다.

체험에서 유료 전환도 명확히 하세요. 일반적인 접근법은 체험 기간 동안 크레딧을 보류했다가 첫 성공 결제(옵션으로 짧은 유예 기간 후)가 확인되면 잠금 해제하는 것입니다.

계정 병합 및 소유권 변경

사람들은 이메일을 바꾸고, 계정을 병합하고, 개인 사용에서 팀 워크스페이스로 옮겨갑니다. 무엇이 사람을 따라가는지, 무엇이 유료 계정을 따라가는지 결정하세요. 구독 대상이 워크스페이스라면 크레딧은 종종 해당 워크스페이스에 귀속되며, 떠나는 구성원에게 따라가지 않습니다.

계정 병합이나 팀 소유권 이전을 지원한다면 기록을 재작성하지 말고 조정 이벤트를 기록하세요. 모든 회수나 수동 보정에는 "인보이스 10482의 차지백" 또는 "워크스페이스 소유권 이전 — 지원 승인" 같은 지원 친화적 메모를 포함하세요. Koder.ai 같은 플랫폼에서 크레딧이 구독에 적용될 때, 그러한 메모가 "왜 내 크레딧이 변했나요?"에 대한 답을 한 번의 조회로 가능하게 합니다.

크레딧을 구독에 깔끔하게 적용하기

Generate the core data model

Create Go and PostgreSQL tables for referrals and credit ledgers without boilerplate.

Build Now

추적보다 더 어려운 부분은 갱신, 업그레이드, 다운그레이드, 세금을 가로질러 크레딧이 일관되게 동작하게 만드는 것입니다.

먼저 크레딧을 어디에 쓸 수 있는지 결정하세요. 어떤 팀은 크레딧을 다음 새 인보이스에만 적용합니다. 다른 팀은 열린(미결제) 인보이스 어느 것이든 적용할 수 있게 합니다. 하나의 규칙을 선택하고 UI에 표시해 사용자에게 놀람을 주지 마세요.

다음으로, 연산 순서를 고정하세요. 예측 가능한 접근법은: 구독 요금(프러에이션 포함)을 계산하고, 할인 적용, 세금 계산, 마지막으로 크레딧을 적용하는 것입니다. 크레딧을 마지막에 적용하면 세금 로직이 일관되고 크레딧이 과세 대상 금액을 줄였는지에 대한 논쟁을 피할 수 있습니다. 법적/세무 규정이 다른 순서를 요구하면 문서화하고 테스트를 작성하세요.

프러에이션은 청구 버그가 자주 드러나는 곳입니다. 누군가 중간에 업그레이드하면 프러에이션 항목(요금 또는 크레딧)을 만들고 이를 다른 항목처럼 처리하세요. 그런 다음 추천 크레딧은 개별 항목이 아니라 인보이스 총액에 적용하세요.

인보이스 규칙을 엄격히 유지하세요:

크레딧은 고객이 지불해야 할 금액을 줄이되 $0 미만으로 만들 수 없다.
사용되지 않은 크레딧은 향후로 이월된다.
크레딧은 고정된 순서(오래된 것부터)로 적용해 결과가 반복 가능하도록 한다.
인보이스가 무효화되거나 환불되면 해당 인보이스에서 실제로 소비된 크레딧만 회수한다.

예시: 사용자가 중간에 업그레이드하여 $12의 프러에이션 요금이 발생했습니다. 할인과 세금을 포함해 인보이스 총액이 $32가 되었습니다. 추천 크레딧이 $50 있다면 $32를 적용해 인보이스를 $0로 만들고 남은 $18은 다음 갱신을 위해 유지합니다.

단계별 구현 계획 (MVP에서 v1까지)

추천 프로그램을 마케팅 위젯이 아니라 작은 청구 기능으로 취급하세요. 목표는 지루한 일관성입니다: 모든 크레딧에는 이유, 타임스탬프, 다음 인보이스로의 명확한 경로가 있어야 합니다.

MVP (며칠 내로 출시)

하나의 전환 이벤트와 하나의 크레딧 규칙을 선택하세요. 예: 초대한 사용자가 유료 가입자가 되고 첫 결제가 성공적으로 처리될 때만 추천이 인정됩니다.

MVP는 엔드 투 엔드 경로를 중심으로 구축하세요: 가입 시 추천 토큰이나 코드 캡처, 결제 성공 시(사용자가 카드를 입력할 때가 아니라) 자격 판정 실행, 고유 idempotency 키로 원장 엔트리 작성, 예측 가능한 순서로 다음 인보이스에 크레딧 적용.

진실의 원천을 일찍 결정하세요. 청구 제공자가 진실의 원천인지 앱의 내부 원장이 진실의 원천인지 선택하세요. 또는 내부 원장이 진실의 원천이면 청구에는 "이 인보이스에 X 크레딧을 적용"만 전송하세요. 둘을 섞으면 보통 "내 크레딧이 사라졌어요" 티켓이 생깁니다.

v1 (지원 가능한 상태로 만들기)

추천 규칙을 더 추가하기 전에 관리자 도구를 추가하세요. 지원은 사용자, 추천 코드, 인보이스로 검색하고 다음 타임라인을 볼 수 있어야 합니다: 초대, 가입, 자격, 크레딧 부여, 크레딧 사용, 회수. 수동 조정이 포함되어야 하고 항상 짧은 메모를 요구하세요.

그 다음 사용자 UX를 추가하세요: 추천 페이지, 각 초대의 상태 표시(대기, 자격, 크레딧 부여), 인보이스와 일치하는 크레딧 이력.

마지막으로 모니터링을 추가하세요: 추천 급증, 높은 회수율(환불/차지백), 동일 기기나 결제 수단을 공유하는 많은 계정 같은 이상 패턴에 대한 알림. 이는 악용 방지를 강력하게 유지하면서 정상 사용자를 처벌하지 않게 합니다.

예시: 누군가가 Koder.ai 추천을 팀과 공유하면, 그들은 첫 성공적인 유료 가입 이후에만 크레딧이 표시되어야 하고 그 크레딧은 수동 쿠폰이 아니라 다음 갱신에서 자동으로 차감되어야 합니다.

청구 버그와 지원 부하를 만드는 흔한 실수

Build a referral MVP fast

Prototype a referral credit ledger and invoice flow in chat, then iterate safely.

Start Free

대부분의 추천 프로그램 실패는 마케팅이 아니라 청구에서 발생합니다. 티켓을 가장 빠르게 만드는 방법은 크레딧이 예측 불가능하게 만드는 것입니다: 사용자는 왜 크레딧을 받았는지, 언제 적용되는지, 인보이스가 왜 다른지 알 수 없습니다.

흔한 함정은 규칙이 명확하지 않은 상태에서 개발을 시작하는 것입니다. "자격 추천"이 모호하면(체험 시작, 첫 결제, 30일간 유지된 유료 등) 케이스별로 크레딧을 협상하게 되고 환불로 사람들을 보상하게 됩니다.

또 다른 자주 발생하는 문제는 하나의 변경 가능한 "크레딧 잔액" 필드를 사용하는 것입니다. 이는 간단해 보이지만 재시도, 환불, 요금제 변경, 수동 조정이 생기면 숫자가 어긋나고 어디서 비롯됐는지 설명할 수 없게 됩니다.

멱등성도 간과되기 쉽습니다. 결제 제공자는 웹후크를 재시도하고 작업자는 잡을 재시도하며 사용자는 이중 클릭합니다. "크레딧 지급" 동작이 멱등하지 않으면 중복 크레딧이 생성되고 수익이 어긋날 때까지 알아채기 어렵습니다.

크레딧 산식도 총액은 맞는데 동작이 틀릴 수 있습니다. 크레딧을 세금 전에 적용하거나 프러에이션 규칙을 무시하면 결제 시스템과 맞지 않는 인보이스가 생성됩니다. 이는 영수증 불일치, 결제 실패, 번거로운 조정으로 이어집니다.

사기 검사도 지나치게 엄격할 수 있습니다. IP, 기기, 도메인으로 차단하고 검토 경로가 없으면 룸메이트나 동료, 같은 네트워크의 팀 같은 정상 추천을 막아 성장에 조용히 악영향을 줍니다.

주의할 다섯 가지 레드 플래그:

자격 규칙이 코드에만 존재하고 관리자/지원 뷰에 표시되지 않음
크레딧에 중복을 막을 고유 이벤트 키(invite_id, conversion_id)가 없음
"잔액"을 덮어쓰는 방식으로 저장하고 원장 엔트리를 남기지 않음
인보이스가 크레딧을 적용하는 순서가 청구 제공자가 기대하는 순서(세금, 프러에이션, 할인)와 다름
사기 방지에 이의 제기 경로나 수동 재량이 없음

예시: Koder.ai의 Pro 사용자가 중간에 업그레이드하고 추천 크레딧을 얻은 뒤 다운그레이드하면, 단일 잔액 필드를 사용하고 크레딧을 프러에이션 전에 적용하면 다음 인보이스가 틀려 보일 수 있습니다. 원장과 고정된 적용 순서는 이 문제를 긴 지원 스레드로 번지는 것을 막아줍니다.

빠른 체크리스트, 간단한 예시, 다음 단계

출시 전에 몇 가지 확인을 실행하면 대부분의 청구 및 지원 문제를 조기에 잡을 수 있습니다.

계정당 한 명의 추천자: 사용자가 귀속되면 조용히 바뀌지 않도록 하세요.
명확한 자격: 크레딧을 얻는 정확한 이벤트를 정의하세요(예: 첫 유료 인보이스 성공 및 환불되지 않음).
원장 사용, 단일 "잔액" 사용 금지: 모든 크레딧과 차감은 엔트리로 저장하세요.
회수 존재: 환불, 차지백, 취소된 체험은 회수 엔트리를 생성합니다.
관리자 조정은 기록됨: 수동 부여 및 제거는 메모가 있는 정상 원장 엔트리로 남깁니다.

예시: 마야가 노아를 초대합니다. 노아는 마야의 초대에서 가입해 체험을 시작하고 Pro로 업그레이드하여 $30을 결제했습니다. 시스템은 해당 인보이스를 자격 완료로 표시하고 마야에게 $10의 크레딧을 부여하는 원장 엔트리를 생성합니다.

마야의 다음 갱신 시 인보이스 소계가 $30이면 청구 단계는 최대 $10의 크레딧을 적용해 인보이스에 $30 소계, -$10 크레딧, $20 납부로 표시합니다. 마야의 원장에는 적립(+10) 한 항목과 사용(-10, 인보이스 #1234에 적용) 한 항목이 남습니다.

나중에 노아가 첫 결제 환불을 요청하면 시스템은 마야의 적립 크레딧을 제거하는 회수 항목(또는 상응하는 차감)을 추가합니다. 이미 일부 크레딧이 사용된 경우에는 히스토리를 다시 쓰는 대신 다음 인보이스에서 차액을 청구합니다.

다음 두 단계는 신뢰를 해치지 않으면서 속도를 유지하게 해줍니다:

속성을 포함한 전체 흐름을 간략한 기획 문서로 프로토타입: 귀속, 자격, 원장 엔트리, 인보이스 적용, 회수.
샌드박스에서 고정 시나리오 테스트: 체험→유료, 크레딧 사용 후 환불, 중간 업그레이드/다운그레이드, 관리자 조정.

빠르게 움직이되 청구 로직의 제어를 잃고 싶지 않다면, Koder.ai는 Planning Mode와 스냅샷 및 롤백을 포함하여 추천 흐름을 반복하면서 인보이스 수학이 일관되도록 도와줍니다. 플랫폼 내부에서 전체 흐름을 테스트한 뒤 준비되면 코드를 내보낼 수 있습니다.

자주 묻는 질문

Are referral credits the same as getting paid cash?

Referral credits reduce what you owe on future invoices (or extend your subscription time).

They are not cash to a bank account, not gift cards, and not a promise of a payout later. Think of them like store credit that shows up on billing.

What event should count as a “qualified referral”?

A common default is: the referral qualifies after the referred user completes a first successful paid invoice (often after email verification, and sometimes after a short grace period).

Avoid qualifying on “invite sent” or “signup” alone, because those are easy to game and hard to defend in disputes.

How do you reliably track who referred who?

Use one primary source of truth, typically a referral link token or short code.

Best practice is:

Capture the token on the landing page
Store it in first-party storage
Attach it to the account at signup
Optionally allow entering a code once during onboarding if the token is missing

What referral statuses should we store?

Use explicit, mutually exclusive statuses so support can answer questions quickly:

pending: signup exists, not yet eligible
qualified: met the rules (e.g., first paid invoice)
credited: credit was issued

Why use a credit ledger instead of just storing a credit balance?

A single “balance” field gets overwritten, retried, or double-updated and becomes impossible to audit.

A ledger is a list of entries you can always add up:

earn (grant)
spend (applied to invoice)
expire
reversal
manual adjustment (with a note and approver)

That makes billing explainable and debuggable.

How do we prevent double-crediting when webhooks retry?

Make the “award credit” action idempotent by using a unique key per source event (for example, the first paid invoice ID).

If the same webhook or background job runs twice, the second run should safely do nothing, rather than issuing duplicate credits.

How do we prevent self-referrals and obvious abuse?

Start with simple, explainable blocks:

Same user account
Same verified email
Same payment method fingerprint

Then add light abuse controls without punishing normal users:

Require verification + a paid invoice before credits become usable
Rate-limit bursts (many signups in a short window)
Hold suspicious rewards as “pending review” instead of auto-banning

What happens to credits if the referred user gets a refund or chargeback?

Define a clear reversal policy tied to billing events:

If the qualifying invoice is fully refunded or charged back, reverse the referral credit
If an invoice is voided before capture, don’t grant credit

For partial refunds, pick one rule and stick to it:

Proportional reversal (fairer, more complex), or
Full reversal (simpler, can feel strict)

How should credits apply to renewals, upgrades, proration, and taxes?

A predictable default is:

Calculate subscription charges (including proration)
Apply discounts
Compute tax
Apply credits last

Rules that reduce confusion:

Credits can’t make the invoice due less than $0
Unused credits roll forward

What’s the simplest MVP for a referral credits system that won’t create support chaos?

A minimal MVP that still stays supportable:

One conversion rule (e.g., first successful paid invoice)
One reward rule (flat amount is easiest to explain)
Referral record stored as a first-class object (not guessed from clicks)
Ledger entries for earn/spend/reversal with idempotency keys
A basic support view: timeline of invite → signup → payment → credit

After that, add UI and admin tools before adding complicated reward tiers.

추천 크레딧 시스템이란 (그리고 그것이 아닌 것)