مقدمه: انتخابی که فقط مالی نیست

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

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

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

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

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

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

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

این جداسازی مهم است: بازگشت کاربر به سایت به معنی قطعی بودن پرداخت نیست. مرورگر و پارامترهای Callback قابل اعتماد کامل نیستند. راهنمای رسمی یکپارچه‌سازی امن درگاه پرداخت شخص ثالث در OWASP نیز توصیه می‌کند مبلغ در سمت سرور محاسبه شود، وضعیت پرداخت از API درگاه تأیید گردد و پردازش تراکنش در برابر تکرار، Idempotent باشد.

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

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

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

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

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

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

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

اصطلاح «واسط» نباید با «غیرمجاز» یا «ناامن» یکی دانسته شود. معیار اصلی، وضعیت قانونی و قراردادی ارائه‌دهنده و ثبت صحیح پذیرنده در شبکه است. برای کنترل وضعیت شرکت‌ها، اطلاعیه‌ها و فهرست‌های جاری باید به وب‌سایت رسمی شبکه الکترونیکی پرداخت کارت (شاپرک) مراجعه کرد و صرفاً به نشان یا ادعای درج‌شده در سایت ارائه‌دهنده اکتفا نکرد.

پرداخت‌یار چه نقشی دارد؟

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

تفاوت PSP، پرداخت‌یار و بانک

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

بانک

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

PSP

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

پرداخت‌یار

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

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

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

مقایسه مالی: کارمزد، تسویه و هزینه پنهان

کارمزد را چگونه مقایسه کنیم؟

تمرکز صرف بر درصد کارمزد می‌تواند گمراه‌کننده باشد. هزینه کل مالکیت یا TCO را در یک بازه شش‌ماهه یا یک‌ساله محاسبه کنید:

هزینه کل = کارمزد تراکنش + هزینه توسعه + نگهداری + عملیات مالی + هزینه قطعی + هزینه مهاجرت + هزینه خدمات مکمل

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

تسویه فقط «زمان واریز» نیست

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

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

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

هزینه قطعی و نرخ تبدیل

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

مقایسه فنی API و تجربه توسعه

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

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

در پروژه‌های اختصاصی اسمارتی اپ (SmartyApp)، ارزیابی اتصال پرداخت فقط با «ارسال موفق یک تراکنش آزمایشی» پایان نمی‌یابد؛ سناریوهای قطع شبکه، بازگشت دیرهنگام، Callback تکراری، پرداخت موفق با پاسخ نامشخص و مغایرت مبلغ نیز باید آزمایش شوند.

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

وضعیت سفارش را از وضعیت پرداخت جدا نگه دارید. برای نمونه:

• وضعیت پرداخت: pending، paid، failed، expired، refunded؛
• وضعیت سفارش: draft، confirmed، processing، shipped، cancelled.

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

قابلیت تعویض ارائه‌دهنده

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

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

• createPayment(order, amount)؛
• verifyPayment(token, expectedAmount)؛
• queryPayment(reference)؛
• refundPayment(...) در صورت پشتیبانی؛
• تبدیل خطاهای اختصاصی به خطاهای استاندارد داخلی.

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

امنیت درگاه پرداخت: نوع درگاه کافی نیست

مبلغ را از مرورگر قبول نکنید

مبلغ نهایی باید در Backend و با قیمت، تخفیف، مالیات، موجودی و هزینه ارسال معتبر محاسبه شود. ارسال مبلغ محاسبه‌شده در JavaScript یا فیلد مخفی، امکان دست‌کاری دارد. کاربر فقط شناسه سبد یا سفارش را ارسال می‌کند؛ سرور مبلغ را تولید می‌کند.

Callback را معادل تأیید ندانید

مهاجم می‌تواند URL بازگشت را با پارامتر ساختگی فراخوانی کند. سرور باید با توکن تراکنش به API درگاه متصل شود، وضعیت قطعی را بگیرد و مبلغ و سفارش را تطبیق دهد. توصیه OWASP نیز صریحاً بر Verify سروربه‌سرور، اعتبارسنجی اصالت Callback و عدم اعتماد به پارامتر بازگشت مرورگر تأکید دارد.

پردازش باید Idempotent باشد

اگر Callback دو یا چند بار برسد، نباید سفارش دوباره ثبت، کیف پول دوباره شارژ یا کالا دوباره ارسال شود. برای شماره مرجع یا شناسه قطعی تراکنش یک Unique Index ایجاد کنید و تغییر وضعیت و ثبت آثار مالی را در تراکنش پایگاه داده انجام دهید.

یک الگوی امن:

1. رکورد پرداخت را با قفل مناسب بخوانید؛
2. اگر قبلاً قطعی شده، همان نتیجه موفق قبلی را برگردانید؛
3. Verify را انجام دهید؛
4. مبلغ، شناسه و وضعیت را تطبیق دهید؛
5. شماره مرجع یکتا را ذخیره کنید؛
6. پرداخت و سفارش را در یک تراکنش اتمیک به‌روزرسانی کنید؛
7. عملیات جانبی مانند پیامک را پس از Commit به صف بسپارید.

اطلاعات کارت را ذخیره نکنید

در اتصال Redirect استاندارد، اطلاعات حساس کارت باید در صفحه امن پرداخت وارد شود و نرم‌افزار فروشگاه نباید شماره کامل کارت، CVV2، رمز یا داده‌های احراز هویت را دریافت یا ذخیره کند. استاندارد رسمی PCI DSS برای حفاظت از داده‌های پرداخت مجموعه الزامات فنی و عملیاتی پایه را برای سازمان‌هایی که داده دارنده کارت را ذخیره، پردازش یا منتقل می‌کنند بیان می‌کند. حتی اگر صفحه پرداخت خارج از سایت شماست، امنیت حساب‌های مدیریتی، کلیدهای API، لاگ‌ها و سرور همچنان مسئولیت مهم کسب‌وکار است.

لاگ، مانیتورینگ و هشدار

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

الزامات حقوقی، هویتی و مالیاتی

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

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

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

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

رابطه و کنترل قراردادی مستقیم‌تر

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

مناسب برای مقیاس بالا

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

هویت روشن پذیرنده

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

کاهش وابستگی به مدل تجاری واسط

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

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

فرایند شروع و هماهنگی بیشتر

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

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

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

مسئولیت بیشتر تیم فنی

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

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

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

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

خدمات جانبی آماده

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

تجربه پشتیبانی محصول‌محور

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

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

کارمزد خدمات

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

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

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

شرایط تسویه و ریسک

فرایند تسویه و بررسی مغایرت یا ریسک باید دقیقاً مطالعه شود. برداشت‌های تبلیغاتی مانند «تسویه فوری» را جایگزین بندهای قرارداد و محدودیت‌های عملیاتی نکنید.

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

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

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

مثال دوم: فروشگاه اینترنتی با رشد سریع

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

مثال سوم: مارکت‌پلیس چندفروشنده

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

مثال چهارم: سامانه خدمات سازمانی

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

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

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

درگاه مستقیم بهتر است یا واسط؟ چارچوب تصمیم‌گیری

برای انتخاب، به هر معیار از یک تا پنج امتیاز اهمیت بدهید و سپس گزینه‌ها را ارزیابی کنید:

1. سرعت موردنیاز برای راه‌اندازی؛
2. تعداد و ارزش ماهانه تراکنش‌ها؛
3. حساسیت کسب‌وکار به کارمزد؛
4. نیاز به لینک پرداخت یا تسهیم؛
5. توان تیم فنی و مالی؛
6. نیاز به SLA و پشتیبانی سازمانی؛
7. اهمیت کنترل مستقیم قراردادی؛
8. نیاز به چنددرگاهی و تداوم خدمت؛
9. کیفیت API، Sandbox و مستندات؛
10. امکان خروج داده و مهاجرت.

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

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

پیش از قرارداد یک چک‌لیست تجاری داشته باشید

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

پیش از انتشار آزمون فنی انجام دهید

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

یک دفتر تراکنش داخلی بسازید

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

اسرار را مدیریت کنید

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

برنامه جایگزین طراحی کنید

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

مسیر مهاجرت از درگاه واسط به مستقیم

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

1. ساخت لایه Adapter مستقل از ارائه‌دهنده؛
2. استانداردسازی وضعیت‌ها و کدهای خطا؛
3. اتصال درگاه مستقیم در محیط آزمایشی؛
4. اجرای تست‌های امنیتی و سناریوهای خطا؛
5. فعال‌سازی محدود برای درصدی از تراکنش‌ها؛
6. مقایسه نرخ موفقیت و مغایرت دو سرویس؛
7. افزایش تدریجی ترافیک؛
8. نگه‌داشتن مسیر قبلی تا تعیین تکلیف تمام تراکنش‌های باز؛
9. آرشیو گزارش‌ها و مستندکردن عملیات پشتیبانی.

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

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

موفق دانستن سفارش بر اساس URL بازگشت

این خطرناک‌ترین اشتباه است. نتیجه باید از API و سمت سرور Verify شود.

یکی گرفتن شماره سفارش و شماره مرجع بانکی

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

نداشتن وضعیت Pending واقعی

گاهی مبلغ کسر می‌شود اما پاسخ نهایی به سایت نمی‌رسد. ثبت فوری «ناموفق» می‌تواند پشتیبانی و حسابداری را دچار خطا کند. این وضعیت باید تا استعلام یا تعیین تکلیف، Pending بماند.

ارسال پیامک و عملیات سنگین داخل Callback

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

وابستگی کامل به یک SDK

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

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

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

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

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

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

۳. آیا برای درگاه مستقیم حتماً شرکت ثبت‌شده لازم است؟

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

۴. آیا اینماد برای دریافت درگاه لازم است؟

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

۵. کدام درگاه کارمزد کمتری دارد؟

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

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

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

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

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

۸. درگاه واسط برای فروشگاه وردپرسی مناسب است؟

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

۹. پس از Callback چه زمانی سفارش را پرداخت‌شده کنیم؟

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

۱۰. اگر مشتری پرداخت کرد ولی به سایت برنگشت چه کنیم؟

سامانه باید وب‌هوک معتبر یا Job استعلام دوره‌ای داشته باشد. سفارش Pending را با API ارائه‌دهنده تعیین تکلیف کنید و صرفاً به بازگشت مرورگر وابسته نباشید.

۱۱. Idempotency در پرداخت یعنی چه؟

یعنی تکرار یک درخواست یا Callback، نتیجه مالی را دوباره اعمال نکند. یک پرداخت موفق باید حداکثر یک بار سفارش را قطعی یا کیف پول را شارژ کند.

۱۲. آیا باید اطلاعات کارت مشتری را در سایت ذخیره کنیم؟

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

۱۳. برای مارکت‌پلیس کدام مدل مناسب‌تر است؟

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

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

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

۱۵. مهم‌ترین شاخص ارزیابی درگاه چیست؟

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

جمع‌بندی

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

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

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

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

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

منابع رسمی

• وب‌سایت رسمی شبکه الکترونیکی پرداخت کارت (شاپرک)
• سامانه رسمی نماد اعتماد الکترونیکی
• درگاه ملی خدمات الکترونیک سازمان امور مالیاتی
• راهنمای OWASP برای یکپارچه‌سازی امن درگاه پرداخت شخص ثالث
• استاندارد امنیت داده صنعت پرداخت PCI DSS