درگاه مستقیم و پرداختیاری در قرارداد، اتصال فنی، پایداری، گزارشگیری، تسویه و عملیات پس از پرداخت و موارد کلید دیگر تفاوت دارند. این راهنما با مقایسه دقیق دو مدل، سناریوهای مناسب، هزینههای پنهان، الزامات امنیتی و چکلیست تصمیمگیری کمک میکند مسیر متناسب با ساختار کسبوکار خود را انتخاب کنید.
انتخاب میان درگاه پرداخت مستقیم و پرداختیاری فقط انتخاب یک صفحه پرداخت نیست؛ تصمیمی درباره معماری پرداخت، تقسیم مسئولیت، جریان نقدی، پشتیبانی و میزان کاری است که تیمهای فنی و مالی باید در داخل کسبوکار انجام دهند. ممکن است دو سرویس در پرداخت عادی تجربهای مشابه برای مشتری بسازند، اما تفاوت آنها هنگام اختلال، مغایرت، استرداد وجه، تغییر PSP یا افزایش حجم تراکنش آشکار میشود.
پاسخ کوتاه این است که هیچیک برای همه کسبوکارها برتر نیستند. درگاه مستقیم برای بعضی تیمها کنترل و رابطه مستقیمتری با PSP ایجاد میکند؛ پرداختیاری میتواند اتصال و بخشی از عملیات پرداخت را در یک لایه متمرکزتر قرار دهد. نتیجه درست فقط با بررسی قرارداد و امکانات واقعی ارائهدهنده به دست میآید، نه با برچسب «مستقیم» یا «غیرمستقیم». برای شناخت اجزای پایه این جریان، ابتدا راهنمای درگاه پرداخت اینترنتی را بخوانید.
درگاه مستقیم یا پرداختیاری؛ کدامیک مناسبتر است؟
اگر نیاز اصلی کسبوکار داشتن یک ترمینال از یک PSP، رابطه قراردادی مستقیمتر و مدیریت داخلی اتصال و عملیات باشد، درگاه مستقیم میتواند گزینه قابل بررسی باشد. اگر کسبوکار میخواهد با یک اتصال، ابزارهای متمرکزتری برای مشاهده تراکنش، پشتیبانی، گزارشگیری، اتصال به چند مسیر یا خدمات پس از پرداخت داشته باشد، پرداختیاری میتواند تناسب بیشتری ایجاد کند.
این پاسخ همچنان قطعی نیست. سرعت فعالسازی، کارمزد، برنامه تسویه، تعداد PSPهای قابل استفاده، کیفیت مستندات و امکانات پنل میان ارائهدهندگان متفاوت است. بنابراین عبارتهایی مانند «درگاه مستقیم همیشه ارزانتر است» یا «پرداختیاری همیشه سریعتر راهاندازی میشود» نباید بدون مشاهده شرایط همان سرویس مبنای تصمیم قرار گیرند.
پرسش درست این نیست که کدام مدل در حالت کلی بهتر است؛ پرسش درست این است که در هر مدل، چه بخشی از کار و ریسک در داخل کسبوکار باقی میماند و چه بخشی را ارائهدهنده مدیریت میکند.
درگاه پرداخت مستقیم چیست؟
در مدل مستقیم، پذیرنده فرایند دریافت ترمینال و همکاری را با یک شرکت ارائهدهنده خدمات پرداخت یا PSP طی میکند و اتصال خود را بر پایه مستندات همان شرکت پیادهسازی میکند. شرایط پذیرش، قرارداد، دسترسی فنی، گزارشها، پشتیبانی و تسویه باید از همان PSP بررسی شوند.
مستقیمبودن به این معنا نیست که همه اجزای شبکه پرداخت حذف میشوند یا کسبوکار مستقیماً به بانک صادرکننده کارت متصل است. این واژه بیشتر نوع رابطه پذیرنده و ارائهدهنده درگاه را توصیف میکند. جزئیات این مدل در راهنمای درگاه پرداخت مستقیم آمده است.
پرداختیاری چیست؟
در مدل پرداختیاری، کسبوکار خدمات درگاه را از پرداختیار دریافت میکند. پرداختیار با اتکا به زیرساخت PSPهای همکار، لایهای برای پذیرش، اتصال فنی و مدیریت بخشی از عملیات پرداخت فراهم میکند. دامنه خدمات ممکن است از ارائه API و پنل تراکنش تا گزارشگیری، مسیردهی، پیگیری، استرداد یا ابزارهای مالی مکمل متفاوت باشد.
پرداختیار جایگزین منطق سفارش و کنترلهای داخلی کسبوکار نیست. پذیرنده همچنان باید تراکنش را سمت سرور تأیید کند، سفارش را فقط یک بار نهایی کند و وضعیتهای نامشخص را مدیریت کند. برای شناخت کامل این مدل، مقاله پرداختیار چیست را ببینید.
تفاوت درگاه مستقیم و پرداختیاری در یک جدول
این جدول جهت کلی مقایسه را نشان میدهد. هر ردیف باید با قرارداد، مستندات فنی و سطح خدمت ارائهدهنده انتخابی تطبیق داده شود.
| معیار مقایسه | درگاه مستقیم | پرداختیاری |
| رابطه قراردادی | مستقیم با PSP | از مسیر پرداختیار |
| پذیرش و راهاندازی | طبق فرایند PSP؛ برای هر مسیر جداگانه | متمرکزتر؛ تابع شرایط پرداختیار |
| اتصال فنی | API هر PSP؛ نگهداری جداگانه | API پرداختیار؛ مدیریت مسیرها در صورت پشتیبانی |
| چند PSP و پایداری | اتصال و مسیردهی بر عهده کسبوکار | ممکن است متمرکز ارائه شود |
| گزارش و مغایرت | گزارش هر PSP یا ابزار داخلی | امکان گزارش متمرکز بسته به سرویس |
| استرداد و پس از پرداخت | تابع PSP یا توسعه داخلی | ممکن است یکپارچه ارائه شود |
| تسویه | طبق قرارداد PSP | طبق قرارداد پرداختیار و سرویس |
| هزینه کل | توسعه و عملیات داخلی بیشتر محتمل است | هزینه سرویس در برابر کاهش بخشی از عملیات |
| پشتیبانی | ارتباط مستقیم با PSP | پرداختیار نقطه اصلی پیگیری است |
| تناسب | تیم دارای زیرساخت و نیاز به کنترل مستقیم | تیم نیازمند تمرکز و ابزارهای عملیاتی |
وجود یک قابلیت در جدول خدمات بهمعنای تناسب آن با فرایند واقعی شما نیست. پیش از تصمیم، باید سطح دسترسی، محدودیتها، هزینه، زمان پاسخگویی و امکان استفاده از آن قابلیت در محیط عملیاتی بررسی شود.
تفاوتهای کلیدی درگاه مستقیم و پرداختیاری
برای انتخاب میان درگاه پرداخت مستقیم و درگاه پرداختیاری آشنایی با تفاوتهای کلیدی هر یک ضروری است. در ادامه تفاوتهای این دو درگاه پرداخت را بررسی کردهایم.
۱. نوع رابطه و قرارداد
در درگاه مستقیم، پذیرنده با PSP وارد فرایند پذیرش و همکاری میشود. مکاتبات مربوط به ترمینال، دسترسی فنی و پشتیبانی نیز در همان مسیر انجام میشوند. اگر کسبوکار از چند PSP استفاده کند، ممکن است قراردادها، دسترسیها و هماهنگیهای جداگانهای داشته باشد.
در پرداختیاری، نقطه اصلی ارتباط پذیرنده، پرداختیار است و جزئیات رابطه با زیرساختهای پرداخت در چارچوب سرویس او مدیریت میشود؛ بااینحال، قرارداد باید روشن کند هر طرف در پذیرش، نگهداری داده، تسویه، استرداد، پیگیری مغایرت و پاسخگویی به رخدادها چه مسئولیتی دارد.
۲. مسیر پذیرش و زمان راهاندازی
هر دو مدل به احراز هویت، بررسی فعالیت و ارائه اطلاعات لازم نیاز دارند. نوع مدارک، مراحل بررسی و زمان فعالسازی میتواند براساس نوع فعالیت، وضعیت حقوقی، کاملبودن اطلاعات و رویه ارائهدهنده تغییر کند.
پرداختیاری ممکن است ثبتنام و تبادل اطلاعات را متمرکزتر کند؛ درگاه مستقیم نیز برای کسبوکاری که مدارک و فرایندهای آماده دارد لزوماً مسیر پیچیدهای نخواهد بود؛ به همین دلیل، زمان راهاندازی را باید بهصورت مکتوب و برای پرونده واقعی خودتان پرسید، نه از تجربه یک کسبوکار دیگر نتیجه گرفت.
۳. اتصال فنی و هزینه نگهداری
در مدل مستقیم، هر PSP مستندات، روش احراز، کدهای خطا و فرایندهای استعلام خود را دارد. اتصال به یک PSP ممکن است ساده باشد، اما اضافهکردن مسیر دوم میتواند به توسعه و آزمایش جداگانه، نرمالسازی پاسخها و منطق انتخاب مسیر نیاز داشته باشد.
در پرداختیاری، کسبوکار معمولاً با API و الگوی عملیاتی همان پرداختیار کار میکند. اگر سرویس از چند PSP پشتیبانی کند، تغییر مسیر ممکن است بدون ساخت اتصال مستقل برای هر PSP انجام شود. این مزیت فقط زمانی واقعی است که پوشش چند مسیر، رفتار failover و محدودیتهای آن در مستندات و آزمون عملی تأیید شده باشند.
در هر دو مدل باید مالک نگهداری افزونهها، SDK، تغییر نسخه API، کلیدها، IPهای مجاز، وبهوکها و محیط آزمایشی مشخص باشد.
۴. پایداری و استفاده از چند مسیر پرداخت
یک درگاه مستقیم متصل به یک PSP، یک مسیر پردازش در اختیار کسبوکار میگذارد. برای کاهش وابستگی، کسبوکار میتواند چند درگاه مستقیم بگیرد؛ اما پایش مسیرها، انتخاب درگاه و بازگرداندن تراکنش به وضعیت صحیح به معماری داخلی نیاز دارد.
بعضی پرداختیارها اتصال به چند PSP و قابلیت مسیردهی را ارائه میکنند؛ بااینحال چند اتصال بهتنهایی «مسیردهی هوشمند» نیست. باید مشخص شود سامانه چه شاخصهایی را پایش میکند، تصمیم در چه بازهای گرفته میشود، در زمان اختلال چه رفتاری دارد و گزارش مسیر انتخابشده چگونه در اختیار پذیرنده قرار میگیرد. راهنمای مسیردهی هوشمند این تفاوت را دقیقتر توضیح میدهد.
۵. تأیید تراکنش و امنیت پیادهسازی
امنیت نهایی سفارش در هر دو مدل به پیادهسازی درست کسبوکار وابسته است. بازگشت کاربر از صفحه پرداخت، بهتنهایی اثبات موفقیت نیست. سرور باید وضعیت تراکنش را از سرویس معتبر بررسی و مبلغ، شناسه سفارش و شناسه تراکنش را با دادههای داخلی تطبیق دهد.
درخواستهای تکراری، چند callback برای یک سفارش، قطع ارتباط پس از کسر وجه و بازپخش پاسخها باید بدون ثبت دوباره سفارش یا تحویل چندباره مدیریت شوند. راهنمای امنیت اتصال به درگاه OWASP بر تأیید سمت سرور، اعتبارسنجی مبلغ و سفارش، idempotency و ثبت رویدادها تأکید میکند؛ بنابراین انتخاب مدل درگاه، مسئولیت طراحی درست چرخه سفارش را از تیم محصول و فنی نمیگیرد.
۶. گزارشگیری و مغایرتگیری
درگاه مستقیم معمولاً گزارشهای همان PSP یا ترمینال را ارائه میکند. اگر چند PSP درگیر باشند، تیم مالی ممکن است دادهها را از منابع مختلف جمع و به یک ساختار مشترک تبدیل کند. کیفیت این فرایند به گزارشهای ارائهشده و ابزارهای داخلی کسبوکار وابسته است.
پرداختیار میتواند گزارش متمرکزتری از تراکنشها و مسیرهای مختلف ارائه دهد. پیش از انتخاب باید بررسی شود چه فیلدهایی قابل مشاهده یا دریافتاند، خروجی فایل یا API وجود دارد، وضعیتهای نامشخص چگونه مشخص میشوند و امکان اتصال داده پرداخت به سفارش، تسویه و استرداد وجود دارد یا خیر.
گزارش خوب فقط تعداد تراکنش موفق را نشان نمیدهد؛ باید برای کشف اختلاف مبلغ، تراکنش بدون سفارش، سفارش بدون تأیید پرداخت و اختلاف میان گزارش عملیاتی و مالی قابل استفاده باشد. راهنمای ویژگیهای درگاه پرداخت معیارهای بیشتری برای ارزیابی این بخش ارائه میکند.
۷. مدیریت پرداخت ناموفق یا نامشخص
خطای پرداخت همیشه از درگاه ناشی نمیشود. محدودیت کارت، اطلاعات نادرست، قطع ارتباط مشتری، اختلال بانک صادرکننده، PSP، شبکه یا منطق داخلی سایت میتوانند پرداخت را ناتمام بگذارند.
در مدل مستقیم، تیم کسبوکار معمولاً وضعیت هر مسیر را جداگانه پایش و خطاها را نرمال میکند. در پرداختیاری ممکن است اطلاعات متمرکزتری درباره مسیر و وضعیت تراکنش در دسترس باشد. در هر دو حالت باید فرایندی برای استعلام، تعیین وضعیت نهایی و پاسخگویی به مشتری وجود داشته باشد. راهنمای کاهش پرداختهای ناموفق به تفکیک این عوامل کمک میکند.
۸. استرداد وجه
بازگشت وجه را نباید با رفع خودکار کسر وجه در تراکنش ناموفق یکی دانست. استرداد معمولاً تصمیم کسبوکار برای بازگرداندن تمام یا بخشی از مبلغ یک تراکنش موفق است؛ برای نمونه پس از لغو سفارش یا اصلاح مبلغ.
در هر مدل باید مشخص شود استرداد از پنل یا API انجام میشود، چه نقشهایی مجازند، به تراکنش اصلی چگونه متصل میشود، چه وضعیتهایی دارد و تیم پشتیبانی چگونه آن را پیگیری میکند. بعضی پرداختیارها این فرایند را در کنار درگاه ارائه میکنند؛ در مدل مستقیم نیز امکانات به PSP و راهکار داخلی وابسته است. جزئیات طراحی این عملیات در راهنمای استرداد وجه آمده است.
۹. تسویه و مدیریت جریان وجوه
زمانبندی و سازوکار تسویه باید از قرارداد و مستندات بهروز همان سرویس بررسی شود. نباید از عنوان مستقیم یا پرداختیاری، بهتنهایی درباره زمان وصول وجه، حساب مقصد، تقویم تسویه یا امکان تفکیک وجوه نتیجهگیری کرد.
برای پلتفرمها و مارکتپلیسها، دریافت وجه از مشتری فقط نیمه اول مسئله است. انتقال سهم فروشندگان یا سایر ذینفعان یک عملیات جداگانه است و باید با کنترل مقصد، وضعیت انتقال، گزارش مالی و فرایند اصلاح خطا طراحی شود. در صورت نیاز به پرداختهای خروجی، راهکار تسویه و انتقال وجه را جدا از درگاه ارزیابی کنید.
۱۰. کارمزد و هزینه واقعی مالکیت
مقایسه کارمزد فقط زمانی معنا دارد که همه اجزای هزینه دیده شوند. هزینه توسعه اولیه، نگهداری اتصال، پایش شبانهروزی، ساخت گزارش، مغایرتگیری، رسیدگی به تیکتها، تغییر PSP و زمان تیم مالی میتواند از اختلاف کارمزد تراکنش مهمتر باشد.
درگاه مستقیم ممکن است برای کسبوکاری با تیم زیرساخت آماده و حجم مشخص، از نظر اقتصادی مناسب باشد. پرداختیاری نیز ممکن است هزینه مستقیم سرویس داشته باشد اما بخشی از توسعه و عملیات را کاهش دهد. قرارداد هر دو مدل باید هزینههای ثابت و متغیر، خدمات مشمول هزینه، مالیات، شرایط تغییر تعرفه و هزینه خدمات مکمل را روشن کند.
۱۱. پشتیبانی و مالک رخداد
هنگام اختلال باید معلوم باشد چه کسی اولین پاسخ را میدهد، چه دادهای برای پیگیری لازم است و مسئله تا کدام لایه ارجاع میشود. درگاه مستقیم کانال ارتباطی با PSP ایجاد میکند؛ پرداختیاری میتواند یک نقطه تماس متمرکز برای چند مسیر باشد.
نام مدل، کیفیت پشتیبانی را تضمین نمیکند. ساعات پاسخگویی، کانال اضطراری، SLA، زمان بهروزرسانی وضعیت، نحوه پیگیری تراکنش و گزارش پس از رخداد باید پیش از قرارداد بررسی شوند.
۱۲. دسترسی سازمانی، داده و کنترل داخلی
برای کسبوکارهای بزرگ، یک حساب کاربری مشترک کافی نیست. تیم مالی، پشتیبانی، فنی و مدیران به سطحهای متفاوتی از مشاهده و اقدام نیاز دارند. باید بررسی شود آیا نقشها و مجوزها قابل تفکیکاند، اقدامات حساس ثبت میشوند و خروجی لازم برای حسابرسی وجود دارد یا خیر.
همچنین باید بدانید چه دادهای نزد ارائهدهنده نگهداری میشود، تاریخچه تا چه مدت قابل دریافت است، خروجی گرفتن هنگام قطع همکاری چگونه انجام میشود و دسترسی API یا پنل چه محدودیتهایی دارد. این ملاحظات در هر دو مدل مهماند.
۱۳. مقیاسپذیری و وابستگی به ارائهدهنده
مقیاسپذیری فقط ظرفیت پردازش نیست؛ توان اضافهکردن مسیر، تغییر سرویس، جداکردن عملیات مالی و مهاجرت بدون توقف نیز بخشی از آن است. اتصال مستقیم به یک PSP وابستگی به همان API ایجاد میکند. اتصال به پرداختیار نیز وابستگی به قرارداد، مدل داده و قابلیتهای همان پلتفرم دارد.
یک لایه داخلی پرداخت با مدل داده استاندارد، شناسه سفارش مستقل، نگاشت وضعیتها و امکان فعال یا غیرفعالکردن ارائهدهنده میتواند هزینه مهاجرت را در هر دو مدل کاهش دهد.
چه زمانی درگاه مستقیم منطقیتر است؟
درگاه مستقیم در این شرایط میتواند ارزش بررسی داشته باشد:
- کسبوکار توان فنی و عملیاتی نگهداری مستقیم اتصال را دارد.
- رابطه مستقیم با یک PSP بخشی از سیاست خرید یا معماری سازمان است.
- یک یا چند ترمینال مشخص نیاز فعلی را پوشش میدهند.
- تیم مالی میتواند گزارشها و مغایرتهای مسیرهای جداگانه را مدیریت کند.
- خدمات مکمل موردنیاز در داخل سازمان ساخته شده یا از ابزار دیگری تأمین میشود.
- شرایط قرارداد، پشتیبانی و تسویه PSP با جریان نقدی کسبوکار سازگار است.
این موارد بهمعنای برتری قطعی درگاه مستقیم نیستند؛ فقط نشان میدهند کسبوکار آمادگی پذیرفتن مسئولیتهای بیشتر در داخل مجموعه را دارد.
چه زمانی پرداختیاری منطقیتر است؟
درگاه پرداختیاری در این شرایط معمولاً ارزش بررسی بیشتری دارد:
- کسبوکار میخواهد راهاندازی و عملیات پرداخت را از یک نقطه متمرکز مدیریت کند.
- اتصال به چند PSP یا تغییر مسیر بدون توسعه جداگانه اهمیت دارد.
- تیم مالی و پشتیبانی به گزارش یکپارچهتر و ابزارهای پیگیری نیاز دارند.
- استرداد، تسویه، مغایرتگیری یا APIهای عملیاتی باید کنار درگاه قرار گیرند.
- ظرفیت تیم فنی باید بیشتر صرف محصول اصلی شود تا نگهداری چند اتصال پرداخت.
- یک کانال پشتیبانی برای پیگیری مسائل چند مسیر ترجیح داده میشود.
این مزایا باید در سرویس واقعی اثبات شوند؛ همه پرداختیارها مجموعه یکسانی از PSPها، گزارشها یا خدمات مکمل ندارند.
آیا مدل ترکیبی انتخاب بهتری است؟
برای بعضی کسبوکارهای پرتراکنش، پاسخ مناسب نه «فقط مستقیم» است و نه «فقط پرداختیاری». مدل ترکیبی میتواند یک یا چند درگاه مستقیم را کنار لایه پرداختیاری یا مسیردهی داخلی قرار دهد. هدف این معماری معمولاً کاهش وابستگی، حفظ مسیر جایگزین و تفکیک عملیات است.
مدل ترکیبی بهخودیخود پایداری ایجاد نمیکند. اگر وضعیتها نرمال نشده باشند، سفارش میان مسیرها شناسه یکتا نداشته باشد یا failover باعث ساخت دو پرداخت فعال برای یک سفارش شود، پیچیدگی بیشتر میتواند ریسک را افزایش دهد. پیش از اجرا، مالک مسیردهی، قواعد تغییر مسیر، منبع حقیقت وضعیت سفارش و روش مغایرتگیری باید روشن باشند.
چکلیست انتخاب میان درگاه مستقیم و پرداختیاری
پیش از مذاکره با ارائهدهندگان، پاسخ این پرسشها را مکتوب کنید:
- الگوی تراکنش ما چیست: تعداد، مبلغ، ساعات اوج و فصلهای پرترافیک؟
- قطع یا افت یک مسیر چه اثر مالی و عملیاتی ایجاد میکند؟
- به یک PSP نیاز داریم یا چند مسیر و مسیردهی نیز لازم است؟
- چه کسی اتصال، مانیتورینگ، کلیدها و تغییر نسخه API را نگهداری میکند؟
- وضعیت پرداخت چگونه سمت سرور تأیید و از پردازش تکراری جلوگیری میشود؟
- تیم مالی برای تطبیق سفارش، تراکنش، تسویه و استرداد به چه فیلدهایی نیاز دارد؟
- برنامه و تقویم تسویه چگونه باید با جریان نقدی ما هماهنگ باشد؟
- استرداد کامل یا جزئی از پنل لازم است یا API؟
- چه نقشهایی باید فقط مشاهده کنند و چه کسانی اجازه اقدام مالی داشته باشند؟
- هنگام اختلال، SLA و مسیر ارجاع تا PSP چگونه است؟
- هزینه کل شامل توسعه، عملیات، پشتیبانی و خدمات مکمل چقدر میشود؟
- در صورت تغییر ارائهدهنده، دادهها و اتصال با چه هزینهای قابل مهاجرتاند؟
برای مقایسه ساختاریافتهتر ارائهدهندگان، معیارهای انتخاب درگاه پرداخت را نیز مرور کنید.
یک روش عملی برای امتیازدهی به گزینهها
ابتدا معیارها را به سه دسته تقسیم کنید: معیارهای حیاتی، معیارهای مهم و امکانات ترجیحی. امنیت تأیید تراکنش، امکان دریافت گزارش مالی لازم و سازگاری تسویه با کسبوکار معمولاً در دسته حیاتی قرار میگیرند؛ ظاهر پنل یا بعضی امکانات جانبی ممکن است ترجیحی باشند.
سپس برای هر معیار وزن تعیین کنید و از ارائهدهنده شاهد بخواهید: بند قرارداد، صفحه مستندات، دسترسی محیط آزمایشی یا اجرای سناریوی واقعی. وعده شفاهی را همارز قابلیت قابل آزمون در نظر نگیرید.
در پایان، هزینه کل و ریسک عملیاتی را کنار امتیاز قابلیتها قرار دهید. گزینهای که قابلیت بیشتری دارد اما در سه معیار حیاتی مردود میشود، نباید صرفاً به دلیل امتیاز مجموع انتخاب شود.
اشتباههای رایج در انتخاب مدل درگاه
- تصمیمگیری فقط براساس زمان فعالسازی اعلامشده
- مقایسه کارمزد بدون محاسبه هزینه توسعه و عملیات داخلی
- یکیدانستن چند PSP با مسیردهی هوشمند و پایششده
- فرض اینکه callback مرورگر برای تأیید سفارش کافی است
- نادیدهگرفتن تراکنشهای نامشخص، استرداد و مغایرت تا پس از راهاندازی
- انتخاب سرویس بدون آزمایش گزارشها با داده واقعی تیم مالی
- نپرسیدن مسئولیت و زمان پاسخگویی هنگام رخداد
- وابستهکردن منطق سفارش به کدها و وضعیتهای اختصاصی یک ارائهدهنده
چگونه بدون اختلال از یک مدل به مدل دیگر مهاجرت کنیم؟
مهاجرت از یک مدل به مدل دیگر در نگاه اول برای کسبوکار هزینهزاست، اما این جابهجایی میتواند کاملاً منطقی و پربازده باشد. درنظرگرفتن این موارد کمک میکند مهاجرت از یک مدل به مدل دیگر بدون اختلال انجام شود.
جریان پرداخت را از منطق سفارش جدا کنید
در سیستم داخلی، سفارش باید شناسه و وضعیت مستقل داشته باشد. اطلاعات ارائهدهنده، ترمینال و شناسه تراکنش در لایه پرداخت نگهداری شوند تا تغییر مسیر به بازنویسی کل فرایند فروش منجر نشود.
وضعیتها را نرمال کنید
نتیجههای ارائهدهندگان مختلف را به مجموعه وضعیتهای داخلی مانند «ایجادشده»، «در انتظار تعیین تکلیف»، «موفق»، «ناموفق» و «مستردشده» نگاشت کنید. جزئیات خام را نیز برای پیگیری حفظ کنید.
مهاجرت را مرحلهای انجام دهید
مسیر جدید را ابتدا با سهم محدود و سناریوهای کنترلشده فعال کنید. نرخ موفقیت، زمان پاسخ، مغایرت و بار پشتیبانی را با مسیر قبلی مقایسه کنید و سپس سهم ترافیک را افزایش دهید.
برنامه بازگشت داشته باشید
پیش از انتقال کامل، مشخص کنید در صورت افزایش خطا چگونه به مسیر قبلی بازمیگردید، تکلیف تراکنشهای در حال پردازش چیست و تیمهای مالی و پشتیبانی از تغییر چگونه مطلع میشوند.
درگاه پرداخت جیبیت چگونه تراکنشها را مدیریت میکند؟
همانطور که بررسی کردیم، انتخاب زیرساخت پرداخت فقط به دریافت یک درگاه محدود نمیشود؛ کسبوکارها با رشد تعداد تراکنشها به راهکاری نیاز دارند که پایداری پرداخت، مدیریت چند مسیر، گزارشگیری و عملیات پس از پرداخت را سادهتر کند.
درگاه پرداخت اینترنتی جیبیت، با اتصال به PSPهای مختلف و مسیردهی هوشمند میان آنها، امکان مدیریت متمرکز مسیرهای پرداخت را برای کسبوکارها فراهم میکند. بهاینترتیب، کسبوکار بهجای توسعه و نگهداری چند اتصال مستقل، میتواند عملیات پرداخت خود را از یک زیرساخت واحد مدیریت کند.
مهمترین مزیتهای درگاه پرداخت جیبیت در پاسخ به چالشهای مطرحشده در این مقاله عبارتاند از:
- پایداری بیشتر پرداخت: اتصال به PSPهای مختلف، امکان تعیین اولویت میان آنها، پایش وضعیت درگاهها و مسیردهی هوشمند میان مسیرهای پرداخت، وابستگی کسبوکار به یک مسیر واحد را کاهش میدهد.
- مدیریت سادهتر عملیات پرداخت: پنل مدیریتی و API جیبیت امکان مشاهده وضعیت تراکنشها، پیگیری فرایند پرداخت و دریافت گزارشهای ساختاریافته را فراهم میکنند.
- کاهش پیچیدگی عملیات مالی: قابلیتهایی مانند تسویه خودکار، استرداد وجه، صورتحساب تکمیلی و رفع مغایرتها، فرایندهای پس از پرداخت را سادهتر میکنند.
- مقیاسپذیری زیرساخت پرداخت: کسبوکارها میتوانند بدون افزایش متناسب پیچیدگی فنی، زیرساخت پرداخت خود را با رشد تعداد تراکنشها توسعه دهند.
درگاه پرداخت اینترنتی جیبیت به کسبوکارهایی کمک میکند تا دید جامعتری بر کل چرخه پرداخت، از ثبت تراکنش تا تسویه، داشته باشند.
پرسشهای متداول
بهصورت کلی، درگاه مستقیم برای تیمی که رابطه مستقیم با PSP و توان نگهداری عملیات را میخواهد مناسبتر است؛ پرداختیاری برای کسبوکاری که اتصال و ابزارهای عملیاتی متمرکزتر میخواهد ارزش بررسی بیشتری دارد. قرارداد و آزمون عملی تعیینکنندهاند.
در کاربرد رایج، درگاهی که ازطریق پرداختیار ارائه میشود درگاه پرداخت غیرمستقیم یا پرداختیاری نامیده میشود. «غیرمستقیم» به مسیر رابطه پذیرنده با PSP اشاره دارد و به معنای غیرواقعی یا ناامنبودن پرداخت نیست.
خیر. تعرفه و شرایط قرارداد باید بهروز بررسی شوند. افزون بر کارمزد سرویس، هزینه توسعه، نگهداری، مانیتورینگ، گزارشگیری و پشتیبانی داخلی را در هزینه کل مالکیت لحاظ کنید.
باز نظر معماری امکان استفاده از چند مسیر وجود دارد، اما قراردادها، الزامات پذیرندگی و سازوکار فنی باید اجازه آن را بدهند. منطق مسیردهی، جلوگیری از پرداخت تکراری و مغایرتگیری باید پیش از اجرا طراحی شود.
سازوکار و تقویم تسویه باید از قرارداد هر سرویس بررسی شود و ممکن است میان ارائهدهندگان متفاوت باشد. عنوان مستقیم یا پرداختیاری برای نتیجهگیری درباره زمان دقیق تسویه کافی نیست.
مارکتپلیس باید علاوه بر دریافت وجه، تسویه با ذینفعان، گزارش تفکیکی، استرداد، کنترل نقشها و مغایرتگیری را طراحی کند. مدلی مناسب است که این معماری را با کمترین ریسک و هزینه کل پوشش دهد؛ گاهی پرداختیاری یا مدل ترکیبی تناسب بیشتری دارد.