tgpay cryptoAPI
crypto-payfeeslimitstransfers

کارمزد و سقف‌های API پذیرنده

3 دقیقه مطالعهآخرین به‌روزرسانی: 5 سپتامبر 2026

صورت‌حساب‌ها یک کارمزد پلتفرم دارند که از سهم شما کسر می‌شود؛ انتقال‌ها و چک‌ها هم به سقف مبلغ محدودند. عددهای زیر تنظیمات فعلی‌اند، نه شرط قرارداد — هر جا با آنچه در برنامه می‌بینید مطابقت نداشت، ملاک برنامه است و منبع قابل اتکا همیشه صورت‌حساب‌های پرداخت‌شده‌ی خودتان است.

کارمزد صورت‌حساب

پرداخت‌کننده همیشه مبلغ اسمی صورت‌حساب را می‌پردازد. کارمزد از سمت پذیرنده برداشته می‌شود: موجودی برنامه‌ی شما به اندازه‌ی مبلغ پس از کسر کارمزد شارژ می‌شود.

کارمزد 3% مبلغ صورت‌حساب است و بر اساس گردش پرداخت شما در 30 روز گذشته، خودکار و پلکانی کاهش می‌یابد:

حجم 30 روزهکارمزد
کمتر از 10,000 دلار3%
از 10,000 دلار2.9%
از 25,000 دلار2.8%
از 50,000 دلار2.7%
از 75,000 دلار2.6%
از 100,000 دلار2.5%

دو قاعده از خود عدد مهم‌ترند:

  • کارمزد در لحظه‌ی پرداخت تعیین و قفل می‌شود. تغییر بعدی نرخ هرگز به صورت‌حسابی که پیش‌تر پرداخت شده دست نمی‌زند.
  • نرخ شما با گردش کارتان تغییر می‌کند. گردش پرداخت بالاتر در بازه‌ی 30 روزه‌ی گذشته می‌تواند شما را خودکار به پله‌ی پایین‌تر ببرد. نه درخواستی لازم است، نه چیزی برای تنظیم کردن.

برای اینکه ببینید دقیقاً چه چیزی کسر شده، fee_asset و fee_amount را از صورت‌حساب پرداخت‌شده بخوانید — از محتوای وب‌هوک invoice_paid یا از getInvoices. برای حسابداری شما همان عدد معتبر است.

بازگشت وجه کارمزد را برنمی‌گرداند: آنچه refundInvoice به پرداخت‌کننده می‌فرستد از موجودی شما کم می‌شود و کارمزد بازنمی‌گردد — در بازگشت جزئی هم همین است.

کسر اشتراک هم کارمزد سمت پذیرنده دارد؛ هر کسر عدد خودش را در فیلد charge.fee از وب‌هوک subscription_charged گزارش می‌کند.

سقف انتقال

transfer به حداقل و حداکثر هر انتقال محدود است و این سقف به‌جای عددی جدا برای هر دارایی، به‌صورت برآورد معادل دلاری با نرخ روز اعمال می‌شود. مبلغ بیرون از این بازه با خطایی صریح رد می‌شود، پس در یکپارچه‌سازی‌تان amount_too_small و amount_too_big را هم پیش‌بینی کنید.

انتقال در این حالت‌ها هم ناموفق می‌شود:

  • در آن دارایی موجودی برنامه‌تان کم بیاید،
  • گیرنده کاربر این برنامه نباشد — پرداخت به شناسه‌ی تلگرامِ ناشناخته یا اشتباه، به‌جای شارژ کیف پولی که کسی آن را باز نمی‌کند، خطا می‌دهد،
  • حساب گیرنده مسدود باشد.

سقف درخواست

متدهایی که پول جابه‌جا می‌کنند برای هر برنامه سقف دارند (مشترک بین همه‌ی توکن‌هایش): createInvoice و createCheck هر دقیقه 60 بار، refundInvoice و transfer هر دقیقه 30 بار و transferBatch هر دقیقه 10 بار. متدهای خواندنی سقفی ندارند. یکپارچه‌سازی سالم هیچ‌وقت به این سقف نمی‌خورد، اما حلقه‌ی تلاش دوباره می‌خورد — با دیدن rate_limited، به‌جای ارسال پیاپی درخواست، فاصله‌ی بین درخواست‌ها را بیشتر کنید.

جلوگیری از پرداخت دوباره

transfer به یک spend_id نیاز دارد که خودتان می‌سازید؛ createCheck و refundInvoice هم آن را می‌پذیرند. اگر همان مقدار را دوباره بفرستید، به‌جای جابه‌جایی دوباره‌ی پول، همان نتیجه‌ی اول تکرار می‌شود — پس درخواستی را که تایم‌اوت شده می‌توان بی‌خطر با همان spend_id دوباره فرستاد و فقط پرداختی که واقعاً جدید است spend_id جدید می‌گیرد.

چه چیزی هزینه ندارد

در API پذیرنده هیچ‌جا کارمزد شبکه وجود ندارد — صورت‌حساب، انتقال و چک همگی داخل خود برنامه و بیرون از زنجیره تسویه می‌شوند. تنها هزینه، کارمزد پلتفرم روی صورت‌حساب‌هاست.

⚠️ هرگز کارمزد را خودتان حساب نکنید

درصد را در کد ثابت نکنید و مبلغ خالص را از روی مبلغ اسمی بازسازی نکنید. پله‌ها و نرخ‌ها عوض می‌شوند و یک ثابتِ قدیمی بی‌سروصدا حسابداری شما را خراب می‌کند. هر بار کارمزد ثبت‌شده را از خود صورت‌حساب بخوانید.