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

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

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

در این مرحله معمولاً با دو مفهوم مواجه می‌شویم:

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

و

درگاه پرداخت واسط

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

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

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

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

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

مشتری
   ↓
فروشگاه اینترنتی
   ↓
درگاه پرداخت مستقیم
   ↓
شبکه پرداخت
   ↓
بانک

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

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

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

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

ساختار کلی به این شکل است:

مشتری
   ↓
فروشگاه اینترنتی
   ↓
درگاه واسط
   ↓
شبکه پرداخت
   ↓
بانک

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

تفاوت اصلی درگاه مستقیم و واسط چیست؟

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

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

اما در درگاه واسط، یک سرویس دیگر این ارتباط را مدیریت می‌کند.

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

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

ویژگیدرگاه مستقیمدرگاه واسطنوع اتصالمستقیماز طریق سرویس واسطفرآیند دریافتمعمولاً نیازمند طی مراحل مربوط به ارائه‌دهندهمعمولاً ساده‌ترراه‌اندازیممکن است زمان‌برتر باشدمعمولاً سریع‌ترکنترل فنیبیشتروابسته به API واسطمدیریت تراکنشتوسط ارائه‌دهندهتوسط واسط و ارائه‌دهندهتسویهطبق سازوکار ارائه‌دهندهطبق سازوکار واسطگزارش‌گیریوابسته به سرویس ارائه‌دهندهمعمولاً متمرکزترپشتیبانیارائه‌دهنده درگاهشرکت واسطوابستگی به سرویس واسطندارددارد

فرآیند پرداخت در فروشگاه چگونه انجام می‌شود؟

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

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

ابتدا فروشگاه یک سفارش ایجاد می‌کند.

Order
├── User
├── Products
├── Amount
├── Shipping
└── Status

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

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

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

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

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

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

چرا Callback به‌تنهایی کافی نیست؟

یکی از اشتباهات رایج در پیاده‌سازی سیستم پرداخت این است که برنامه‌نویس صرفاً براساس Callback وضعیت سفارش را تغییر دهد.

مثلاً:

کاربر برگشت
      ↓
Payment = Success
      ↓
Order = Paid

این منطق به‌تنهایی کافی نیست.

فروشگاه باید تراکنش را طبق API و فرآیند تأیید سرویس پرداخت بررسی و Verify کند.

منطق صحیح‌تر:

Payment Request
      ↓
Gateway
      ↓
Customer Payment
      ↓
Callback
      ↓
Verify Transaction
      ↓
Payment Confirmed
      ↓
Order = Paid

بنابراین Callback و Verify دو مفهوم متفاوت هستند.

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

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

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

همچنین در معماری مستقیم، تیم فنی مستقیماً با API و مستندات ارائه‌دهنده سرویس کار می‌کند.

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

معایب درگاه مستقیم

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

همچنین تیم فنی باید مستندات سرویس ارائه‌دهنده را بررسی کرده و فرآیندهایی مانند:

• ایجاد تراکنش

• Redirect

• Callback

• Verify

• مدیریت خطا

• استعلام

• Refund یا فرآیندهای مرتبط، در صورت پشتیبانی

را به شکل صحیح پیاده‌سازی کند.

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

مزایای درگاه واسط چیست؟

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

یکی از مهم‌ترین مزیت‌های آن، سادگی راه‌اندازی است.

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

این موضوع مخصوصاً زمانی مفید است که یک کسب‌وکار بخواهد سریع MVP خود را راه‌اندازی کند.

یک API مشترک چه مزیتی دارد؟

فرض کنید فروشگاه شما از یک سرویس واسط استفاده می‌کند.

در این حالت ممکن است API یکپارچه‌ای داشته باشید که فرآیندهایی مانند:

Create Payment
Verify Payment
Inquiry
Refund
Settlement

را در یک ساختار مشخص ارائه کند.

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

این موضوع می‌تواند توسعه و نگهداری سیستم را ساده‌تر کند.

معایب درگاه واسط

درگاه واسط یک مزیت مهم دارد، اما یک وابستگی نیز ایجاد می‌کند.

فروشگاه شما به سرویس واسط وابسته می‌شود.

یعنی در معماری سیستم، یک لایه دیگر اضافه شده است:

Application
     ↓
Payment Provider
     ↓
Payment Network

در نتیجه باید مواردی مانند:

• SLA سرویس

• کیفیت API

• پشتیبانی

• وضعیت سرویس

• فرآیند تسویه

• کارمزد

• محدودیت‌های API

• مستندات

را نیز بررسی کنید.

موضوع مهم‌تر: تسویه

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

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

باید مشخص شود:

• تسویه چه زمانی انجام می‌شود؟

• تسویه به چه حسابی انجام می‌شود؟

• آیا تسویه به‌صورت دوره‌ای انجام می‌شود؟

• کارمزد چگونه محاسبه می‌شود؟

• وضعیت تراکنش‌های ناموفق چگونه مدیریت می‌شود؟

• در صورت مغایرت تراکنش چه فرآیندی وجود دارد؟

این موارد باید قبل از انتخاب سرویس بررسی شوند.

کارمزد؛ مستقیم همیشه به معنی ارزان‌تر نیست

یکی از برداشت‌های اشتباه این است که:

درگاه مستقیم = بدون هزینه

و:

درگاه واسط = هزینه بیشتر

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

ممکن است یک سرویس واسط بابت خدمات خود کارمزد دریافت کند، اما در مقابل امکاناتی مانند:

• API یکپارچه

• گزارش‌گیری

• مدیریت تراکنش

• پشتیبانی

• ابزارهای مدیریتی

• دسترسی به چند مسیر پرداخت

را ارائه دهد.

بنابراین نباید فقط قیمت را معیار تصمیم‌گیری قرار داد.

امنیت درگاه پرداخت

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

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

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

اما امنیت فقط به صفحه پرداخت محدود نیست.

مواردی مانند:

• HTTPS

• اعتبارسنجی مبلغ

• جلوگیری از تغییر Order ID

• جلوگیری از Replay

• Verify سمت Server

• مدیریت صحیح Callback

• Idempotency

• ثبت Log مناسب

• کنترل وضعیت سفارش

نیز اهمیت دارند.

Idempotency چرا مهم است؟

فرض کنید مشتری روی دکمه پرداخت چند بار کلیک کند.

اگر سیستم شما برای هر درخواست بدون کنترل، یک تراکنش جدید ایجاد کند، ممکن است مشکلاتی ایجاد شود.

یک معماری مناسب باید بتواند تشخیص دهد که یک سفارش یا Payment Intent قبلاً برای پرداخت پردازش شده است.

به‌صورت مفهومی:

Order #1024
      ↓
Payment Intent
      ↓
Gateway

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

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

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

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

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

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

در این حالت درگاه مستقیم نیز می‌تواند گزینه‌ای قابل بررسی باشد.

بنابراین انتخاب باید براساس شرایط واقعی کسب‌وکار انجام شود، نه صرفاً نام «مستقیم» یا «واسط».

در یک پروژه حرفه‌ای چه چیزی مهم‌تر از نوع درگاه است؟

گاهی تمرکز بیش از حد روی انتخاب درگاه باعث می‌شود بخش مهم‌تری فراموش شود:

معماری Payment در خود Application.

در یک فروشگاه حرفه‌ای بهتر است Payment از Order جدا باشد.

برای مثال:

Order
 └── Payment
      ├── Amount
      ├── Status
      ├── Authority
      ├── ReferenceId
      ├── CreatedAt
      └── VerifiedAt

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

وضعیت‌های پرداخت را دقیق طراحی کنید

بهتر است Payment فقط دو وضعیت:

Success
Failed

نداشته باشد.

در یک سیستم واقعی ممکن است وضعیت‌هایی مانند این‌ها لازم باشند:

Pending
Redirected
Processing
Paid
Failed
Canceled
Expired
VerificationFailed
Refunded

نام دقیق وضعیت‌ها به معماری پروژه بستگی دارد، اما اصل مهم این است که Payment یک State Machine مستقل داشته باشد.

جمع‌بندی

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

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

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

در نهایت، انتخاب درگاه نباید فقط براساس «مستقیم یا واسط بودن» انجام شود.

مواردی مانند:

امنیت، API، پایداری، تسویه، کارمزد، پشتیبانی، مقیاس‌پذیری و نیازهای واقعی کسب‌وکار

باید در کنار یکدیگر بررسی شوند.

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

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