قابلیتهای ارائهدهندگان پرداخت و آنچه به خریدار ارائه میشود
چه قابلیتای از یک درگاه یا حساب پذیرنده قابل انتظار است، کدامشان در اوردیکس مصرف میشود و کدامشان فقط یک قابلیت ارائهدهنده است.
این راهنما میان سه چیز تمایز قائل میشود: قابلیتهایی که خود ارائهدهنده پرداخت فراهم میکند، مسیری که اوردیکس از آن قابلیتها مصرف میکند، و چیزی که خریدار در ویترین فروشگاه یا صفحهٔ خرید میبیند. یک فروشگاه میتواند با اتصال حساب پذیرندهٔ واجد شرایط، بخشی از این قابلیتها به مشتریان خود ارائه دهد؛ اما معرفی عمومی باید فقط شامل مسیری باشد که واقعاً ساخته، تنظیم و آزموده شده است.
۱. چرا تفکیک سه سطح لازم است
سطح اول، خرید اشتراک اوردیکس است: پلن انتخاب میشود و پرداخت از درگاههای پلتفرم انجام میشود. سطح دوم، پرداخت سفارش فروشگاههای کاربران است: وجه به حساب پذیرندهٔ همان فروشگاه مینشیند و اوردیکس تنها نتیجه را ثبت میکند. سطح سوم، قابلیتهای خود ارائهدهنده است که ممکن است در حسابی فعال باشد و در حساب دیگر نباشد. بدون این تفکیک، یک راهنما یا صفحهٔ فروش، قابلیت یک حساب را به همهٔ خریداران وعده میدهد.
۲. حداقل آنچه یک درگاه استاندارد فراهم میکند
نشانی پرداخت امن، نمایش نام پذیرنده و مبلغ، شناسهٔ یکتای تراکنش، صفحهٔ پیامک یا رمز پویا، بازگشت به سایت با یک توکن یا authority، و استعلام یا verify سمت سرور. هرکدام از اینها متعلق به ارائهدهنده است، نه به اوردیکس؛ سامانه فقط نتیجهٔ معتبر را مصرف و ثبت میکند و جایگزین مرجع بانکی نمیشود.
۳. تأیید خودکار واریز، از رویداد تا وضعیت سفارش
تأیید خودکار وقتی ممکن است که ارائهدهنده هم رویداد قابلاتکاء بدهد و هم امکان بررسی مجدد بدهد: رویداد امضاشده یا پاسخ verify با شناسهٔ تراکنش، تطبیق مبلغ و شناسهٔ بیرونی، و سپس ثبت یکبارهٔ اثر مالی. در این الگو، وضعیت سفارش و سند پرداخت از همان تأیید ساخته میشوند؛ کلیک خریدار روی دکمه، بست شدن صفحهٔ بانک یا رسید تصویری، هیچکدام در این زنجیره جای تأیید سروری را نمیگیرند.
۴. مبلغ یکتا و تطبیق ماشینی
برخی سرویسهای کارتبهکارت، برای هر صورتحساب مبلغی با رقم اعشار یکتا تولید میکنند تا واریز بدون مراجعهٔ انسانی به همان سفارش وصل شود. شرط کارکرد آن، پرداخت دقیق همان مبلغ است؛ پرداخت مبلغ پایه، گردکردن مبلغ یا واریز چند سفارش در یک انتقال، تطبیق را میشکند و پرونده به بررسی دستی میرود. مهلت اعتبار این مبلغها محدود است و پس از پایان آن باید همان سفارش بازبینی شود، نه سفارش تازه ساخته شود.
۵. وبهوک، امضای رویداد و پذیرش آن
وبهوک یک کانال خبری است، نه صندوق. اعتبار آن به سه چیز وابسته است: رمز اختصاصی (Secret) همان حساب، امضای بررسیشده روی بدنهٔ خام رویداد، و پنجرهٔ زمانی که رویدادهای قدیمی را رد میکند. نشانی callback باید از اینترنت قابلدسترس و HTTPS باشد و تغییر مسیر، ریدایرکت یا پراکسی که بدنه را بازنویسی کند، امضا را باطل میکند. رویداد تکراری باید بیاثر شود؛ وگرنه یک پرداخت، دو سند مالی میسازد.
۶. محیط آزمایشی و سنجش اتصال
ارائهدهندگان معمولاً کلید یا حساب آزمایشی، میزبان sandbox و توکن تستی میدهند. در اوردیکس، هر درگاه فیلدهای خودش را دارد و پیش از فعالسازی میتوان آزمون اتصال گرفت؛ نتیجهٔ آزمون یعنی «پاسخ سرویس گرفته شد»، نه «تراکنش واقعی تأیید شد». برای اطمینان، یک پرداخت کمارزش واقعی انجام و در پنل همان درگاه ببینید؛ ساندباک، وجود وجه را اثبات نمیکند.
۷. مسیر دستی و جایگاه آن
وقتی مسیر خودکار در دسترس نیست، روش دستی باقی میماند: نمایش مقصد و مبلغ، واریز توسط خریدار، ثبت شمارهٔ پیگیری و تطبیق مسئول مجاز فروشگاه. این مسیر آهستهتر و وابسته به انسان است، اما قابل بازرسی نگه داشته میشود چون مرجع واریز و نتیجهٔ بررسی ثبت میشوند. فروشگاهی که فقط مسیر دستی دارد نباید خودش را «درگاه لحظهای» معرفی کند.
۸. پیگیری، کد رهگیری و ردپای ممیزی
خریدار باید بتواند با کد سفارش یا لینک پیگیری، وضعیت را ببیند: سفارش ساخته شد، پرداخت درخواست شد، بازگشت یا رویدادی رسید، و در پایان وجه تأیید یا رد شد. برای هر درگاه، ردپای رویدادها با زمان، شناسه و نتیجه نگهداری میشود تا در اختلاف، همان پرونده بازخوانی شود. در صورت ابهام، همان سفارش پیگیری میشود؛ ساخت سفارش دوم، مشکل را دوچندان میکند.
۹. بازگشت وجه، لغو و اسناد معکوس
بازگشت وجه یک عملیات ارائهدهنده است: از پنل یا API همان درگاه، با شرایط کارمزد و زمان تسویهٔ خودش. از دید سامانه، بازگشت وجه باید یک سند جدا و قابلردیابی بسازد، نه ویرایش یا حذف سند قبلی. در نسخهٔ جاری، صفحهٔ خریدار دکمهٔ بازگشت خودکار ندارد و لغو سفارش بهتنهایی وجه را برنمیگرداند؛ اگر این قابلیت لازم است، مسیر آن باید جدا ساخته و آزموده شود.
۱۰. پرداخت دورهای، اقساط و چنددرگاهی
قابلیتهایی مثل برداشت دورهای، ذخیرهٔ مجوز کارت، پرداخت در چند قسط، یا هدایت هوشمند بین چند درگاه، هر کدام هم پشتیبانی صریح ارائهدهنده و هم طراحی مستقل در سامانه میخواهند. نبودِ این مسیرها بهمعنی ضعف درگاه نیست؛ بهمعنی آن است که فعلاً نباید به خریدار وعده داده شوند. تمدید اشتراک در اوردیکس با درخواست روشن کاربر انجام میشود و برداشت خودکار دورهای در آن صورت نمیگیرد.
۱۱. سقف مبلغ، واحد پول و نرخ درخواست
هر درگاه حداقل و حداکثر مبلغ، واحد پول مجاز و سقف تعداد درخواست در بازهٔ زمانی دارد. در مسیر اشتراک، ارز پلن باید ریال یا تومان باشد و مبالغ خارج از بازهٔ مجاز رد میشوند؛ نرخ درخواست هم محدود است تا سوءاستفاده و ترافیک تکراری کنترل شود. وقتی خریدار پیام «مبلغ مجاز نیست» میبیند، علت معمولاً همین مرزهاست، نه خرابی سامانه.
۱۲. چگونه اینها را به خریدار معرفی کنیم
متن فروشگاهی فقط سه چیز را وعده دهد: مبلغ و روش پرداخت روشن، مسیر امن پرداخت، و پیگیری وضعیت بعد از پرداخت. برای هر ادعای دیگر، سه سؤال را پاسخ دهید: آیا ارائهدهنده آن را در همین حساب فعال کرده؟ آیا مسیر در سامانه ساخته و به checkout وصل شده؟ آیا با یک تراکنش واقعی آزموده شده؟ اگر پاسخ یکی «نه» است، آن را در راهنمای داخلی نگه دارید، نه در صفحهٔ فروش.
۱۳. محدوده عملیاتی فعلی اوردیکس
در خرید اشتراک، درگاههای برخط پلتفرم (زرینپال، پیاکسا و آبان گیتوی) بههمراه کارتبهکارت دستی و پیوند پرداخت بیرونی پشتیبانی میشوند و هر کدام فیلدها و قواعد تأیید خودش را دارد. در سفارش فروشگاه، مسیر خودکار با اتصال حساب عادی پذیرندهٔ فروشگاه ساخته میشود و تا آن اتصال فعال نباشد، همان سفارش با روش دستی و تأیید فروشنده پیش میرود. بازگشت وجه خودکار، تمدید خودکار، پرداخت دورهای، اقساط و مسیریابی چنددرگاهی در نسخهٔ جاری ارائه نمیشوند؛ نام یک سرویس در فهرست اتصالهای داخلی یا پنل، بهمعنی فعال بودن آن در پرداخت سفارش فروشگاه نیست.
نقشه اجرایی: قابلیتهای ارائهدهندگان پرداخت و آنچه به خریدار ارائه میشود
نمای مفهومی از موضوعات این راهنما؛ عنوانها و دادهها صرفاً آموزشیاند.
پس از مطالعه این راهنما چه مواردی را بررسی کنم؟
- پیشنیازها و محدوده دسترسی مرتبط با این بخش را پیش از شروع بررسی کنید.
- هر مرحله را با داده واقعی و در دامنه مجاز فضای کاری انجام دهید.
- پس از اجرا، وضعیت و نتیجه را در همان ماژول بازبینی کنید.
نکته مهم: این شبیهسازی داده واقعی را تغییر نمیدهد. نتیجه نهایی به مجوز کاربر، پلن، تنظیمات اتصال و سرویسهای بیرونی وابسته است.