برای اتصال درگاه پرداخت به سایت، ابتدا حساب پذیرندگی و شرایط فعالیت را با ارائه‌دهنده تکمیل کنید، سپس افزونه یا اتصال فنی را تنظیم کنید و مسیر سفارش تا تأیید پرداخت را بیازمایید. نمایش دکمه پرداخت و حتی بازگشت مشتری به سایت، به‌تنهایی نشانه پرداخت موفق نیست. سایت باید نتیجه را از سرویس پرداخت تأیید کند و به همان سفارش وصل کند.
این راهنما برای صاحب کسب‌وکار و مسئول اجرای سایت است؛ از انتخاب درگاه تا آزمون‌های تحویل را پوشش می‌دهد. اگر هنوز محصول، سبد و ارسال را نساخته‌اید، ابتدا آموزش ساخت فروشگاه با وردپرس و ووکامرس را بخوانید؛ در اینجا تمرکز بر بخش پرداخت است.
فروش کالا، پرداخت یک فاکتور و رزرو نوبت، جریان سفارش یکسانی ندارند. روی کاغذ بنویسید مشتری بابت چه چیزی پول می‌دهد، مبلغ کجا تعیین می‌شود و پس از تأیید چه اتفاقی باید بیفتد. مثلاً در فروش فایل، دسترسی دانلود باید به همان سفارش تأییدشده وابسته باشد؛ در سفارش کالای فیزیکی، مرحله آماده‌سازی و ارسال نیز لازم است.
اگر پرداخت مبلغ دلخواه دارید، هدف پرداخت، حد قابل‌قبول مبلغ و روش تطبیق آن با درخواست مشتری را روشن کنید. اگر رزرو دارید، زمان نگه‌داشتن ظرفیت تا نتیجه پرداخت را تعریف کنید. این تصمیم‌ها پیش از نصب افزونه، اختلاف میان مدیر سایت و مجری را کمتر می‌کنند.
هنگام طراحی سایت با درگاه بانکی، از هر ارائه‌دهنده درباره این موارد پاسخ مشخص بگیرید:
برای تصمیم میان قرارداد مستقیم با شرکت خدمات پرداخت و استفاده از پرداخت‌یار، همین نیازها را مقایسه کنید. صرف عنوان «مستقیم» یا «واسط» برای نتیجه‌گیری درباره کیفیت، هزینه یا سهولت اتصال کافی نیست. پیشنهاد مکتوب، مستندات و نتیجه آزمون سایت خودتان معیار عملی‌تری است.
اطلاعات متقاضی، راه تماس، حساب تسویه و دامنه فعالیت را آماده کنید و با فرم و قرارداد روز ارائه‌دهنده تطبیق دهید. برای نمونه، شرایط رسمی درگاه زیبال در زمان بررسی این راهنما، اینماد معتبر، کد رهگیری مالیاتی به نام متقاضی و حداقل ۱۸ سال سن را ذکر می‌کند. این نمونه را فهرست کامل شرایط همه ارائه‌دهندگان تلقی نکنید؛ الزامات فعالیت و مدارک خود را پیش از درخواست بررسی کنید.
در فرایند رسمی دریافت درگاه زرین‌پال نیز ثبت‌نام، احراز هویت، درخواست و بررسی مدارک پیش از فعال‌سازی آمده است. همچنین طبق مقررات اجرایی زرین‌پال، مرچنت اختصاصی باید در دامنه متعلق به پذیرنده و مرتبط با فعالیت ثبت‌شده استفاده شود. درگاه فرد دیگری را راه‌حل موقت پروژه قرار ندهید.
در سایت، کالا یا خدمت، قیمت یا مبنای تعیین مبلغ، اطلاعات تماس و شرایط خرید و بازگشت را روشن بنویسید. مسئول پیگیری پذیرندگی را مشخص کنید؛ آماده بودن سایت به معنی تأیید خودکار حساب درگاه نیست. شرایط و مستندات این مقاله در ۱۲ آبان ۱۴۰۵، برابر با ۳ نوامبر ۲۰۲۶، بررسی شده‌اند و هنگام اقدام باید دوباره خوانده شوند.
روی دامنه نهایی با HTTPS معتبر کار کنید و پیش از تغییر، نسخه پشتیبان قابل‌بازیابی داشته باشید. راهنمای نصب SSL و فعال‌سازی HTTPS در وردپرس برای این بخش نقطه شروع است. نشانی بازگشت پرداخت باید به مسیر درست برسد؛ تغییر دامنه، تغییرمسیر اشتباه یا مسدود شدن این مسیر می‌تواند خرید را نیمه‌تمام بگذارد.
مشخص کنید چه کسی اجازه تغییر تنظیمات پرداخت دارد و اطلاعات اتصال کجا نگهداری می‌شود. تنظیمات حساس را در متن صفحه، کد سمت مرورگر، تصویر آموزشی یا گزارش عمومی قرار ندهید. از مجری بخواهید دسترسی پشتیبانی را متناسب با کار و مدت همکاری تعریف کند.
مستندات درگاه‌های پرداخت ووکامرس میان پیاده‌سازی صفحه تسویه معمول و اتصال روش پرداخت به بلوک تسویه تفاوت می‌گذارد. بنابراین فعال بودن افزونه در فهرست پرداخت‌ها، به‌تنهایی سازگاری آن با صفحه تسویه فعلی شما را اثبات نمی‌کند. همان مسیر خریدی را که مشتری می‌بیند آزمایش کنید.
اگر پروژه از ابتدا ساخته می‌شود، انتخاب روش پرداخت را در محدوده سفارش طراحی سایت با وردپرس مشخص کنید. برای برآورد کل فروشگاه نیز هزینه طراحی سایت فروشگاهی با وردپرس را جدا از هزینه خدمات درگاه بررسی کنید؛ این دو هزینه و مسئولیت متفاوت دارند.
در نمونه زرین‌پال، سایت درخواست را با مبلغ، شناسه پذیرنده و نشانی بازگشت می‌فرستد و شناسه درخواست یا Authority می‌گیرد. مشتری به صفحه پرداخت هدایت می‌شود و سپس به نشانی بازگشت برمی‌گردد. در بازگشت، برنامه باید تأیید تراکنش یا verify را مطابق مستندات اجرا کند. راهنمای رسمی اتصال زرین‌پال این مراحل و کدهای پاسخ را توضیح می‌دهد.
در همین سرویس، پاسخ ۱۰۰ در تأیید به معنی موفقیت است و پاسخ ۱۰۱ نشان می‌دهد آن تراکنش قبلاً تأیید شده است. این اعداد عمومی نیستند و برای درگاه دیگر باید مستندات خودش را خواند. پاسخ تکراری نباید باعث تحویل دوباره کالا یا افزایش دوباره اعتبار مشتری شود.
برای سایت اختصاصی، منطق سفارش را در سمت سرور نگه دارید: مبلغ معتبر را از داده ذخیره‌شده سفارش بخوانید، شناسه درخواست را به سفارش مربوط وصل کنید و فقط تغییر وضعیت مجاز را انجام دهید. اصول تأیید تراکنش در OWASP بر کنترل سمت سرور و محافظت از داده و وضعیت تراکنش تأکید دارند. مقدار ارسالی مرورگر نباید مرجع نهایی مبلغ یا موفقیت باشد.
فرض کنید جمع نهایی سفارش ۲۵۰ هزار تومان است. اگر درخواست به ریال باشد، مقدار متناظر ۲ میلیون و ۵۰۰ هزار ریال است. در مستندات واحد پولی زرین‌پال، IRR برای ریال و IRT برای تومان معرفی شده است. واحد نمایش فروشگاه، تنظیم افزونه و مبلغ درخواست باید هماهنگ باشند.
مبلغ را در صفحه سفارش، صفحه پرداخت و گزارش ثبت‌شده مقایسه کنید؛ یکسان بودن ظاهر اعداد در دو صفحه کافی نیست. مثال بالا محاسبه ساده تبدیل واحد است و مبلغ یا حداقل مجاز تراکنش هیچ ارائه‌دهنده‌ای را تعیین نمی‌کند.
آزمایش را در نسخه آزمایشی سایت و با روش تست معتبر ارائه‌دهنده انجام دهید. سندباکس زرین‌پال امکان آزمون بدون پرداخت مبلغ را با نشانی سرویس تست توضیح می‌دهد. در افزونه آماده، روش فعال‌سازی تست را از راهنمای همان افزونه دنبال کنید.
طبق راهنمای آزمون سفارش ووکامرس، سفارش آزمایشی ممکن است ایمیل، آمار و اتصال‌های دیگر را فعال کند. پیش از آزمون اثر اتصال به انبار، ارسال، پیامک و حسابداری را مشخص کنید. برای هر سناریو، شناسه سفارش، زمان، نتیجه موردانتظار و نتیجه واقعی را ثبت کنید.
| سناریوی آزمون | معیار پذیرش پیشنهادی |
|---|---|
| پرداخت موفق | مبلغ درست، تأیید معتبر، ثبت شماره پیگیری و اجرای یک‌باره اقدام پس از پرداخت. |
| انصراف یا شکست پرداخت | پیام روشن و امکان تلاش دوباره؛ سفارش پرداخت‌شده معرفی نشود. |
| بازکردن دوباره صفحه بازگشت | رسید قابل مشاهده باشد؛ موجودی، دانلود یا اعتبار دوباره تغییر نکند. |
| قطع ارتباط هنگام تأیید | نتیجه نامعلوم قابل پیگیری بماند؛ صرف قطع ارتباط، موفقیت یا شکست قطعی اعلام نشود. |
| تخفیف و هزینه ارسال | جمع نهایی با سفارش ذخیره‌شده و مبلغ درگاه تطبیق داشته باشد. |
| خرید با موبایل | دکمه، پیام خطا، انتقال و بازگشت در مسیر واقعی خرید قابل استفاده باشند. |
این جدول معیار پیشنهادی تحویل پروژه است؛ نتیجه واقعی را باید در سایت خود ثبت کنید. برای کنترل بخش‌های دیگر راه‌اندازی، چک‌لیست طراحی سایت پیش از انتشار را نیز به برنامه آزمون اضافه کنید.
ابتدا شماره سفارش، زمان، مبلغ و شناسه درخواست را جمع‌آوری و با گزارش ارائه‌دهنده تطبیق دهید. از مشتری رمز کارت یا کد امنیتی نخواهید. تا نتیجه معتبر روشن نشده، کالا یا اعتبار را صرفاً بر اساس تصویر رسید تحویل ندهید و مشتری را بی‌اطلاع به پرداخت دوباره هدایت نکنید.
در راهنمای اتصال امن درگاه OWASP، تطبیق مبلغ، واحد پول و سفارش، تأیید سمت سرور و پردازش یک‌باره سفارش توصیه شده است. برای پیگیری، شناسه‌های لازم و نتیجه بررسی را ثبت کنید؛ اطلاعات ورود، داده کامل کارت و داده شخصی غیرضروری را وارد گزارش نکنید.
اگر خطا پیش از انتقال رخ می‌دهد، فعال بودن پذیرندگی، تنظیمات افزونه و ارتباط سرور را بررسی کنید. اگر پس از بازگشت رخ می‌دهد، مسیر بازگشت، پاسخ تأیید و ثبت وضعیت سفارش را بررسی کنید. خطای مبلغ ده‌برابری را از تنظیم واحد پول پیگیری کنید. هر تغییر را با همان سناریوی خطادار دوباره بیازمایید؛ خاموش کردن کنترل امنیتی راه‌حل عمومی نیست.
صورت‌جلسه تحویل باید ارائه‌دهنده و دامنه متصل، مسئول حساب، روش دسترسی مجاز، نسخه افزونه یا اتصال، نتایج آزمون، روش پیگیری مغایرت و مسئول پشتیبانی را مشخص کند. معیار را فقط «درگاه نصب شد» نگذارید؛ برای نمونه بنویسید «پرداخت تست موفق و ناموفق، بازگشت تکراری و تطبیق مبلغ آزموده شد» و نتیجه‌ها را ضمیمه کنید.
چک‌لیست موارد تحویل سایت وردپرسی به کارفرما برای ثبت دسترسی‌ها و مستندات مفید است. پس از به‌روزرسانی افزونه پرداخت، تغییر قالب تسویه یا جابه‌جایی دامنه نیز آزمون‌های وابسته را تکرار کنید.
برای سایت دارای افزونه سازگار، بخشی از کار با تنظیمات انجام می‌شود. اتصال اختصاصی، رفع تداخل یا منطق ویژه سفارش ممکن است به توسعه نیاز داشته باشد. در هر دو روش، آزمون نتیجه پرداخت و سفارش لازم است.
خیر. پذیرندگی باید فعال باشد، مبلغ درست ارسال شود و نتیجه معتبر در سفارش ثبت شود. پیام مشتری و عملیات پس از پرداخت نیز باید آزموده شوند.
این دو را جدا پیگیری کنید: یکی نتیجه تراکنش سفارش است و دیگری واریز طبق برنامه ارائه‌دهنده. گزارش سفارش و گزارش تسویه باید قابل تطبیق باشند؛ برنامه و شرایط روز را از قرارداد و پنل رسمی بخوانید.
