مقدمه

درگاه پرداخت یکی از حساس‌ترین اجزای هر فروشگاه اینترنتی، سامانه رزرو، نرم‌افزار اشتراکی یا پلتفرم خدمات آنلاین است. کاربران ممکن است طراحی زیبای سایت، سرعت مناسب و امکانات متنوع آن را تحسین کنند؛ اما اگر در مرحله پرداخت با خطا، ابهام، بازگشت ناموفق یا ثبت‌نشدن سفارش مواجه شوند، کل تجربه آن‌ها تحت تأثیر قرار می‌گیرد.

هنگام راه‌اندازی پرداخت اینترنتی، معمولاً دو گزینه اصلی پیش روی کسب‌وکار قرار دارد: درگاه پرداخت مستقیم و درگاه پرداخت واسط. در مدل مستقیم، پذیرنده با یک شرکت ارائه‌دهنده خدمات پرداخت یا PSP وارد همکاری می‌شود. در مدل واسط، خدمات پرداخت از طریق یک پرداخت‌یار مجاز و زیرساخت‌های تکمیلی آن ارائه می‌شود.

در نگاه اول، تفاوت این دو گزینه ساده به نظر می‌رسد: درگاه مستقیم ارتباط مستقیم‌تری با PSP دارد و درگاه واسط معمولاً سریع‌تر و همراه با ابزارهای جانبی فعال می‌شود. اما در عمل، انتخاب درست به مدل درآمدی، حجم تراکنش‌ها، توان فنی تیم، نیازهای حسابداری، زمان ورود به بازار، نحوه تسویه و برنامه توسعه آینده بستگی دارد.

در پروژه‌های طراحی سایت و تولید نرم‌افزار تحت وب، انتخاب درگاه باید هم‌زمان با طراحی فرایند سفارش و معماری مالی انجام شود. برای نمونه، رویکرد فنی اسمارتی اپ (SmartyApp)در چنین پروژه‌هایی این است که پرداخت صرفاً یک دکمه یا صفحه انتقال به بانک در نظر گرفته نشود؛ بلکه بخشی از چرخه سفارش، حسابداری، تطبیق مالی و مدیریت خطا باشد.

در این مقاله، ضمن پاسخ به پرسش «درگاه پرداخت مستقیم یا واسط؟»، نحوه عملکرد هر مدل، مزایا و محدودیت‌ها، معیارهای انتخاب، نکات امنیتی و روش استاندارد پیاده‌سازی آن‌ها را بررسی می‌کنیم.

نکته: مقررات، مدارک موردنیاز، تعرفه‌ها و زمان‌بندی تسویه ممکن است در طول زمان تغییر کنند. پیش از عقد قرارداد باید شرایط جاری را از شرکت ارائه‌دهنده و منابع رسمی بررسی کنید.

اکوسیستم پرداخت اینترنتی در ایران چگونه کار می‌کند؟

برای مقایسه درست درگاه مستقیم و واسط، ابتدا باید نقش بازیگران اصلی شبکه پرداخت را بشناسیم.

بانک مرکزی

بانک مرکزی نقش سیاست‌گذاری و تنظیم‌گری کلان نظام پولی و پرداخت را بر عهده دارد. ضوابط فعالیت شرکت‌های ارائه‌دهنده خدمات پرداخت و پرداخت‌یاران در این چارچوب تدوین می‌شود.

شرکت شاپرک

شرکت شبکه الکترونیکی پرداخت کارت یا شاپرک، بازوی اجرایی و نظارتی بانک مرکزی در شبکه پرداخت کارتی است. این شرکت برای سامان‌دهی، کنترل و نظارت بر ابزارهای پذیرش و شرکت‌های فعال در شبکه پرداخت فعالیت می‌کند. (Shaparak)

در وب‌سایت رسمی شاپرک و فهرست شرکت‌های مجاز بخش‌هایی برای معرفی شرکت‌های PSP، پرداخت‌یاران و دیگر بازیگران مجاز شبکه وجود دارد. پیش از انتخاب هر شرکت، باید وضعیت مجوز و فعالیت آن در منبع رسمی بررسی شود. (Shaparak)

شرکت PSP چیست؟

PSP مخفف Payment Service Provider است. این شرکت‌ها خدمات پرداخت الکترونیکی مانند درگاه پرداخت اینترنتی و پایانه‌های فروشگاهی را تحت نظارت شبکه پرداخت ارائه می‌کنند.

هنگامی که یک کسب‌وکار درگاه مستقیم دریافت می‌کند، قرارداد پذیرندگی آن معمولاً مستقیماً با یک PSP منعقد می‌شود و شناسه پذیرنده و ترمینال مربوط به همان کسب‌وکار تخصیص می‌یابد.

پرداخت‌یار چیست؟

در اسناد بانک مرکزی، پرداخت‌یار یک شخص حقوقی است که براساس قرارداد با شرکت‌های PSP و تفاهم با شاپرک فعالیت می‌کند و پرداخت‌های بدون حضور کارت را دریافت و به شبکه شاپرک ارسال می‌کند. (cbi.ir)

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

بنابراین هر شرکت واسطی الزاماً پرداخت‌یار مجاز نیست. در این مقاله، منظور از «درگاه واسط»، خدماتی است که از طریق پرداخت‌یار یا مجموعه دارای ارتباط قانونی و قابل‌استعلام با شبکه پرداخت ارائه می‌شود.

پذیرنده

پذیرنده همان کسب‌وکار، فروشگاه یا سازمانی است که برای دریافت وجه از مشتری از درگاه استفاده می‌کند. اطلاعات هویتی، حساب بانکی، دامنه، حوزه فعالیت و وضعیت قانونی پذیرنده در فرایند فعال‌سازی بررسی می‌شود.

درگاه پرداخت مستقیم چیست؟

درگاه پرداخت مستقیم یا Direct IPG سرویسی است که طی آن کسب‌وکار مستقیماً از یک PSP خدمات درگاه اینترنتی دریافت می‌کند.

در این مدل، پذیرنده معمولاً فرایند احراز هویت و عقد قرارداد را با PSP طی می‌کند. پس از تأیید، اطلاعاتی مانند شناسه پذیرنده، شناسه ترمینال و کلیدها یا نام‌های کاربری فنی برای اتصال به API در اختیار تیم توسعه قرار می‌گیرد.

فرایند ساده یک پرداخت مستقیم به این صورت است:

1. مشتری سفارش را در سایت ثبت می‌کند.
2. سرور سایت درخواست ایجاد تراکنش را به API شرکت PSP ارسال می‌کند.
3. PSP یک توکن یا شناسه پرداخت برمی‌گرداند.
4. کاربر به صفحه پرداخت هدایت می‌شود.
5. پس از انجام یا لغو عملیات، کاربر به Callback URL سایت بازمی‌گردد.
6. سرور سایت نتیجه تراکنش را به‌صورت مستقل از PSP استعلام یا تأیید می‌کند.
7. در صورت موفقیت تأیید، سفارش به وضعیت پرداخت‌شده تغییر می‌کند.
8. اطلاعات تراکنش برای گزارش‌گیری و تطبیق مالی ذخیره می‌شود.

مزایای درگاه پرداخت مستقیم

ارتباط قراردادی مستقیم با PSP

کسب‌وکار مستقیماً با ارائه‌دهنده زیرساخت پرداخت در ارتباط است. این موضوع برای سازمان‌هایی که فرایند حقوقی، مالی یا امنیتی مشخصی دارند اهمیت زیادی دارد.

کنترل بیشتر بر تنظیمات پذیرندگی

برخی تنظیمات، گزارش‌ها و فرایندهای پشتیبانی بدون عبور از یک لایه واسط مدیریت می‌شوند. البته امکانات دقیق به PSP و قرارداد پذیرندگی بستگی دارد.

مناسب برای تراکنش‌های پرتعداد

کسب‌وکارهایی که تعداد تراکنش بالایی دارند، معمولاً به SLA، مدیریت حساب سازمانی و کانال پشتیبانی رسمی‌تری نیاز دارند. درگاه مستقیم می‌تواند برای چنین کسب‌وکارهایی گزینه منطقی‌تری باشد.

کاهش وابستگی به لایه واسط

اگر API مستقیماً به PSP متصل باشد، تغییر سیاست، محدودیت یا اختلال سامانه واسط مستقیماً بر کسب‌وکار اثر نمی‌گذارد. البته همچنان وابستگی فنی به همان PSP وجود دارد.

تناسب بیشتر با ساختارهای سازمانی

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

چالش‌های درگاه مستقیم

فرایند فعال‌سازی طولانی‌تر

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

مستندات فنی متفاوت

کیفیت مستندات API، محیط آزمایشی، کتابخانه‌های برنامه‌نویسی و نمونه‌کد در شرکت‌های مختلف یکسان نیست. تیم توسعه باید توان تحلیل و پیاده‌سازی مستقل داشته باشد.

ابزارهای جانبی محدودتر

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

پشتیبانی فنی سازمانی

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

توسعه جداگانه برای هر PSP

فرمت درخواست، کدهای خطا، روش Verify و ساختار پاسخ هر ارائه‌دهنده می‌تواند متفاوت باشد. اتصال مستقیم بدون لایه انتزاعی، تعویض درگاه در آینده را پرهزینه می‌کند.

درگاه پرداخت واسط چیست؟

درگاه واسط، درگاه پرداخت‌یار یا Aggregated Payment Gateway سرویسی است که ارتباط کسب‌وکار با شبکه پرداخت را از طریق یک ارائه‌دهنده واسط برقرار می‌کند.

پرداخت‌یار معمولاً API ساده‌تر، پنل مدیریتی، ابزارهای گزارش‌گیری و فرایند ثبت‌نام آنلاین‌تری ارائه می‌دهد. کسب‌وکار همچنان باید احراز هویت شود و اطلاعات پذیرندگی آن در چارچوب مقررات شبکه ثبت شود؛ بنابراین درگاه واسط مجاز به معنی پرداخت ناشناس یا بدون نظارت نیست.

فرایند فنی پرداخت واسط از دید توسعه‌دهنده مشابه درگاه مستقیم است:

1. ایجاد سفارش در نرم‌افزار
2. ارسال درخواست پرداخت به API پرداخت‌یار
3. دریافت توکن
4. انتقال کاربر به صفحه پرداخت
5. بازگشت کاربر به سایت
6. ارسال درخواست Verify از سرور
7. ثبت نتیجه قطعی
8. تسویه و تطبیق گزارش‌ها

تفاوت اصلی در لایه ارائه‌دهنده، قرارداد، امکانات تکمیلی و نحوه پشتیبانی است.

مزایای درگاه پرداخت واسط

فعال‌سازی و راه‌اندازی ساده‌تر

بسیاری از پرداخت‌یاران فرایند ثبت‌نام، بارگذاری مدارک، تعریف دامنه و دریافت کلید API را به‌صورت آنلاین انجام می‌دهند.

API و مستندات توسعه‌دهنده‌محور

پرداخت‌یاران معمولاً برای جذب فروشگاه‌های آنلاین، فریلنسرها و استارتاپ‌ها تلاش می‌کنند تجربه اتصال را ساده کنند. نمونه‌کد، افزونه، SDK و محیط آزمایشی می‌تواند زمان توسعه را کاهش دهد.

افزونه‌های آماده

برای سیستم‌های مدیریت محتوا و فروشگاه‌سازها معمولاً افزونه‌های نصب‌شدنی ارائه می‌شود. البته پیش از استفاده باید امنیت، سازگاری و وضعیت نگهداری افزونه بررسی شود.

خدمات ارزش‌افزوده

امکانات احتمالی عبارت‌اند از:

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

وجود و شرایط هر قابلیت باید در مستندات و قرارداد همان ارائه‌دهنده بررسی شود.

پشتیبانی مناسب‌تر برای کسب‌وکارهای کوچک

پرداخت‌یاران معمولاً با مسائل رایج فروشگاه‌های کوچک و متوسط آشناترند و ممکن است پاسخ‌گویی ساده‌تر و کانال‌های ارتباطی متنوع‌تری ارائه دهند.

چالش‌های درگاه پرداخت واسط

اضافه‌شدن یک لایه عملیاتی

در این مدل، علاوه بر PSP و شبکه پرداخت، سامانه پرداخت‌یار نیز در مسیر ارائه خدمت قرار می‌گیرد. اختلال یا محدودیت در این لایه می‌تواند بر عملیات پرداخت اثر بگذارد.

هزینه یا کارمزد خدمات

ممکن است پرداخت‌یار برای هر تراکنش، تسویه، ابزار تکمیلی یا خدمات ویژه هزینه دریافت کند. ساختار کارمزد ثابت نیست و باید براساس قرارداد جاری بررسی شود.

وابستگی به امکانات اختصاصی

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

تفاوت در زمان‌بندی تسویه

شیوه و زمان‌بندی تسویه می‌تواند براساس مقررات شبکه، نوع سرویس و قرارداد پرداخت‌یار متفاوت باشد. این مسئله برای کسب‌وکارهایی با جریان نقدی حساس بسیار مهم است.

ضرورت بررسی مجوز

نباید صرفاً به ظاهر حرفه‌ای سایت یا تبلیغات ارائه‌دهنده اعتماد کرد. وضعیت شرکت باید از طریق منابع رسمی مانند فهرست شرکت‌های مجاز شاپرک بررسی شود.

جدول مقایسه درگاه پرداخت مستقیم و واسط

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

مقایسه از نظر زمان فعال‌سازی

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

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

برای کسب‌وکار سازمانی، زمان فعال‌سازی معمولاً اهمیت کمتری نسبت به امنیت قرارداد، سطح خدمات، پشتیبانی رسمی و قابلیت گزارش‌گیری دارد.

مقایسه از نظر هزینه و کارمزد

بررسی هزینه درگاه نباید فقط به عدد کارمزد هر تراکنش محدود شود. هزینه واقعی یا Total Cost of Ownership شامل بخش‌های زیر است:

• هزینه یا کارمزد سرویس
• هزینه توسعه اولیه
• هزینه نگهداری اتصال
• هزینه رفع خطا و پشتیبانی
• هزینه توسعه گزارش‌های مالی
• هزینه مهاجرت احتمالی
• زیان ناشی از اختلال و پرداخت ناموفق
• هزینه تطبیق حسابداری
• هزینه امکانات جانبی
• زمان صرف‌شده توسط تیم مالی و پشتیبانی

ممکن است درگاهی کارمزد کمتری داشته باشد، اما API ضعیف، گزارش ناقص یا پشتیبانی نامناسب آن هزینه عملیاتی بیشتری ایجاد کند.

یک فرمول تصمیم‌گیری ساده می‌تواند چنین باشد:

هزینه واقعی پرداخت = کارمزد سرویس + هزینه فنی + هزینه عملیات مالی + زیان خطا و قطعی

تعرفه‌ها و شرایط پرداخت‌یاران و PSPها ممکن است تغییر کنند؛ بنابراین درج یک عدد ثابت در طراحی بلندمدت سیستم منطقی نیست. نرم‌افزار باید قابلیت تعریف و محاسبه هزینه ارائه‌دهنده را به‌صورت تنظیم‌پذیر داشته باشد.

مقایسه از نظر تسویه و جریان نقدی

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

هنگام بررسی درگاه، پرسش‌های زیر را مطرح کنید:

• تسویه در چه روزهایی انجام می‌شود؟
• ساعت قطع پردازش روزانه چیست؟
• تعطیلات چه اثری بر تسویه دارد؟
• آیا حداقل مبلغ تسویه وجود دارد؟
• آیا امکان تسویه به چند حساب وجود دارد؟
• گزارش تسویه شامل چه فیلدهایی است؟
• ارتباط هر واریز با تراکنش‌های سایت چگونه مشخص می‌شود؟
• وضعیت مبالغ معلق چگونه گزارش می‌شود؟
• فرایند رسیدگی به مغایرت چیست؟
• آیا API گزارش تسویه ارائه شده است؟

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

مقایسه از نظر API و تجربه توسعه‌دهنده

کیفیت API تأثیر مستقیمی بر زمان توسعه و تعداد خطاهای عملیاتی دارد.

ویژگی‌های یک API مناسب

• مستندات دقیق و به‌روز
• مثال درخواست و پاسخ
• فهرست کامل کدهای خطا
• محیط Sandbox
• نسخه‌بندی API
• زمان انقضای توکن مشخص
• پشتیبانی از Webhook
• API استعلام وضعیت
• API بازگشت وجه
• گزارش تسویه
• کتابخانه رسمی یا نمونه‌کد
• سازوکار احراز هویت امن
• محدودیت نرخ مستند
• Status Page یا اطلاع‌رسانی اختلال

پیش از انتخاب درگاه، بهتر است تیم فنی یک Proof of Concept اجرا کند و فقط به توضیحات بازاریابی اکتفا نکند.

کیفیت خطاها

پاسخی مانند «عملیات ناموفق بود» برای یک سامانه حرفه‌ای کافی نیست. API باید میان خطاهای زیر تفاوت قائل شود:

• نامعتبر بودن مبلغ
• نامعتبر بودن Callback URL
• خطای احراز هویت
• منقضی‌شدن توکن
• تکراری‌بودن درخواست
• قطع ارتباط با شبکه
• پرداخت‌نشدن توسط کاربر
• پرداخت موفق ولی Verify نشده
• Verify تکراری
• مغایرت مبلغ
• تراکنش برگشتی

تیم توسعه باید برای هر وضعیت رفتار مشخصی تعریف کند.

معماری فنی صحیح اتصال درگاه پرداخت

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

راهنمای رسمی OWASP برای اتصال امن درگاه پرداخت شخص ثالث هشدار می‌دهد که اتصال ناامن می‌تواند به جعل پرداخت، دست‌کاری مبلغ و سوءاستفاده از منطق کسب‌وکار منجر شود. نتیجه پرداخت باید از طریق ارتباط امن سمت سرور تأیید شود. (OWASP Cheat Sheet Series)

مرحله اول: ایجاد سفارش محلی

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

اطلاعات پیشنهادی:

• شناسه سفارش
• شناسه کاربر
• مبلغ نهایی
• واحد پول
• اقلام سفارش
• تخفیف
• هزینه ارسال
• وضعیت سفارش
• زمان ایجاد
• ارائه‌دهنده پرداخت
• وضعیت تراکنش

مبلغ نباید هنگام Callback از پارامترهای مرورگر دریافت و قابل‌اعتماد تلقی شود. مبلغ معتبر همان مبلغ ذخیره‌شده در سرور است.

مرحله دوم: ایجاد رکورد تراکنش

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

فیلدهای پیشنهادی جدول تراکنش:

اطلاعات حساس و کلیدهای محرمانه نباید در Payload یا لاگ ذخیره شوند.

مرحله سوم: دریافت توکن از سرور

درخواست ایجاد پرداخت باید از Backend به API درگاه ارسال شود. کلید API یا Merchant Secret هرگز نباید در کد JavaScript مرورگر، اپلیکیشن قابل‌استخراج یا مخزن عمومی قرار گیرد.

مرحله چهارم: انتقال کاربر

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

مرحله پنجم: دریافت Callback

درگاه پس از پایان عملیات، کاربر را به Callback URL بازمی‌گرداند. پارامترهای Callback صرفاً اطلاعات اولیه‌اند و نباید مبنای قطعی تغییر سفارش به وضعیت «پرداخت‌شده» باشند.

مهاجم می‌تواند URL بازگشت را به‌صورت دستی فراخوانی یا پارامترهای آن را تغییر دهد.

مرحله ششم: Verify سمت سرور

Backend باید با استفاده از توکن، شناسه پذیرنده و مبلغ ذخیره‌شده، درخواست Verify یا Inquiry را مستقیماً به ارائه‌دهنده ارسال کند.

در این مرحله باید موارد زیر بررسی شوند:

• موفقیت قطعی تراکنش
• تطابق مبلغ
• تطابق شناسه سفارش
• تطابق پذیرنده
• معتبر بودن شناسه مرجع
• عدم ثبت قبلی شناسه مرجع
• عدم پرداخت قبلی سفارش
• معتبر بودن وضعیت فعلی تراکنش

راهنمای OWASP برای مجوزدهی تراکنش تأکید می‌کند که کنترل تراکنش باید سمت سرور انجام شود، داده‌های تراکنش در برابر تغییر محافظت شوند و هر عملیات دارای اعتبار منحصربه‌فرد و محدود به زمان باشد. (OWASP Cheat Sheet Series)

مرحله هفتم: ثبت اتمیک نتیجه

پس از Verify موفق باید در یک تراکنش پایگاه داده:

1. وضعیت پرداخت بررسی شود.
2. رکورد تراکنش قفل یا کنترل شود.
3. شناسه مرجع ثبت شود.
4. تراکنش پرداخت‌شده شود.
5. سفارش به وضعیت مناسب تغییر کند.
6. عملیات مالی یا موجودی ثبت شود.

اگر بخشی از عملیات موفق و بخش دیگر ناموفق باشد، سیستم نباید در وضعیت ناسازگار باقی بماند.

مرحله هشتم: نمایش نتیجه

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

مدیریت وضعیت تراکنش

استفاده از یک فیلد بولی مانند is_paid برای سامانه‌های حرفه‌ای کافی نیست. تراکنش می‌تواند وضعیت‌های متعددی داشته باشد.

تغییر وضعیت باید براساس State Machine انجام شود. برای مثال، تراکنش REFUNDED نباید دوباره به PAID بازگردد، مگر آنکه فرایند تجاری مشخصی برای اصلاح وجود داشته باشد.

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

یکی از مشکلات رایج، ارسال چندباره Callback یا تکرار درخواست Verify است. این اتفاق ممکن است به دلایل زیر رخ دهد:

• Refresh صفحه توسط کاربر
• تلاش مجدد مرورگر
• Retry شبکه
• ارسال مجدد Webhook
• کلیک چندباره روی دکمه
• اجرای هم‌زمان چند Worker
• Timeout پاسخ درگاه

راهکار اصلی، Idempotency است؛ یعنی اجرای چندباره یک درخواست یکسان نباید نتیجه مالی را چند بار ثبت کند.

روش‌های پیشنهادی:

• ایجاد Unique Index روی شناسه مرجع ارائه‌دهنده
• ایجاد Unique Constraint برای پرداخت موفق هر سفارش
• استفاده از Lock پایگاه داده
• بررسی وضعیت پیش از اعمال تغییر
• ذخیره Idempotency Key
• جداسازی «دریافت Callback» از «ثبت قطعی پرداخت»
• استفاده از صف برای عملیات جانبی

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

تفاوت ریال و تومان

یکی از ساده‌ترین و درعین‌حال خطرناک‌ترین خطاها، اشتباه میان ریال و تومان است. ممکن است نرم‌افزار مبلغ را به تومان ذخیره کند، اما API درگاه مبلغ را به ریال بخواهد یا برعکس.

بهترین روش این است که:

• واحد پول در مدل داده صریح باشد.
• مبلغ با عدد صحیح ذخیره شود.
• تبدیل فقط در Adapter درگاه انجام شود.
• تست خودکار برای مبالغ نمونه وجود داشته باشد.
• مبلغ ارسال‌شده و مبلغ Verify شده مقایسه شوند.
• نام متغیرها واحد را مشخص کند؛ مانند amountRial.

استفاده از نام عمومی amount بدون مشخص‌کردن واحد، احتمال خطا را افزایش می‌دهد.

الگوی Adapter برای پشتیبانی از چند درگاه

اتصال مستقیم منطق سفارش به یک API خاص، وابستگی شدیدی ایجاد می‌کند. بهتر است یک Payment Gateway Interface تعریف شود.

نمونه عملیات عمومی:

• createPayment
• verifyPayment
• inquirePayment
• refundPayment
• getSettlementReport

سپس برای هر ارائه‌دهنده یک Adapter جداگانه توسعه داده شود:

• DirectPspGatewayAdapter
• PayyarGatewayAdapter
• BackupGatewayAdapter

این معماری مزایای زیر را دارد:

• تعویض ساده‌تر ارائه‌دهنده
• افزودن درگاه دوم
• تست مستقل منطق سفارش
• یکسان‌سازی خطاها
• مدیریت مرکزی لاگ‌ها
• کاهش وابستگی به SDK
• امکان مسیریابی تراکنش‌ها

در پروژه‌های نرم‌افزار اختصاصی، اسمارتی اپ (SmartyApp) می‌تواند لایه پرداخت را مستقل از منطق فروشگاه طراحی کند تا تغییر PSP یا پرداخت‌یار به بازنویسی کل فرایند سفارش منجر نشود.

آیا استفاده هم‌زمان از چند درگاه مناسب است؟

داشتن درگاه پشتیبان می‌تواند دسترس‌پذیری را افزایش دهد، اما فقط زمانی مفید است که معماری نرم‌افزار برای آن آماده باشد.

سناریوهای استفاده:

• انتخاب دستی توسط کاربر
• انتخاب براساس سلامت سرویس
• انتقال خودکار به درگاه جایگزین
• تقسیم بار
• استفاده از درگاه اختصاصی برای گروه خاصی از سفارش‌ها
• جداسازی پرداخت B2B و B2C

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

همچنین انتقال خودکار نباید پس از آن انجام شود که وضعیت تراکنش اول نامشخص است؛ زیرا ممکن است مشتری در درگاه اول پرداخت کرده باشد ولی پاسخ نهایی به سایت نرسیده باشد.

مانیتورینگ و شاخص‌های عملکرد

صرفاً فعال‌بودن API به معنی سالم‌بودن تجربه پرداخت نیست. شاخص‌های زیر باید مانیتور شوند:

• نرخ ایجاد موفق توکن
• نرخ ورود کاربران به درگاه
• نرخ پرداخت موفق
• نرخ لغو توسط کاربر
• نرخ خطای Verify
• تعداد تراکنش‌های وضعیت نامشخص
• زمان پاسخ API
• زمان Verify
• نرخ Callback ناموفق
• تعداد پرداخت‌های تکراری
• تعداد مغایرت‌های مالی
• نرخ موفقیت به تفکیک ارائه‌دهنده
• نرخ موفقیت به تفکیک ساعت و دستگاه

برای نمونه، اگر توکن با موفقیت ایجاد شود اما تعداد زیادی از کاربران به Callback نرسند، مشکل ممکن است در تجربه کاربری یا ارتباط مرورگر باشد. اگر Callback دریافت شود ولی Verify شکست بخورد، باید وضعیت API و منطق Backend بررسی شود.

ثبت لاگ امن

لاگ پرداخت باید برای عیب‌یابی و حسابرسی کافی باشد، اما نباید اطلاعات حساس را افشا کند.

موارد قابل ثبت:

• شناسه داخلی سفارش
• شناسه داخلی تراکنش
• نام ارائه‌دهنده
• کد پاسخ
• زمان درخواست و پاسخ
• نتیجه Verify
• شناسه مرجع
• شناسه همبستگی یا Correlation ID

مواردی که نباید ثبت شوند:

• کلید API
• Merchant Secret
• رمز یا اطلاعات کارت
• توکن‌های محرمانه کامل
• داده هویتی غیرضروری
• پاسخ خام حاوی اطلاعات حساس

راهنمای رسمی ثبت رویدادهای امنیتی OWASP توصیه می‌کند برنامه کاربردی رویدادها را همراه با هویت، عملیات، نتیجه و زمینه لازم ثبت کند؛ درعین‌حال اطلاعات حساس نباید بدون ضرورت در لاگ قرار گیرند. (OWASP Cheat Sheet Series)

ملاحظات امنیتی درگاه مستقیم و واسط

از نظر اصول امنیت نرم‌افزار، تفاوت بنیادینی میان درگاه مستقیم و واسط وجود ندارد. در هر دو مدل، مسئولیت پیاده‌سازی صحیح بخش‌هایی بر عهده تیم توسعه است.

استفاده اجباری از HTTPS

تمام صفحات سفارش، Callback و APIهای داخلی باید از HTTPS استفاده کنند. کلیدها نیز باید در Secret Manager یا متغیرهای محیطی امن نگهداری شوند.

اعتماد نکردن به مرورگر

مبلغ، وضعیت پرداخت، شماره سفارش و نقش کاربر نباید از داده ارسالی مرورگر بدون کنترل سمت سرور پذیرفته شوند.

اعتبارسنجی Callback

روش HTTP، پارامترها، توکن، طول داده‌ها و فرمت مقادیر باید کنترل شوند. حتی اگر ارائه‌دهنده IPهای Callback را اعلام کند، محدودکردن IP نباید جایگزین Verify سمت سرور شود.

جلوگیری از Replay Attack

توکن‌ها، شناسه‌ها و Webhookها نباید امکان استفاده مجدد برای ثبت چندباره عملیات داشته باشند. Timestamp، Nonce، امضا و Unique Constraint از کنترل‌های مفید هستند.

امنیت افزونه‌های آماده

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

• آخرین تاریخ به‌روزرسانی
• سازگاری با نسخه سیستم
• نحوه ذخیره کلید
• اعتبارسنجی مبلغ
• Verify سمت سرور
• کنترل پرداخت تکراری
• آسیب‌پذیری‌های گزارش‌شده
• منبع انتشار افزونه

مسئولیت امنیت با برون‌سپاری حذف نمی‌شود

شورای استانداردهای امنیتی صنعت پرداخت تأکید می‌کند که استفاده از ارائه‌دهنده شخص ثالث، تمام مسئولیت امنیتی پذیرنده را حذف نمی‌کند؛ اتصال، تغییر مسیر و سامانه فروشگاه همچنان باید محافظت و نظارت شوند. این توصیه یک مرجع بین‌المللی امنیت پرداخت است و باید در کنار مقررات داخلی در نظر گرفته شود. (PCI Security Standards Council)

مثال‌های واقعی برای کسب‌وکارها

مثال اول: فروشگاه اینترنتی تازه‌تأسیس

فرض کنید یک فروشگاه محصولات دست‌ساز با روزانه ۱۰ تا ۳۰ سفارش در حال راه‌اندازی است. تیم کوچک است و هدف اصلی، انتشار سریع نسخه اولیه محسوب می‌شود.

انتخاب مناسب می‌تواند درگاه واسط باشد، زیرا:

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

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

مثال دوم: فروشگاه بزرگ با حجم بالای تراکنش

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

در این شرایط، درگاه مستقیم معمولاً مزایای بیشتری دارد:

• قرارداد سازمانی
• تعامل مستقیم با PSP
• امکان تعریف SLA
• گزارش‌گیری رسمی‌تر
• هماهنگی مستقیم در زمان اختلال
• تناسب با فرایندهای حسابداری سازمان

بااین‌حال، فروشگاه می‌تواند یک پرداخت‌یار را نیز به‌عنوان مسیر جایگزین یا ارائه‌دهنده ابزارهای خاص حفظ کند.

مثال سوم: نرم‌افزار اشتراکی SaaS

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

معیارهای مهم عبارت‌اند از:

• Webhook پایدار
• API استعلام
• Verify قابل‌اعتماد
• گزارش تسویه
• لینک پرداخت
• امکان پیگیری پرداخت‌های نامشخص
• مدیریت Retry

در این سناریو، کیفیت API و عملیات مالی از مستقیم یا واسط‌بودن مهم‌تر است.

مثال چهارم: بازارگاه چندفروشندگی

یک Marketplace مبلغ سفارش مشتری را دریافت و سهم چند فروشنده را محاسبه می‌کند.

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

در چنین پروژه‌ای باید ارائه‌دهنده‌ای انتخاب شود که سرویس قانونی تسهیم و گزارش‌های مرتبط را ارائه دهد. منطق تسهیم نیز باید در زمان ایجاد پرداخت، ثبت سفارش و تسویه کاملاً قابل حسابرسی باشد.

مثال پنجم: سامانه دریافت شهریه یا حق عضویت

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

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

• برای هر صورتحساب شناسه یکتا ایجاد شود.
• لینک پرداخت به همان صورتحساب متصل باشد.
• مبلغ سمت سرور تعیین شود.
• پس از Verify، بدهی کاهش یابد.
• شناسه مرجع در پرونده کاربر ذخیره شود.

درگاه مستقیم برای چه کسب‌وکارهایی مناسب‌تر است؟

درگاه مستقیم معمولاً برای شرایط زیر مناسب‌تر است:

• حجم تراکنش بالا
• ساختار سازمانی و مالی رسمی
• نیاز به قرارداد مستقیم با PSP
• وجود تیم فنی باتجربه
• نیاز به SLA و پشتیبانی سازمانی
• حساسیت بالا نسبت به کنترل پذیرندگی
• امکان صرف زمان برای فعال‌سازی
• نیاز به گزارش‌های رسمی PSP
• تمایل به کاهش وابستگی به پرداخت‌یار

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

درگاه واسط برای چه کسب‌وکارهایی مناسب‌تر است؟

درگاه واسط معمولاً برای شرایط زیر مناسب‌تر است:

• استارتاپ یا MVP
• فروشگاه کوچک و متوسط
• نیاز به راه‌اندازی سریع
• نبود تیم فنی بزرگ
• استفاده از فروشگاه‌ساز
• نیاز به لینک پرداخت
• نیاز به افزونه آماده
• نیاز به گزارش‌های ساده مدیریتی
• تراکنش‌های محدود یا متوسط
• نیاز به ابزارهای ارزش‌افزوده

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

چالش‌های مشترک هر دو مدل

تراکنش موفق و سفارش ناموفق

ممکن است پرداخت انجام شود، اما به دلیل خطای پایگاه داده یا سرویس داخلی، سفارش نهایی نشود. برای این وضعیت باید فرایند Recovery وجود داشته باشد.

سفارش موفق و کاهش موجودی ناموفق

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

وضعیت نامشخص

Timeout الزاماً به معنی ناموفق‌بودن پرداخت نیست. در وضعیت نامشخص باید از API استعلام، Webhook یا تطبیق گزارش استفاده شود.

مغایرت تسویه

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

بازگشت وجه

لغو سفارش با Refund یکسان نیست. ابتدا باید مشخص شود آیا مبلغ فقط پرداخت شده، تسویه شده یا قبلاً بازگردانده شده است.

بهترین روش‌ها برای انتخاب درگاه پرداخت

ابتدا نیازهای کسب‌وکار را مستند کنید

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

فقط قیمت را مقایسه نکنید

پایداری، API، پشتیبانی، کیفیت گزارش، زمان رفع مغایرت و هزینه توسعه از کارمزد اسمی مهم‌ترند.

مجوز را بررسی کنید

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

مستندات API را پیش از قرارداد ببینید

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

اتصال را Provider-Agnostic طراحی کنید

منطق فروشگاه را مستقیماً به SDK یا پاسخ‌های یک شرکت گره نزنید. Adapter و مدل خطای یکپارچه ایجاد کنید.

درگاه پشتیبان داشته باشید

برای کسب‌وکارهای حساس، استفاده از دو مسیر پرداخت می‌تواند مفید باشد؛ به شرط آنکه مدیریت وضعیت تراکنش به‌درستی انجام شود.

تطبیق مالی را خودکار کنید

هر روز تراکنش‌های موفق، برگشتی، نامشخص و تسویه‌شده را با گزارش ارائه‌دهنده مقایسه کنید.

تست‌های خودکار بنویسید

سناریوهای ضروری:

• پرداخت موفق
• لغو توسط کاربر
• Verify ناموفق
• Timeout
• Callback تکراری
• Verify تکراری
• مغایرت مبلغ
• خطای پایگاه داده
• پرداخت هم‌زمان
• Refund
• قطع سرویس پیامک یا حسابداری

برنامه مدیریت اختلال تعریف کنید

در زمان قطعی باید مشخص باشد:

• چه پیامی به کاربر نمایش داده می‌شود؟
• آیا درگاه جایگزین فعال می‌شود؟
• تراکنش نامشخص چگونه بررسی می‌شود؟
• تیم پشتیبانی چه گزارشی دریافت می‌کند؟
• سفارش تا چه زمانی رزرو می‌ماند؟

اشتباهات رایج در اتصال درگاه

اعتماد به پارامتر Status

ممکن است Callback دارای پارامتر موفقیت باشد، اما بدون Verify نباید سفارش پرداخت‌شده تلقی شود.

تغییر وضعیت فقط در Frontend

هیچ عملیات مالی قطعی نباید صرفاً در JavaScript مرورگر انجام شود.

ذخیره کلید در مخزن کد

کلیدها باید خارج از Repository و در Secret Management نگهداری شوند.

نداشتن شناسه داخلی تراکنش

شناسه ارائه‌دهنده جای شناسه داخلی سیستم را نمی‌گیرد. هر دو باید ذخیره شوند.

یکی‌گرفتن سفارش و تراکنش

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

نبود Unique Constraint

بررسی نرم‌افزاری به‌تنهایی برای جلوگیری از ثبت دوباره کافی نیست. محدودیت پایگاه داده نیز لازم است.

نمایش پیام مبهم

کاربر باید بداند مبلغ از حساب او کم شده، پرداخت ناموفق بوده یا وضعیت نیازمند بررسی است.

چک‌لیست انتخاب درگاه

پیش از تصمیم نهایی، این پرسش‌ها را پاسخ دهید:

• ارائه‌دهنده در فهرست رسمی شرکت‌های مجاز قرار دارد؟
• مدارک و فرایند فعال‌سازی چیست؟
• ساختار هزینه و کارمزد چگونه است؟
• زمان و نحوه تسویه چیست؟
• محیط آزمایشی ارائه می‌شود؟
• مستندات API کامل است؟
• Webhook و API استعلام وجود دارد؟
• بازگشت وجه پشتیبانی می‌شود؟
• تسهیم وجوه وجود دارد؟
• پشتیبانی در روزهای تعطیل چگونه است؟
• SLA مشخص ارائه می‌شود؟
• گزارش تسویه قابل دریافت است؟
• وضعیت اختلال‌ها اعلام می‌شود؟
• افزونه‌ها به‌روز و امن هستند؟
• مهاجرت به ارائه‌دهنده دیگر چقدر هزینه دارد؟
• داده‌های تراکنش تا چه مدت نگهداری می‌شوند؟
• روش رسیدگی به مغایرت چیست؟
• آیا امکان داشتن چند ترمینال وجود دارد؟

پرسش‌های متداول

۱. درگاه پرداخت مستقیم بهتر است یا واسط؟

پاسخ به اندازه و نیاز کسب‌وکار بستگی دارد. درگاه مستقیم برای ساختارهای سازمانی و پرتراکنش مناسب‌تر است؛ درحالی‌که درگاه واسط معمولاً راه‌اندازی سریع‌تر و ابزارهای جانبی بیشتری ارائه می‌دهد.

۲. آیا درگاه واسط امن است؟

اگر ارائه‌دهنده مجاز باشد و اتصال فنی به‌درستی پیاده‌سازی شود، درگاه واسط می‌تواند امن باشد. مجوز شرکت، Verify سمت سرور، نگهداری امن کلیدها و مدیریت تراکنش تکراری باید بررسی شوند.

۳. آیا برای درگاه مستقیم به برنامه‌نویس نیاز داریم؟

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

۴. آیا درگاه واسط بدون احراز هویت فعال می‌شود؟

درگاه واسط مجاز نیز ملزم به شناسایی پذیرنده و رعایت ضوابط شبکه پرداخت است. وعده پرداخت ناشناس یا بدون احراز هویت باید با احتیاط جدی بررسی شود.

۵. آیا درگاه واسط همیشه کارمزد دارد؟

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

۶. تسویه درگاه مستقیم سریع‌تر است؟

الزاماً خیر. نحوه و زمان‌بندی تسویه تابع مقررات جاری، قرارداد و ساختار سرویس است. شرایط باید به‌صورت مکتوب بررسی شود.

۷. آیا می‌توان هم‌زمان درگاه مستقیم و واسط داشت؟

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

۸. Callback موفق به معنی پرداخت موفق است؟

خیر. Callback فقط بازگشت کاربر یا ارسال نتیجه اولیه است. پرداخت باید از سمت سرور با API ارائه‌دهنده Verify شود.

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

سیستم باید تراکنش را استعلام کند. اگر پرداخت موفق بوده باشد، سفارش بازیابی و تکمیل می‌شود. اگر تراکنش ناموفق باشد، بازگشت وجه مطابق فرایند شبکه و ارائه‌دهنده انجام می‌شود.

۱۰. چگونه از ثبت دوباره سفارش جلوگیری کنیم؟

از Idempotency، قفل پایگاه داده، Unique Constraint، بررسی وضعیت تراکنش و شناسه مرجع یکتا استفاده کنید.

۱۱. آیا افزونه آماده درگاه کافی است؟

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

۱۲. درگاه مناسب مارکت‌پلیس چیست؟

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

۱۳. برای اپلیکیشن موبایل چگونه درگاه متصل کنیم؟

ایجاد تراکنش و Verify باید در Backend انجام شود. اپلیکیشن فقط کاربر را به صفحه پرداخت هدایت و نتیجه نمایشی را از سرور دریافت می‌کند.

۱۴. آیا تغییر درگاه در آینده دشوار است؟

اگر منطق پرداخت مستقیماً به API یک شرکت متصل شده باشد، تغییر دشوار است. استفاده از Adapter Pattern و مدل داده مستقل مهاجرت را ساده‌تر می‌کند.

۱۵. مهم‌ترین معیار فنی انتخاب درگاه چیست؟

کیفیت Verify، مستندات API، مدیریت وضعیت نامشخص، گزارش تسویه، پشتیبانی و پایداری سرویس از مهم‌ترین معیارها هستند.

جمع‌بندی

پاسخ به پرسش «درگاه پرداخت مستقیم یا واسط؟» برای همه کسب‌وکارها یکسان نیست. درگاه مستقیم، ارتباط قراردادی مستقیم‌تر، کنترل سازمانی و تناسب بیشتری با کسب‌وکارهای بزرگ و پرتراکنش دارد. درگاه واسط معمولاً فعال‌سازی سریع‌تر، API ساده‌تر و امکانات تکمیلی بیشتری در اختیار استارتاپ‌ها و فروشگاه‌های کوچک و متوسط قرار می‌دهد.

بااین‌حال، موفقیت پرداخت اینترنتی بیشتر از نام ارائه‌دهنده به کیفیت معماری نرم‌افزار وابسته است. ایجاد سفارش پیش از پرداخت، Verify سمت سرور، کنترل مبلغ، جلوگیری از ثبت تکراری، ثبت شناسه مرجع، مدیریت وضعیت نامشخص و تطبیق تسویه از الزامات هر پیاده‌سازی حرفه‌ای هستند.

کسب‌وکارهایی که رشد آینده را در نظر دارند، بهتر است لایه پرداخت خود را مستقل از ارائه‌دهنده طراحی کنند. در این مدل می‌توان بدون بازنویسی فرایند سفارش، درگاه مستقیم، پرداخت‌یار یا مسیر پشتیبان جدیدی به سامانه افزود.

دریافت مشاوره طراحی و اتصال درگاه پرداخت

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

تیم اسمارتی اپ (SmartyApp) در زمینه طراحی سایت، تولید نرم‌افزار اختصاصی و برنامه‌نویسی سامانه‌های تحت وب، امکان تحلیل معماری پرداخت، توسعه اتصال چنددرگاهی، مدیریت تراکنش و یکپارچه‌سازی با سیستم‌های مالی را فراهم می‌کند.

برای بررسی نیازهای پروژه و انتخاب میان درگاه پرداخت مستقیم یا واسط، با اسمارتی اپ (SmartyApp)تماس بگیرید و درخواست جلسه مشاوره فنی ثبت کنید.

منابع رسمی

1. وب‌سایت رسمی شرکت شاپرک و فهرست فعالان مجاز شبکه پرداخت
2. معرفی رسمی شرکت شاپرک و نقش آن در شبکه پرداخت
3. سیاست بانک مرکزی درباره فناوری مالی و ضوابط پرداخت‌یاران
4. ضوابط و فرایند اجرایی فعالیت پرداخت‌یاران در وب‌سایت بانک مرکزی
5. راهنمای OWASP برای اتصال امن درگاه پرداخت شخص ثالث
6. راهنمای OWASP برای امنیت و مجوزدهی تراکنش‌ها
7. راهنمای OWASP برای ثبت امن رویدادهای نرم‌افزار
8. منابع رسمی امنیت پذیرندگان در PCI Security Standards Council
9. راهنمای امنیت پرداخت تجارت الکترونیکی PCI SSC
10. سامانه رسمی نماد اعتماد الکترونیکی