8 মিনিট

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-এর জন্য রেফারেল ক্রেডিট সিস্টেম: রেফারেল ট্র্যাক করুন, প্রতারণা ব্লক করুন, এবং সাবস্ক্রিপশনে ক্রেডিট প্রয়োগ করুন স্পষ্ট নিয়ম ও অডিটযোগ্য লেজারের সাথে।

রেফারেল ক্রেডিট সিস্টেম কী (এবং কী নয়)

রেফারেল ক্রেডিট প্রোগ্রাম হলো একটি বিলিং ফিচার, পেমেন্ট ফিচার নয়। পুরস্কার হলো অ্যাকাউন্ট ক্রেডিট যা ভবিষ্যত চার্জ কমায় (বা সময় বাড়ায়)। এটা ব্যাংকে পাঠানো নগদ নয়, গিফট কার্ড নয়, এবং কাউকে পরে "পে করা হবে"—এ ধরনের প্রতিশ্রুতি নয়।

একটি ভালো সিস্টেম প্রতিটি সময় এক প্রশ্নের উত্তর দেয়: "কেন এই অ্যাকাউন্টের পরের ইনভয়েস কম হয়ে গেল?" যদি আপনি এক-দুই বাক্যে এটা ব্যাখ্যা করতে না পারেন, তখন সাপোর্ট টিকিট ও বিরোধ আসবে।

রেফারেল ক্রেডিট সিস্টেমের তিনটি অংশ আছে: কেউ নতুন গ্রাহককে আমন্ত্রণ করে, স্পষ্ট নিয়ম নির্ধারণ করে কখন সেই আমন্ত্রণ গণ্য হবে (conversion), এবং ক্রেডিটগুলো উপার্জিত হয়ে ভবিষ্যৎ সাবস্ক্রিপশন বিলগুলোতে প্রয়োগ করা হয়।

এটা কী নয়: নগদ পে-আউট, এমন একটি অস্পষ্ট ডিসকাউন্ট যা নথি ছাড়া সংখ্যাগুলো বদলে দেয়, বা এমন পয়েন্ট সিস্টেম যা কখনো ইনভয়েসের সাথে যুক্ত হয় না।

অনেক টিম এই বিবরণের উপর নির্ভর করে। রেফারাররা জানতে চায় তারা কী উপার্জন করেছে এবং কখন তা প্রযোজ্য হবে। রেফার হয়ে যাওয়া ব্যবহারকারীরা জানতে চায় তারা কী পায় এবং এটা তাদের প্ল্যানে প্রভাব ফেলে কি না। সাপোর্টকে দ্রুত "আমার ক্রেডিট কোথায় গেল?" সমাধান করতে হবে। ফাইন্যান্সকে এমন মোট দরকার যা ইনভয়েসের সাথে মেলে এবং অডিট করা যায়।

উদাহরণ: স্যাম প্রিয়া-কে রেফার করে। প্রিয়া পেইড প্ল্যান শুরু করে। স্যাম $20 ক্রেডিট উপার্জন করে যা স্যামের পরের ইনভয়েস থেকে সর্বোচ্চ $20 পর্যন্ত কমাবে। যদি স্যামের পরের বিল $12 হয়, বাকি $8 পরবর্তীতে ব্যবহারযোগ্য ক্রেডিট হিসেবে থাকে, এবং কোথা থেকে এসেছে তা স্পষ্ট রেকর্ড থাকে।

সাফল্য কেবল "আরো রেফারেল" নয়। এটা প্রত্যাশাযোগ্য বিলিং এবং কম মতবিরোধ। আপনি জানবেন এটা কাজ করছে যখন ক্রেডিট ব্যালান্স সহজে ব্যাখ্যা করা যায়, ইনভয়েস লেজারের সাথে মেলে, এবং সাপোর্ট অনুমান বা ম্যানুয়াল ফিক্স ছাড়া প্রশ্নের উত্তর দিতে পারে।

তৈরি করার আগে সিদ্ধান্ত নেওয়ার নিয়মগুলো

রেফারেল প্রোগ্রাম সহজ শোনায় যতক্ষণ না প্রথম টিকিট আসে: "কেন আমি ক্রেডিট পাইনি?" বেশিরভাগ কাজ নীতি বোঝায়, কোড নয়।

ট্রিগার দিয়ে শুরু করুন। "Invite sent" খুব আগেই, "signed up" সহজেই গেম করা যায়। সাধারণ সমাধান হলো একটি "qualified conversion": ইমেইল ভেরিফাইড + প্রথম পেইড ইনভয়েস, বা ট্রায়ালের পর প্রথম সফল পেমেন্ট। একটি ট্রিগার বেছে নিন এবং ধারাবাহিক রাখুন যাতে আপনার লেজার পরিষ্কার থাকে।

পরবর্তী, মান ও সীমা নির্ধারণ করুন। ক্রেডিট বাস্তব মনে হওয়া উচিত, কিন্তু এটা যেন সীমাহীন ডিসকাউন্ট মেশিনে পরিণত না হয়। নির্ধারণ করুন আপনি কি ফ্ল্যাট অ্যামাউন্ট দেবেন (যেমন $20 ক্রেডিট) বা বিলের একটি শতাংশ দেবেন, এবং এমনভাবে ক্যাপ করুন যাতে এক বাক্যে বোঝানো যায়।

ভবিষ্যতে বিভ্রান্তি প্রতিরোধকারী সিদ্ধান্তগুলো হলো:

কোন ইভেন্ট যোগ্য করে (প্রথম পেমেন্ট, প্রথম রিনিউয়াল ইত্যাদি)
কতটা ক্রেডিট দেয়া হবে (ফ্ল্যাট বনাম শতাংশ, এবং ভিন্ন প্ল্যানে পার্থক্য থাকলে তা)
ক্যাপ (প্রতি রেফারেল, প্রতি মাস, বা লাইফটাইম)
কোন প্ল্যান এবং ডিল টাইপ গণ্য হবে
ক্রেডিটের মেয়াদ শেষ হবে কি না

যোগ্যতা নিয়ম প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ। যদি কেবল পেইড প্ল্যানই গণ্য হয়, তা জানিয়ে দিন। যদি কিছু অঞ্চল বাদ থাকবে (ট্যাক্স, কমপ্লায়েন্স, প্রচার), তা জানিয়ে দিন। যদি বার্ষিক প্ল্যান যোগ্য কিন্তু মাসিক নয়, তা জানিয়ে দিন। Koder.ai মত প্ল্যাটফর্মে যেখানে একাধিক টিয়ার আছে, আগে থেকে নির্ধারণ করে নিন যে ফ্রি-টু-প্রো আপগ্রেড যোগ্য কিনা, এবং এন্টারপ্রাইজ কনট্রাক্ট ম্যানুয়ালি হ্যান্ডল করা হবে কিনা।

ইউজার-ফেসিং শব্দগুলো শিপ করার আগে লিখে ফেলুন। যদি আপনি প্রতিটি নিয়ম দুইটা ছোট বাক্যে ব্যাখ্যা করতে না পারেন, ব্যবহারকারীরা ভুল ধারণা করবে। সাবলীল কিন্তু কঠোর রাখুন: "We may withhold credits for suspicious activity" বেশি পরিষ্কার (এবং কম বিরক্তিকর) একটি দীর্ঘ হুমকির তালিকার চেয়ে।

ইনভাইট থেকে qualified conversion পর্যন্ত রেফারেল ট্র্যাক করার পদ্ধতি

একটা প্রাইমারি আইডেন্টিফায়ার বেছে নিন এবং বাকি সবকে সাপোর্টিং প্রমাণ হিসেবে বিবেচনা করুন। সবচে পরিষ্কার অপশনগুলো হলো রেফারেল লিঙ্ক টোকেন (শেয়ার করা সহজ), একটি শর্ট কোড (টাইপ করা সহজ), এবং নির্দিষ্ট ইমেইলে পাঠানো ইনভাইট (ডাইরেক্ট ইনভাইটের জন্য সেরা)। একটি সোর্স-অফ-ট্রুথ বেছে নিন যাতে অ্যাট্রিবিউশন voorsis বলেই থাকে।

সে আইডেন্টিফায়ার যত দ্রুত সম্ভব ধরুন এবং পুরো যাত্রায় বহন করুন। লিঙ্ক টোকেন সাধারণত ল্যান্ডিং পেইজে ধরা হয়, প্রথম-পার্টি স্টোরেজে রাখা হয়, তারপর সাইনআপে পুনঃজমা করা হয়। মোবাইলের জন্য, অ্যাপ ইনস্টল ফ্লো-এ পাস করুন যখন পারবেন, কিন্তু ধরে নেবেন কখনো কখনো এটা হারিয়ে যাবে।

একটি ছোট ইভেন্ট সেট ট্র্যাক করুন যা আপনার ব্যবসার নিয়মের সাথে মেলে। যদি আপনার লক্ষ্য "এটা পেইং কাস্টমার হল কি না" হয় (শুধু "ক্লিক করলো" নয়), একটি ন্যূন্যতম সেট যথেষ্ট:

referral_click (token দেখা গেছে)
account_signup (নতুন ব্যবহারকারী তৈরি হয়েছে)
account_verified (ইমেইল/ফোন ভেরিফাইড)
first_paid_invoice (প্রথম সফল পেমেন্ট)
qualification_locked (conversion গ্রহণ করা হয়েছে এবং আর পরিবর্তন হবে না)

ডিভাইস বদল এবং ব্লকড কুকি স্বাভাবিক। ক্রিপি ট্র্যাকিং ছাড়া সেগুলো হ্যান্ডল করতে, সাইনআপের সময় একটি claim ধাপ যোগ করুন: যদি ইউজার টোকেন নিয়ে আসে, তা নতুন অ্যাকাউন্টের সাথে জুড়ুন; নাহলে অনবোর্ডিং-এ একবার একটি শর্ট রেফারেল কোড দেওয়ার অপশন দিন। যদি দুটোই থাকে, প্রথম ধরা মানটিকেই প্রাইমারি রাখুন এবং অন্যটিকে সেকেন্ডারি প্রমাণ হিসেবে সংরক্ষণ করুন।

সবশেষে, প্রতিটি রেফারেলের জন্য সাপোর্ট এক মিনিটে পড়তে পারে এমন একটি সহজ টাইমলাইন রাখুন: রেফারার, রেফারড অ্যাকাউন্ট (জানা গেলে), বর্তমান স্ট্যাটাস, এবং শেষ গুরুত্বপূর্ণ ইভেন্টের টাইমস্ট্যাম্প। যখন কেউ জিজ্ঞেস করে "কেন আমি ক্রেডিট পাইনি?" আপনি বলতে পারবেন বাস্তব তথ্য: "সাইনআপটি হয়েছে, কিন্তু প্রথম পেইড ইনভয়েস হয়নি," অনুমান না করে।

এমন একটি ডেটা মডেল যা পড়তে ও ডিবাগ করতে সহজ

রেফারেল প্রোগ্রামগুলি সাধারণত তখন ভেঙে যায় যখন ডেটা মডেল অস্পষ্ট। সাপোর্ট জিজ্ঞেস করে "কে কাকে রেফার করেছে?" বিলিং জিজ্ঞেস করে "ক্রেডিটটি জারি করা হয়েছে কি?" যদি আপনি লগ খুঁড়ে না বের করে উত্তর দিতে না পারেন, মডেলটা টাইট করা দরকার।

রেফারেল সম্পর্ককে প্রথম-শ্রেণীর রেকর্ড হিসেবে সংরক্ষণ করুন, ক্লিক থেকে আঁচ করা অনুমান নয়।

সংরক্ষণ করার জন্য কোর রেকর্ড

একটি সাদামাটা, ডিবাগযোগ্য সেটআপ দেখতে এরকম:

referrals: id, referrer_user_id, referred_user_id, created_at, source (invite link, coupon, manual), status, status_updated_at
referral_attribution (বিকল্প): referral_id, invite_code_id or 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, পূর্ণ ইউজার-এজেন্ট, নাম—যেগুলো পরে আপনি পস্তাবেন—সেগুলো এড়িয়ে চলা বা মাত্রা-হ্যাশ হিসেবে সংরক্ষণ করুন এবং স্পষ্ট রিটেনশন পলিসি রাখুন।

স্ট্যাটাসগুলো স্পষ্ট ও পারস্পরিকভাবে একচেটিয়া রাখুন: pending (সাইন আপ আছে, এখনও যোগ্য নয়), qualified (নিয়ম পূরণ করেছে), credited (ক্রেডিট জারি করা হয়েছে), rejected (চেক ফেল করেছে), reversed (রিফান্ড/চার্জব্যাকের পরে ক্রেডিট উঠিয়ে নেওয়া)।

ডাবল-কাউন্টিং প্রতিরোধের নিয়ম

একবার প্রাধান্য নির্ধারণ করুন, তারপর ডাটাবেসে এটা জোরদার করুন যাতে অ্যাপ ভুলবশত দুটি বার ক্রেডিট না দেবে। ন্যূনতম:

প্রতিটি রেফারড অ্যাকাউন্টে কেবল একটি রেফারার থাকবে (unique on referred_user_id)
প্রতিটি রেফারড অ্যাকাউন্টে কেবল একটি রেফারেলই credited থাকতে পারে
যদি বহু টাচ ঘটে, প্রথম-টাচ বা শেষ-টাচ বেছে নিন এবং সেই referral_id সংরক্ষণ করুন

যদি আপনি টিম সাপোর্ট করেন, নির্ধারণ করুন রেফারেল কি পার্সোনাল সাইনআপে লাগবে না কি ওয়ার্কস্পেস ক্রিয়েশনে। দুইটাই করার চেষ্টা করবেন না। কাজ করার উপায় হলো রেফারেলকে ইউজার অ্যাকাউন্টের সাথে টায় করে রাখা, এবং যোগ্যতা চেক করতে দেখা হবে সেই ইউজার (বা তাদের ওয়ার্কস্পেস) পেইং সাবস্ক্রাইবার হয়েছে কি না।

ক্রেডিট লেজার মুলনীতি: সঠিক, অডিটযোগ্য, ব্যাখ্যাযোগ্য

Ship supportable referral tracking

Add pending-qualified-credited-reversed statuses and a support-ready referral timeline.

Try Free

কম বিড়ম্বনা ও কম সাপোর্ট টিকিট চাইলে একটি লেজার ব্যবহার করুন, একক "ক্রেডিট ব্যালান্স" ফিল্ড নয়। একটি ব্যালান্স সংখ্যাকে ওভাররাইট করা যায়, রাউন্ড করা যায়, বা দুবার আপডেট করা যায়। লেজার হলো এন্ট্রির ইতিহাস যা সবসময় যোগ করা যায়।

এন্ট্রি টাইপগুলো সীমিত ও নির্দিষ্ট রাখুন: earn (grant), spend (invoice-এ প্রয়োগ), expire, reversal (clawback), এবং manual adjustment (নোট ও অনুমোদকের সাথে)।

প্রতিটি এন্ট্রি ইঞ্জিনিয়ার ও সাপোর্ট উভয়ের জন্য পড়ার যোগ্য হওয়া উচিত। ধারাবাহিক ফিল্ড রাখুন: amount, credit type (যদি ক্রেডিট নকদ না হয় তাহলে "USD" বলা ঠিক নয়), reason text, source event (যেমন referral_signup_qualified), source IDs (user, referred user, subscription বা invoice), timestamps, এবং created_by (system বা admin)।

Idempotency প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ। একই webhook বা ব্যাকগ্রাউন্ড জব দুইবার চলতে পারে। প্রতিটি সোর্স ইভেন্টের জন্য একটি ইউনিক idempotency key দাবী করুন যাতে আপনি ডাবল ক্রেডিট ছাড়া নিরাপদে retry করতে পারেন।

ইউজারকে ব্যাখ্যা করাও জরুরি। যখন কেউ জিজ্ঞেস করে "কেন আমি 20 ক্রেডিট পেলাম?" আপনি দেখাতে পারবেন কোন রেফারেল এটা ট্রিগার করেছিল, কখন পোস্ট করা হয়েছিল, মেয়াদ আছে কি না, এবং পরে কোন reversal হয়েছে কি না। যদি বন্ধু আপগ্রেড করে, আপনি সেই আপগ্রেড ইভেন্টের সাথে টায় একটি earn এন্ট্রি যোগ করবেন। পেমেন্ট রিফান্ড হলে reversal এন্ট্রি যোগ করবেন যা রিফান্ড ইভেন্টের সাথে যুক্ত।

সেলফ-রেফারেল ও সাধারণ প্রতারণা প্রতিরোধ (কঠোর না হয়ে)

ধারণা রাখুন বেশিরভাগ মানুষ সত্্য এবং কিছু লোক সহজ ট্রিক ব্যবহার করবে। লক্ষ্য হলো সহজ প্রতারণা থামানো, নিয়মগুলো পরিষ্কার রাখা, এবং সত্যিকারের গ্রাহকদের ব্লক না করা যারা একই ওয়াই-ফাই বা পরিবার কার্ড শেয়ার করে।

সহজ ও যুক্তিযুক্ত ব্লক দিয়ে সেলফ-রেফারেল থামান

প্রথমে সেই কঠোর ব্লকগুলো রাখুন যেগুলো আপনি যুক্তিসহ ব্যাখ্যা করতে পারবেন। রেফারার ও রেফারড একই ব্যক্তি স্পষ্ট হলে ক্রেডিট দেবেন না—যেমন একই user ID, একই verified email, বা একই payment method fingerprint। ইমেইল ডোমেন নিয়ম সাহায্য করতে পারে, কিন্তু খুব বিস্তৃত ব্লকিং সৎ টিমকে ক্ষতিগ্রস্ত করতে পারে।

তারপর লুপ ও মাস রেজিস্ট্রেশন সনাক্তকরণের জন্য হালকা ডিটেকশন যোগ করুন। প্রথম দিনে নিখুঁত ফ্রড স্কোরিং দরকার নেই। কিছু শক্ত সিগনাল বেশিরভাগ প্রতারণা ধরবে: একই ডিভাইস থেকে স্বল্প সময়ে অনেক সাইনআপ, একই IP রেঞ্জ থেকে মিনিটের মধ্যে বারবার ব্যবহার, একই কার্ডের একাধিক নতুন অ্যাকাউন্টে ব্যবহার, অনেক অ্যাকাউন্ট যেগুলো ইমেইল ভেরিফাই করে না, বা ক্রেডিট প্রয়োগের পরে দ্রুত ক্যানসেল-এবং-রিসাবস্ক্রাইব প্যাটার্ন।

ক্রেডিট ব্যবহারের আগে একটি যোগ্যতামূলক অ্যাকশন আবশ্যক করুন (উদাহরণ: ভেরিফায়েড ইমেইল + পেইড ইনভয়েস)। এটা বট ও ফ্রি-টিয়ার চর্নকে ক্রেডিট জেনারেট করা থেকে রোধ করে।

সাধারণ ব্যবহারকারীকে শাস্তি না দিয়ে প্রতারণা লাগাম দিন

রেফারেল লিংক ও রিডেম্পশনের চারপাশে রেট লিমিট ও কুলডাউন যোগ করুন, কিন্তু প্রয়োজন না হলে তা চুপ করে রাখুন। যদি একটি লিঙ্ক এক ঘণ্টায় একই নেটওয়ার্ক থেকে 20 বার ব্যবহার হয়, পুরস্কার সাময়িকভাবে থামান এবং ফ্ল্যাগ দিন।

আপনি যখন হস্তক্ষেপ করেন, অভিজ্ঞতাকে শান্ত রাখুন। ক্রেডিটগুলোকে pending হিসেবে চিহ্নিত করুন যতক্ষণ না পেমেন্ট ক্লিয়ার করে, দেরির কারণ সহজ ভাষায় দেখাও (বালত করা বাদে), সাপোর্টের সাথে যোগাযোগ করার সহজ উপায় দিন, এবং এজ কেসগুলো ম্যানুয়াল রিভিউতে পাঠান অটো-ব্যানের পরিবর্তে।

উদাহরণ: একটি স্টার্টআপ টিম একই অফিস IP শেয়ার করে। তিন সহকর্মী একই দিনে একই রেফারেলের মাধ্যমে সাইন আপ করলে, যোগ্য পেমেন্ট + একটি বেসিক কুলডাউন থাকলে তাদের ইনভয়েস পেমেন্টের পরে ক্রেডিট মিলবে; বট-সদৃশ ঝড়গুলো রিভিউ জন্য হোল্ড হবে।

বাস্তব জীবনের জটিলতা: রিফান্ড, রিভার্সাল, এবং অ্যাকাউন্ট পরিবর্তন

রেফারেল প্রোগ্রামগুলো তখনই জটিল মনে হয় যখন টাকা ভুল দিকে যায়: রিফান্ড, চার্জব্যাক, ইনভয়েস বাতিল, বা অ্যাকাউন্ট মালিকানা বদল। এগুলো সামনে থেকেই ডিজাইন করলে আপনি রাগান্বিত ব্যবহারকারী ও দীর্ঘ সাপোর্ট থ্রেড এড়াতে পারবেন।

কখন ক্রেডিট উল্টানো হবে (এবং কীভাবে)

ক্রেডিটকে এমন কিছু হিসেবে বিবেচনা করুন যা আপনি পেইড আউটকামের ভিত্তিতে উপার্জন করেন, শুধু সাইনআপ নয়। তারপর বিলিং ইভেন্টের সাথে জুড়ে একটি রিভার্সাল পলিসি নির্ধারণ করুন।

একটি নিয়ম সেট যা সাপোর্ট সহজে ব্যাখ্যা করতে পারে:

যদি মূল পেইড ইনভয়েস সম্পূর্ণ রিফান্ড বা চার্জব্যাক হয়, তাহলে সেই ইনভয়েসের জন্য প্রদত্ত রেফারেল ক্রেডিট রিভার্স করুন।
যদি ইনভয়েস পেমেন্ট ক্্্যাপচার হওয়ার আগে বাতিল করা হয়, ক্রেডিট দেবেন না।
যদি ক্রেডিট আগে দেওয়া হয়ে থাকে (উদাহরণ: "invoice paid"-এ), রিভার্সালগুলো স্বয়ংক্রিয় হওয়া উচিত এবং একটি পরিষ্কার ট্রেইল থাকা উচিত।

পার্শিয়াল রিফান্ডেই টিমগুলো আটকে পড়ে। একটি পদ্ধতি বেছে নিন এবং ধারাবাহিক থাকুন: অনুপাতিক রিভার্সাল (যেমন 30% রিফান্ড হলে 30% ক্রেডিট রিভার্স) বা সম্পূর্ণ রিভার্সাল (যেকোন রিফান্ডে পুরো ক্রেডিট রিভার্স)। অনুপাতিক বেশি ন্যায্য কিন্তু টেস্ট করা কঠিন; সম্পূর্ণ রিভার্সাল সহজ কিন্তু কড়া লাগতে পারে।

ট্রায়াল-টু-পেইড ট্রানজিশনগুলোও স্পষ্ট করা দরকার। একটি সাধারণ পন্থা হলো ট্রায়ালে ক্রেডিট pending রাখা, তারপর প্রথম সফল পেইড ইনভয়েস ক্লিয়ার হলে (অপশনালি একটি ছোট গ্রেস পিরিয়ডের পরে) তা লক করা।

অ্যাকাউন্ট মার্জ ও মালিকানা পরিবর্তন

লোকেরা ইমেইল বদলায়, অ্যাকাউন্ট মার্জ করে, বা পার্সোনাল থেকে টিম ওয়ার্কস্পেসে চলে যায়। সিদ্ধান্ত নিন কি ব্যক্তির সাথে চলে এবং কি পেইং অ্যাকাউন্টের সাথে থাকে। যদি ওয়ার্কস্পেস সাবস্ক্রাইবার হয়, ক্রেডিটগুলো প্রায়শই সেই ওয়ার্কস্পেসের জন্য থাকে, কোন সদস্যের নয় যে পরে চলে যেতে পারে।

আপনি যদি অ্যাকাউন্ট মার্জ বা টিম মালিকানা ট্রান্সফার সাপোর্ট করেন, অতীত কাহিনি পুনরায় লেখার বদলে একটি অ্যাডজাস্টমেন্ট ইভেন্ট রেকর্ড করুন। প্রতিটি রিভার্সাল বা ম্যানুয়াল কারেকশন-এ একটি সাপোর্ট-ফ্রেন্ডলি নোট থাকা উচিত, যেমন "Chargeback on invoice 10482" বা "Workspace owner transfer approved by support." Koder.ai-এর মতো প্ল্যাটফর্মে যেখানে ক্রেডিট সাবস্ক্রিপশনে প্রযোজ্য, সেই নোটগুলোই এক-লুকআপে "কেন আমার ক্রেডিট বদলেছে?" জবাব দেয়।

সাবস্ক্রিপশনে ক্রেডিট প্রয়োগ পরিষ্কারভাবে

Go from plan to deployment

Deploy a working referral flow and validate it with real invoices and reversals.

Deploy App

ট্র্যাক করা কঠিন নয়; কঠিন অংশ হলো ক্রেডিটগুলো রিনিউয়াল, আপগ্রেড, ডাউনগ্রেড এবং ট্যাক্সে অভিন্নভাবে আচরণ করা।

প্রথমে সিদ্ধান্ত নিন ক্রেডিট কোথায় ব্যবহার করা যাবে। কিছু দল কেবল পরের নতুন ইনভয়েসে ক্রেডিট প্রয়োগ করে। অন্যরা যেকোন ওপেন (অপ্রদত্ত) ইনভয়েস ঢাকতে দেয়। একটি নিয়ম বেছে নিন এবং UI-তে দেখান যাতে মানুষ আশ্চর্য না হয়।

পরের ধাপ—অপারেশনের অর্ডার নির্ধারণ করুন। একটি প্রত্যাশাযোগ্য পদ্ধতি হলো: সাবস্ক্রিপশন চার্জ হিসাব করুন (প্রোরেশন সহ), ডিসকাউন্ট প্রয়োগ করুন, ট্যাক্স গণনা করুন, তারপর সর্বশেষে ক্রেডিট প্রয়োগ করুন। ক্রেডিট শেষেই প্রয়োগ করলে ট্যাক্স লজিক ধারাবাহিক থাকে এবং বিতর্ক কমে যে ক্রেডিট ট্যাক্সযোগ্য পরিমাণ কমাচ্ছে কি না। আপনার নিয়ম যদি ভিন্ন হয়, তা ডকুমেন্ট করুন এবং টেস্ট করুন।

প্রোরেশন হলো যেখানে বিলিং বাগ সাধারণত দেখা যায়। কেউ মাঝমাসে আপগ্রেড করলে একটি প্রোরেশন লাইন আইটেম (চার্জ বা ক্রেডিট) তৈরি করুন এবং এটাকে যে কোনো লাইনে আইটেমের মতো বিবেচনা করুন। তারপর রেফারেল ক্রেডিট ইনভয়েস টোটালে প্রয়োগ করুন, নির্দিষ্ট লাইনে নয়।

ইনভয়েস নিয়মগুলো কঠোর রাখুন:

ক্রেডিট কাস্টমারের দায় কমায়, কিন্তু কখনো $0’র নিচে নামতে দেয় না।
অব্যবহৃত ক্রেডিট ভবিষ্যৎ ইনভয়েসের জন্য থাকে।
ক্রেডিট নির্দিষ্ট ক্রমে প্রয়োগ করুন (পুরনোগুলো আগে) যাতে ফলাফল পুনরাবৃত্তিমূলক হয়।
যদি ইনভয়েস বাতিল বা রিফান্ড হয়, কেবল সেই ইনভয়েসে ব্যবহৃত ক্রেডিট উল্টান।

উদাহরণ: কেউ মাঝমাসে আপগ্রেড করে এবং $12 প্রোরেশন চার্জ পায়। ডিসকাউন্ট ও ট্যাক্সের পরে ইনভয়েস টোটাল $32 হয়। যদি তাদের কাছে $50 রেফারেল ক্রেডিট থাকে, আপনি $32 প্রয়োগ করবেন, ইনভয়েস Due $0 হবে, এবং বাকী $18 পরের রিনিউয়ালে থাকবে।

স্টেপ-বাই-স্টেপ ইমপ্লিমেন্টেশন প্ল্যান (MVP থেকে v1)

রেফারেল প্রোগ্রামকে একটি ছোট বিলিং ফিচার হিসেবে বিবেচনা করুন, মার্কেটিং উইজেট হিসেবে নয়। লক্ষ্য হলো বিরক্তিকর ধারাবাহিকতা: প্রতিটি ক্রেডিটের একটি কারণ, টাইমস্ট্যাম্প, এবং পরের ইনভয়েসে যাওয়ার পথ থাকবে।

MVP (দিবসে নয়, সপ্তাহে শিপ করুন)

একটি কনভার্শন ইভেন্ট এবং একটি ক্রেডিট নিয়ম বেছে নিন। উদাহরণ: আমন্ত্রিত ব্যবহারকারী কেবল তখনই যোগ্য যখন তারা পেইং সাবস্ক্রাইবার হয় এবং তাদের প্রথম পেমেন্ট ক্লিয়ার হয়।

MVP এর আশেপাশে একটি end-to-end পথ বানান: সাইনআপে রেফারেল টোকেন বা কোড ক্যাপচার করুন, পেমেন্ট সফল হলে (না যে ব্যবহারকারী কার্ড দিচ্ছে) যোগ্যতা চালান, একটি লেজার এন্ট্রি লিখুন ইউনিক idempotency কী সহ, এবং পরের ইনভয়েসে ক্রেডিটগুলো ধারাবাহিক ক্রমে প্রয়োগ করুন।

এখনই সোর্স-অফ-ট্রুথ ঠিক করুন। আপনার বিলিং প্রোভাইডার কি সোর্স-অফ-ট্রুথ হবে এবং আপনার অ্যাপ সেটি মিরর করবে, নাকি আপনার ইনটারনাল লেজার সোর্স-অফ-ট্রুথ হবে এবং বিলিং কেবল "এই ইনভয়েসে X ক্রেডিট প্রয়োগ করুন" বলে? দুটো মিশাতে গেলে সাধারণত "আমার ক্রেডিট হারিয়ে গেছে" টিকিট তৈরি হয়।

v1 (সাপোর্টেবল করে তুলুন)

আরও রেফারেল নিয়ম যোগ করার আগে অ্যাডমিন টুল যোগ করুন। সাপোর্টকে ইউজার, রেফারেল কোড, এবং ইনভয়েস দিয়ে সার্চ করতে দিতে হবে, তারপর একটি টাইমলাইন দেখবে: invite, signup, qualification, credits granted, credits spent, এবং reversals। ম্যানুয়াল অ্যাডজাস্টমেন্টগুলোও দেখান এবং সবসময় একটি শর্ট নোট চাইুন।

তারপর ইউজার UX যোগ করুন: একটি রেফারেল পেইজ, প্রতিটি ইনভাইটের স্ট্যাটাস লাইন (pending, qualified, credited), এবং এমন একটি ক্রেডিট হিস্ট্রি যা ইনভয়েসের সাথে মিলে।

শেষে মনিটরিং যোগ করুন: রেফারেলে হঠাৎ স্পাইক, উচ্চ রিভার্সাল রেট (রিফান্ড বা চার্জব্যাক), এবং অস্বাভাবিক প্যাটার্ন (একই ডিভাইস বা পেমেন্ট মেথড শেয়ার করা) সম্পর্কে অ্যালার্ট দিন। এটি এ্যাবিউজ কন্ট্রোলগুলো শক্ত রাখে বরং সাধারণ ব্যবহারকারীকে শাস্তি করে না।

উদাহরণ: কেউ Koder.ai রেফারেল শেয়ার করলে তাদের ক্রেডিট কেবল প্রথম সফল পেইড সাবস্ক্রিপশনের পরে দেখাবে, এবং সেই ক্রেডিট পরের রিনিউয়ালে স্বয়ংক্রিয়ভাবে কমবে, কপোন নয়।

সাধারণ ভুল যা বিলিং বাগ ও সাপোর্ট লোড বাড়ায়

Test messy billing cases

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

Plan It

অধিকাংশ রেফারেল প্রোগ্রাম মার্কেটিংয়ে নয়, বিলিংয়ে ব্যর্থ হয়। দ্রুত টিকিট তৈরি করার দ্রুত উপায় হলো ক্রেডিট অনিশ্চিত করে তোলা: ব্যবহারকারীরা বুঝতে পারে না কেন তারা পেল, কখন তা প্রয়োগ হবে, বা কেন ইনভয়েস আলাদা।

একটি সাধারণ ফাঁদ হলো নিয়ম স্পষ্ট না করে বিল্ড করা। যদি "qualified referral" অস্পষ্ট হয় (ট্রায়াল শুরু, প্রথম পেমেন্ট, 30 দিন ধরে পেইড প্ল্যান), আপনি কেস বাই কেস ক্রেডিট নিয়ে আলোচনায় পড়ে যাবেন এবং রিফান্ড দিয়ে মানুষকে সন্তুষ্ট করতে হবে।

আরেকটি সাধারণ সমস্যা হলো একটিবার পরিবর্তনশীল "credit balance" ফিল্ড ব্যবহার করা। এটা সহজ দেখায় যতক্ষণ না রিট্রাই, রিফান্ড, প্ল্যান চেঞ্জ, বা ম্যানুয়াল অ্যাডজাস্টমেন্ট হয়। তখন সংখ্যাটা ঘুরে যায় এবং আপনি ব্যাখ্যা করতে পারেন না কিভাবে পৌঁছেছেন।

Idempotencyও বরাবর উপেক্ষিত হয়। পেমেন্ট প্রোভাইডাররা ওয়েবহুক retry করে, ওয়ার্কাররা জব retry করে, ব্যবহারকারী ডাবল-ক্লিক করে। যদি আপনার "award credit" অ্যাকশন idempotent না হয়, আপনি ডুপ্লিকেট ক্রেডিট তৈরী করবেন এবং কেবল তখনই লক্ষ্য করবেন যখন রেভিনিউ ভুল দেখাবে।

ক্রেডিট ম্যাথও ঠিক না থাকতে পারে যদিও মোট ঠিক আছে। ক্রেডিট ট্যাক্সের আগে প্রয়োগ করলে বা প্রোরেশন নিয়ম উপেক্ষা করলে ইনভয়েসগুলি পেমেন্ট সিস্টেমের প্রত্যাশার সাথে মেলে না। ফলে রিসিপ্ট মিসম্যাচ, ব্যর্থ পেমেন্ট, এবং কষ্টকর রিকনসিলিয়েশন হয়।

ফ্রড চেকও অত্যন্ত কঠোর হলে সমস্যা। IP, ডিভাইস, বা ডোমেন দ্বারা ব্লক করে রিভিউ পথ ছাড়া, বাস্তব রেফারেল থামবে (রুমমেট, সহকর্মী, টিম একই নেটওয়ার্কে) এবং অচুপে গ্রোথ ক্ষতিগ্রস্ত হবে।

দেখার জন্য পাঁচটি রেড ফ্ল্যাগ:

কোয়ালিফিকেশন নিয়ম শুধুমাত্র কোডে আছে এবং অ্যাডমিন/সপোর্ট ভিউতে দেখা যায় না।
ক্রেডিটগুলোর ইউনিক ইভেন্ট কী নেই (invite_id, conversion_id) ডুপ্লিকেট প্রতিরোধ করার জন্য।
"Balance" এক ফিল্ড ওভাররাইট করে সংরক্ষণ করা হয়েছে, লেজার এন্ট্রি যোগ করার বদলে।
ইনভয়েসে ক্রেডিট প্রয়োগের অর্ডার আপনার বিলিং প্রোভাইডারের প্রত্যাশার থেকে আলাদা (ট্যাক্স, প্রোরেশন, ডিসকাউন্ট)।
ফ্রড প্রতিরোধে কোনো আপিল পাথ বা ম্যানুয়াল ওভাররাইড নেই।

উদাহরণ: একটি Koder.ai Pro ইউজার মাঝমাসে আপগ্রেড করে, রেফারেল ক্রেডিট পায়, তারপর ডাউনগ্রেড করে। যদি আপনার সিস্টেম একটি সিঙ্গল ব্যালান্স ফিল্ড ব্যবহার করে এবং ক্রেডিটকে প্রোরেশনের আগে প্রয়োগ করে, পরের ইনভয়েস গোল করে উঠতে পারে যদিও মোট মূল্য কাছাকাছি থাকে। একটি লেজার + নির্দিষ্ট প্রয়োগ অর্ডার এটা দীর্ঘ সাপোর্ট থ্রেডে পরিণত হতে দেয় না।

দ্রুত চেকলিস্ট, একটি সহজ উদাহরণ, এবং পরবর্তী ধাপ

শিপ করার আগে কিছু চেক চালান যা বেশিরভাগ বিলিং ও সাপোর্ট সমস্যা ধরবে।

এক রেফারার প্রতি অ্যাকাউন্ট: একবার অ্যাট্রিবিউট করা হলে তা নীরবভাবে পরিবর্তন করবেন না।
পরিষ্কার কোয়ালিফিকেশন: ঠিক ইভেন্ট নির্ধারণ করুন যা ক্রেডিট আर्जন করে (উদাহরণ: প্রথম সফল পেইড ইনভয়েস সফল এবং রিফান্ড না)।
লেজার, ব্যালান্স নয়: প্রতিটি ক্রেডিট ও ডেবিট এন্ট্রি হিসেবে সংরক্ষণ করুন।
রিভার্সাল আছে: রিফান্ড, চার্জব্যাক এবং বাতিল ট্রায়াল রিভার্সিং এন্ট্রি তৈরি করে।
অ্যাডমিন অ্যাডজাস্টমেন্ট লগ করা হয়: ম্যানুয়াল গ্রান্ট ও রিমুভালগুলো লেজার এন্ট্রির মত দেখায় এবং একটি কারণ থাকে।

উদাহরণ: মায়া নোয়াকে আমন্ত্রণ দেয়। নোয়া মায়ার ইনভাইট থেকে সাইন আপ করে, ট্রায়াল করে, পরে Pro-এ আপগ্রেড করে এবং $30 পে করে। আপনার সিস্টেম সেই ইনভয়েসকে qualified চিহ্নিত করে এবং মায়ার জন্য একটি ক্রেডিট এন্ট্রি তৈরি করে (উদাহরণ: $10 সাবস্ক্রিপশন ক্রেডিট)।

মায়ার পরের রিনিউয়ালে, তার ইনভয়েস সাবটোটাল $30। আপনার বিলিং ধাপ $10 তার উপলব্ধ ক্রেডিট থেকে প্রয়োগ করে, ইনভয়েস $30 subtotal, -$10 credit, এবং $20 due দেখায়। মায়ার লেজারে একটি earn (+$10) এন্ট্রি এবং একটি spend (-$10 applied to invoice #1234) এন্ট্রি থাকবে।

যদি পরে নোয়া প্রথম পেমেন্টের জন্য রিফান্ড চান, সিস্টেম একটি reversal এন্ট্রি যোগ করবে যা মায়ার উপার্জিত ক্রেডিট সরিয়ে দেয় (বা একটি মেলানো ডেবিট পোস্ট করে)। যদি কোনো ক্রেডিট ইতিমধ্যে ব্যবহার হয়ে থাকে, পরের ইনভয়েসে পার্থক্য চার্জ করা হবে, ইতিহাস পুনরায় লেখার বদলে।

দুইটি পরবর্তী ধাপ যা বিশ্বাস ভাঙা ছাড়া গতিবেগ বজায় রাখে:

attribution, qualification, ledger entries, application to invoices, এবং reversals সহ পুরো ফ্লোটি একটি সংক্ষিপ্ত পরিকল্পনা ডকুমেন্টে প্রটোটাইপ করুন।
স্যান্ডবক্সে নির্দিষ্ট সিনারিওগুলি টেস্ট করুন: ট্রায়াল-টু-পেইড, ক্রেডিট ব্যবহারের পরে রিফান্ড, মাঝখানে আপগ্রেড ও ডাউনগ্রেড, এবং একটি অ্যাডমিন অ্যাডজাস্টমেন্ট।

যদি আপনি দ্রুত এগোতে চান আবারও বিলিং লজিক হারিয়ে না ফেলতে, Koder.ai Planning Mode, স্ন্যাপশট এবং রোলব্যাক নিয়ে সাহায্য করে; এতে আপনি রেফারেল ফ্লো যতক্ষণ পর্যন্ত ইনভয়েস ম্যাথ স্থির না হয় পর্যবেক্ষণ করে ইটারেট করতে পারেন। পুরোটা প্ল্যাটফর্মের ভিতরে koder.ai-তে করতে পারবেন, তারপর কোড এক্সপোর্ট করবেন যখন প্রস্তুত হবেন।

সাধারণ প্রশ্ন

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
rejected: failed checks or ineligible
reversed: credit clawed back after refund/chargeback

Keep a timestamp for the last status change.

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
Apply credits oldest-first so results are repeatable

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.