بیشتر پلتفرمهای صورتحساب خیلی زود شما را مجبور به انتخاب میکنند: پیشپرداخت یا پسپرداخت، اشتراک یا پرداخت به ازای مصرف، سلفسرویس یا سازمانی. یک مدل را انتخاب میکنید، منتشر میکنید، و استثناها را بعداً وصله میکنید: محصول جدا در Stripe، اعتبار دستی، و صفحهگسترده تیم فروش.
اما پلتفرمهای واقعی اینقدر ساده و یکدست نیستند.
توسعهدهنده مستقل کیف پول و شارژ با کارت میخواهد. تیم در حال رشد، سهمیه ماهانه قابل پیشبینی میخواهد. مشتری سازمانی، فاکتور net-60 و سقف اعتبار توافقشده میخواهد؛ اما همان مشتری هم ممکن است در هفته راهاندازی از سهمیه عبور کند.
فینو اینها را «طرحهای رقیب» نمیبیند. همه آنها منابع پرداخت روی یک حساب هستند و در هر درخواست، با همان یک کلید API، بهصورت خودکار انتخاب میشوند.
سه منبع پرداخت
۱. اشتراک سهمیهای
مشتری برای یک دوره صورتحساب، یک مقدار ثابت میخرد: فراخوانی API، توکن، بایت یا میلیثانیه. هر درخواست موفق از سهمیه باقیمانده طرح کم میکند.
مناسب برای: طرحهای استاندارد، تیمی و سازمانی؛ جایی که خریدار سقف هزینه قابل پیشبینی میخواهد.
رفتار: وقتی سهمیه تمام شد، فینو سرویس را فوراً قطع نمیکند. سراغ منبع بعدی در ترتیب اولویت میرود؛ مثلاً کیف پول و بعد اعتبار. اگر هیچ منبعی باقی نمانده باشد، 402 برمیگرداند.
۲. کیف پول پیشپرداخت
مشتری حساب خود را شارژ میکند؛ از طریق Stripe Checkout، درگاه پرداخت محلی، یا ثبت دستی توسط مدیر. هزینه هر درخواست بعد از اندازهگیری از موجودی کیف پول کم میشود.
مناسب برای: توسعهدهندگانی که در حال آزمایشاند، مشتریان پرداخت به ازای مصرف، و بازارهایی که صدور فاکتور برایشان اصطکاک ایجاد میکند.
رفتار: شارژ کیف پول در همان دفتر کلی ثبت میشود که مصرف را ثبت میکند. واریز تأییدشده بعد از همگامسازی، بلافاصله در مسیر اصلی درخواست دیده میشود؛ بدون پیامهایی مثل «موجودی هر ساعت بهروز میشود».
۳. اعتبار پسپرداخت
مشتری تا سقف اعتبار قابل تنظیم مصرف میکند. در پایان دوره، فینو برای مانده حساب دریافتنی فاکتور صادر میکند.
مناسب برای: مشتریان سازمانی با فرایند خرید رسمی، شرایط net-30 یا net-60، و رابطه اعتباری از قبل تعریفشده.
رفتار: مرحله رزرو ابتدا کیف پول و سپس ظرفیت اعتبار را بررسی میکند. با انباشته شدن مصرف، حساب دریافتنی در دفتر کل دوطرفه ثبت میشود؛ بنابراین واحد مالی قبل از ارسال فاکتور، میزان بدهی در معرض وصول را میبیند.
یک کلید، یک یکپارچهسازی، تغییر خودکار منبع پرداخت
یک ماه واقعی برای یک مشتری با یک کلید API میتواند اینطور پیش برود:
| هفته | اتفاق | منبع |
|---|---|---|
| ۱ | مصرف در محدوده طرح Pro است؛ ۵۰۰k توکن در ماه | سهمیه |
| ۲ | اوج مصرف هنگام راهاندازی، سهمیه را تمام میکند | کیف پول (شارژ خودکار با Stripe) |
| ۳ | کیف پول وسط دمو تمام میشود؛ سقف اعتبار اجازه ادامه میدهد | اعتبار پسپرداخت |
| ۴ | واحد مالی فاکتور میگیرد؛ مشتری از داشبورد پرداخت میکند | تسویه حساب دریافتنی |
توسعهدهنده کلید API را عوض نکرد. تیم فروش هم تیکت «استثنای صورتحساب» ثبت نکرد. فینو بهترتیب سراغ منابع پرداخت رفت:
سهمیه (اشتراک) → کیف پول (پیشپرداخت) → اعتبار (پسپرداخت) → 402این اولویت برای هر محصول قابل تنظیم است. اما انتخاب منبع پرداخت همیشه سمت سرور، قطعی، و از طریق Raft همگام میشود تا همه گرهها روی یک تصمیم توافق داشته باشند.
مدل قیمتگذاری روی همین پایه مینشیند
منبع پرداخت جواب میدهد پول از کجا میآید. قیمتگذاری جواب میدهد هر واحد چقدر هزینه دارد.
روی همان حساب، فینو از این مدلها پشتیبانی میکند:
- نرخ ثابت به ازای واحد — مثلاً ۰٫۰۰۲ دلار برای هر فراخوانی.
- پلکانی — ۱M توکن اول با یک نرخ، ۴M توکن بعدی با نرخ دیگر.
- حجمی — قیمت واحد بر اساس کل مصرف دوره تعیین میشود.
قیمتگذاری در مرحله نهاییسازی و با شمارنده مصرف دوره انجام میشود. اگر مصرف وسط یک درخواست از یک پله قیمتی عبور کند، محاسبه با micros صحیح انجام میشود؛ نه با تقریبهای صفحهگسترده.
مشتری میتواند همزمان اشتراک سهمیهای داشته باشد، روی بسته توکن پلکانی قیمتگذاری شود، و مصرف مازاد را از کیف پول پرداخت کند؛ چون منبع پرداخت و اندازهگیری دو موضوع جدا هستند که در یک جریان دستور به هم وصل شدهاند.
چرا رقبا مجبورتان به انتخاب میکنند
| پلتفرم | محدودیت معمول |
|---|---|
| Kong / AWS APIM / Apigee | فقط اعمال سهمیه — بدون صورتحساب پولی |
| Stripe Billing | اشتراک یا مصرفی — نه هر دو بهصورت بومی روی یک کلید، همراه با کیف پول پشتیبان |
| Lago / Metronome / Orb | اندازهگیری قوی — اما رویدادهای ناهمگام دوباره شکاف صورتحساب ایجاد میکنند؛ بدون پروکسی بومی |
| Zuplo | درگاه + Stripe — بدون دفتر کل یکپارچه یا ترتیب همزمان منابع پرداخت |
تمایز فینو این نیست که «سه صفحه قیمتگذاری داریم». تمایز این است که هر سه منبع پرداخت از یک دفتر کل، یک جریان رزرو/نهاییسازی، و یک معادله حسابداری مشترک استفاده میکنند؛ معادلهای که قبل از برگشت پاسخ کنترل میشود.
شما چه چیزی تنظیم میکنید، مشتری چه چیزی میبیند
شما تنظیم میکنید:
- تعریف طرح (سهمیه، دوره، قیمت)
- درگاه شارژ کیف پول و حداقل موجودی لازم
- سقف اعتبار و شرایط فاکتور
- اولویت منابع پرداخت و سیاست مصرف مازاد
مشتری میبیند:
- یک کلید API
402فوری وقتی واقعاً هیچ موجودی یا اعتباری باقی نمانده است- داشبورد سلفسرویس با سهمیه باقیمانده، موجودی کیف پول، و فاکتورهای باز
- بدون SDK صورتحساب در کد برنامه
مشتری نباید لازم داشته باشد بداند این درخواست از سهمیه اسفند کم شده یا از شارژ دیروز Stripe. این جزئیات زیرساخت شماست؛ مسئله مشتری نیست.
کی از کدام مدل استفاده کنید
| نوع مشتری | شروع | گسترش |
|---|---|---|
| توسعهدهنده مستقل | کیف پول پیشپرداخت | طرح سهمیهای بعد از ارتقا |
| تیم در حال رشد | اشتراک سهمیه | کیف پول برای مازاد |
| سازمانی | اعتبار پسپرداخت | سقف سهمیه برای بودجه واحدها |
| بازار / فروشنده | هر سه | تسویه ارائهدهنده از همان دفتر کل |
هدف این نیست که فقط یک ردیف را انتخاب کنید. هدف این است که مشتری بتواند بین این مدلها رشد کند، بدون اینکه کل سیستم صورتحساب را عوض کنید.
سه مدل صورتحساب با یک کلید API فقط یک شعار بازاریابی نیست. ترتیب منابع پرداخت در همان ماشین حالتی اجرا میشود که API شما را پروکسی میکند؛ تا هر نوع مشتری یک یکپارچهسازی، یک دفتر کل، و یک مرجع حقیقت داشته باشد.