تیم فنی واقعاً چه چیزی لازم دارد؟

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

یک integration ساده کافی است:

API Key → ساخت Invoice → دریافت Checkout URL → پرداخت مشتری → تأیید تراکنش → Webhook

در عمل، بک‌اند یا ربات تو یک فاکتور ایجاد می‌کند و اطلاعاتی مانند این موارد را مشخص می‌کند:

• شبکهٔ پرداخت
• دارایی موردنظر
• مبلغ
• شناسهٔ سفارش یا externalId

Fiura در پاسخ، لینک صفحهٔ پرداخت را در اختیار سیستم قرار می‌دهد.

همان لینک می‌تواند در سایت، اپلیکیشن، ربات، ایمیل یا هر کانال دیگری که مشتری از آن خرید می‌کند استفاده شود.

انتخاب شبکه با کسب‌وکار است

پرداخت رمزارزی فقط به یک بلاکچین محدود نیست.

در Fiura می‌توانی بسته به نیاز کسب‌وکارت شبکهٔ مناسب را انتخاب کنی.

BSC

برای پرداخت‌هایی که سرعت و هزینهٔ پایین تراکنش اهمیت دارد، BSC می‌تواند گزینهٔ مناسبی باشد.

Ethereum

برای کسب‌وکارهایی که می‌خواهند در بزرگ‌ترین اکوسیستم EVM حضور داشته باشند، Ethereum انتخاب طبیعی‌تری است.

TRON

برای پرداخت‌های مبتنی بر USDT، به‌خصوص در سناریوهایی که حجم بالای پرداخت مطرح است، TRON یکی از گزینه‌های مهم است.

نکته اینجاست که منطق کسب‌وکار تو با تغییر شبکه عوض نمی‌شود.

Invoice همان Invoice است؛ فقط شبکهٔ پرداخت تغییر می‌کند.

مبلغ را تتر بگذار یا تومان؛ مشتری با کیف پول خودش پرداخت می‌کند

در جریان پرداخت، کسب‌وکار می‌تواند مبلغ را بر اساس نیاز خود تعریف کند.

مثلاً می‌توانی قیمت محصول را به تومان مشخص کنی و Fiura مقدار رمزارز موردنیاز را محاسبه کند؛ یا مستقیماً مبلغ را بر اساس یک دارایی مانند USDT تعیین کنی.

مشتری نیز از کیف پول خودش پرداخت می‌کند.

بسته به جریان پرداخت، روش‌هایی مانند:

• WalletConnect
• QR Code
• ارسال مستقیم تراکنش
• ثبت txHash

می‌توانند در اختیار کاربر قرار بگیرند.

در نتیجه، مشتری لازم نیست برای پرداخت وارد چند سایت مختلف شود یا برای پیدا کردن تراکنش، چند Explorer را باز کند.

Checkout؛ جایی که پرداخت اتفاق می‌افتد

یکی از بخش‌های مهم هر درگاه پرداخت، خود صفحهٔ Checkout است.

اگر این مرحله پیچیده باشد، حتی بهترین API هم نمی‌تواند تجربهٔ پرداخت خوبی ایجاد کند.

Fiura این بخش را آماده می‌کند تا مشتری بتواند اطلاعات مهم پرداخت را در یک محیط مشخص ببیند:

• مبلغ پرداخت
• دارایی
• شبکه
• وضعیت تراکنش
• اطلاعات پرداخت
• QR Code
• هویت بصری فروشنده

به این ترتیب، کسب‌وکار لازم نیست خودش یک Payment UI کامل برای تراکنش‌های بلاکچینی طراحی کند.

از Invoice تا سفارش تکمیل‌شده

جریان اصلی پرداخت را می‌توان خیلی ساده تصور کرد:

۱. ایجاد Invoice

بک‌اند، ربات یا سیستم اتوماسیون تو یک Invoice ایجاد می‌کند.

۲. دریافت Checkout URL

Fiura لینک پرداخت را برمی‌گرداند.

۳. پرداخت مشتری

مشتری از کیف پول خودش پرداخت را انجام می‌دهد.

۴. تشخیص تراکنش

پرداخت روی شبکه شناسایی می‌شود.

۵. تغییر وضعیت Invoice

پس از تأیید شرایط پرداخت، وضعیت Invoice به paid تغییر می‌کند.

۶. ارسال Webhook

Fiura نتیجه را به endpoint تعریف‌شده توسط کسب‌وکار ارسال می‌کند.

۷. انجام عملیات نهایی

از اینجا سیستم تو می‌تواند سفارش را تحویل دهد، لایسنس را فعال کند، اعتبار حساب را افزایش دهد یا هر فرآیند دیگری را اجرا کند.

یعنی توسعه‌دهنده دیگر لازم نیست هر چند دقیقه بلاکچین را بررسی کند تا بفهمد مشتری پول را فرستاده یا نه.

Webhook؛ جایی که سیستم تو خبردار می‌شود

برای یک سیستم پرداخت واقعی، فقط تشخیص تراکنش کافی نیست.

سیستم فروش باید بداند چه زمانی پرداخت تأیید شده است.

Webhook این ارتباط را برقرار می‌کند.

وقتی وضعیت پرداخت تغییر می‌کند، Fiura اطلاعات مربوط به پرداخت را به آدرسی که کسب‌وکار تعریف کرده ارسال می‌کند.

این یعنی می‌توانی جریان‌هایی مثل این بسازی:

Fiura → Webhook → Backend → Order Paid → Deliver Product

یا:

Fiura → Webhook → n8n → Telegram / Discord / CRM

برای امنیت بیشتر، Webhook را می‌توان با امضای HMAC اعتبارسنجی کرد تا سیستم تو بتواند تشخیص دهد درخواست واقعاً از منبع مورداعتماد آمده است.

این موضوع در زیرساخت‌های پرداخت اهمیت زیادی دارد؛ چون یک Webhook جعلی نباید بتواند یک سفارش را به وضعیت «پرداخت‌شده» تغییر دهد.

امنیت بدون پیچیده کردن تجربهٔ کاربر

پرداخت باید هم امن باشد و هم سریع.

Fiura بخش‌هایی از زیرساخت را در اختیار می‌گیرد تا تیم فنی مجبور نباشد همه‌چیز را خودش پیاده‌سازی کند.

در معماری پرداخت، مواردی مانند مدیریت امن API Key، اعتبارسنجی Webhook و کنترل دسترسی به عملیات حساس اهمیت بالایی دارند.

از طرف دیگر، تراکنش‌ها قابل بررسی روی بلاکچین هستند.

اگر تیم مالی یا پشتیبانی بپرسد:

«این پرداخت کجاست؟»

پاسخ فقط یک رکورد داخلی نیست.

txHash یک مرجع قابل بررسی روی شبکه است.

این شفافیت یکی از تفاوت‌های اصلی پرداخت‌های On-chain با بسیاری از سیستم‌های پرداخت سنتی است.

پرداخت حضوری هم می‌تواند همان زیرساخت را داشته باشد

Fiura فقط برای فروشگاه‌های آنلاین طراحی نشده است.

فرض کن یک کسب‌وکار حضوری می‌خواهد پرداخت رمزارزی دریافت کند.

می‌توان همان شبکه‌ها و موجودی را با یک QR Code در اختیار مشتری قرار داد.

در نتیجه، کسب‌وکار مجبور نیست برای پرداخت آنلاین و حضوری دو سیستم کاملاً جداگانه داشته باشد.

یک زیرساخت پرداخت؛ چند کانال فروش.

Fiura Prove؛ وقتی فقط «پرداخت» کافی نیست

همهٔ مسائل مالی با پرداخت حل نمی‌شوند.

گاهی یک کسب‌وکار یا طرف معامله می‌خواهد بداند آیا یک فرد یا مجموعه توانایی مالی مشخصی دارد یا نه؛ اما نمی‌خواهد رقم دقیق دارایی خود را افشا کند.

برای این سناریو، Fiura یک لایهٔ جداگانه با نام Fiura Prove دارد.

ایده این است که بتوان حداقل موجودی موردنیاز را اثبات کرد، بدون اینکه مقدار دقیق دارایی آشکار شود.

این قابلیت برای معامله‌های سنگین‌تر می‌تواند کاربرد داشته باشد؛ برای مثال:

• خودرو
• ملک
• آثار هنری
• معاملات بزرگ B2B

Fiura Prove جای درگاه پرداخت روزمره را نمی‌گیرد.

درگاه برای انتقال ارزش است؛ Prove برای ایجاد اعتماد قبل از معامله.

از Testnet تا اولین پرداخت

برای شروع لازم نیست زیرساخت پیچیده‌ای داشته باشی.

می‌توانی ابتدا در محیط Testnet جریان پرداخت را آزمایش کنی و بعد سراغ Mainnet بروی.

فرآیند کلی برای تیم فنی ساده است:

1. ایجاد حساب
2. دریافت API Key
3. ساخت اولین Invoice
4. دریافت checkoutUrl
5. باز کردن صفحهٔ پرداخت
6. بررسی وضعیت Invoice
7. تنظیم Webhook
8. اتصال پرداخت موفق به سیستم سفارش

مستندات فارسی و انگلیسی، به همراه نمونه‌های cURL و Node، مسیر Integration را برای توسعه‌دهنده کوتاه‌تر می‌کنند.

هدف این نیست که تیم تو متخصص بلاکچین شود.

هدف این است که پرداخت رمزارزی مثل یک سرویس دیگر در Backend محصولت قابل استفاده باشد.

n8n؛ وقتی پرداخت باید به بقیهٔ سیستم وصل شود

اگر کسب‌وکار از اتوماسیون استفاده می‌کند، Webhook می‌تواند نقطهٔ اتصال Fiura به سایر سرویس‌ها باشد.

مثلاً:

Payment Confirmed → n8n → CRM

یا:

Payment Confirmed → n8n → Telegram

یا:

Payment Confirmed → n8n → فعال‌سازی اشتراک SaaS

به این ترتیب، پرداخت فقط یک تراکنش بلاکچینی باقی نمی‌ماند؛ تبدیل می‌شود به یک Event در سیستم کسب‌وکار.

لازم نیست Blockchain Engineer باشی

برای پذیرش پرداخت رمزارزی، الزاماً به Full Node، Smart Contract یا تیم Blockchain جداگانه نیاز نداری.

اگر یک Backend داری که می‌تواند API را صدا بزند و یک Endpoint برای دریافت Webhook داشته باشد، بخش اصلی Integration در اختیار توست.

مدل ذهنی ساده است:

محصول تو

↓

Fiura API

↓

Invoice

↓

Checkout

↓

Blockchain Payment

↓

Confirmation

↓

Webhook

↓

Business Logic

↓

Order Completed

این همان چیزی است که یک درگاه پرداخت باید انجام دهد:

نه اینکه تو را مجبور کند زیرساخت بلاکچین بسازی؛ بلکه باید بلاکچین را به یک بخش قابل‌استفاده از محصولت تبدیل کند.

آیندهٔ Multi-Chain؛ بدون تغییر مدل Integration

شبکه‌های بلاکچینی دائماً در حال تغییرند و هر شبکه ویژگی‌ها و کاربران خودش را دارد.

به همین دلیل، یک Payment Gateway خوب نباید منطق کسب‌وکار را به یک شبکهٔ خاص گره بزند.

در Fiura، مدل اصلی بر پایهٔ Invoice، Checkout، Status و Webhook طراحی شده است.

بنابراین با اضافه شدن شبکه‌های جدید، هدف این است که مدل Integration برای تیم فنی ثابت بماند.

Polkadot نیز در نقشهٔ توسعهٔ Fiura قرار دارد، اما تا زمانی که Checkout آن آمادهٔ استفادهٔ زنده نباشد، شبکه‌های فعلی مانند BSC، Ethereum و TRON گزینه‌های اصلی برای ساخت جریان پرداخت هستند.

یک روز تا اولین پرداخت

برای شروع یک پروژهٔ پرداخت رمزارزی لازم نیست ماه‌ها زیرساخت بسازی.

اگر Backend، API و Webhook را در اختیار داری، مسیر می‌تواند به چند مرحلهٔ مشخص خلاصه شود:

API Key بگیر → Invoice بساز → Checkout را باز کن → پرداخت را دریافت کن → Webhook را پردازش کن.

بقیهٔ کار، منطق محصول توست.

Fiura قرار نیست جای محصولت را بگیرد.

تو محصول را می‌سازی؛ Fiura کمک می‌کند ارزش بین مشتری و کسب‌وکار جابه‌جا شود و سیستم تو همان لحظه از نتیجه باخبر شود.

شروع کنید

اگر محصول، فروشگاه، SaaS، ربات فروش یا سیستم اتوماسیون داری و می‌خواهی پرداخت رمزارزی را بدون ساخت زیرساخت بلاکچینی از صفر به آن اضافه کنی، Fiura می‌تواند نقطهٔ شروع Integration تو باشد.