چطور مغایرت دامنه ترمینال با Callback و Referrer را برطرف کنیم؟

اگر دامنه مورداستفاده در Callback یا Referrer پرداخت با دامنه ثبت‌شده ترمینال هم‌خوان نباشد، ممکن است روی ترمینال محدودیت اعمال شود. این مسئله معمولاً پس از تغییر دامنه سایت، Backend یا مسیر Checkout ایجاد می‌شود.

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

در ادامه توضیح می‌دهیم دامنه ثبت‌شده ترمینال، Callback و Referrer را چطور بررسی کنید و در صورت وجود مغایرت، چه اقدامی لازم است.

برای بررسی تطابق دامنه چه چیزهایی اهمیت دارند؟

برای تشخیص وجود یا نبود مغایرت، ابتدا باید سه مؤلفه را از هم تفکیک کنیم:

مؤلفه	توضیح	نمونه
دامنه ثبت‌شده ترمینال	دامنه‌ای که ترمینال پرداخت برای آن ثبت شده است	example.com
Callback	آدرسی که کاربر پس از پایان فرایند پرداخت به آن بازمی‌گردد	https://example.com/payment/callback
Referrer	مبدئی که مرورگر هنگام ورود کاربر به مسیر پرداخت گزارش می‌کند	https://example.com/cart

در این بررسی، مسیر بعد از دامنه اهمیتی ندارد؛ برای مثال در https://example.com/payment/callback، دامنه example.com است و /payment/callback فقط مسیر بازگشت محسوب می‌شود. Subdomainهایی مانند shop.example.com یا api.example.com نیز تا زمانی که به همان دامنه و پذیرنده تعلق داشته باشند، به‌خودی خود، مغایرت ایجاد نمی‌کنند. مسئله زمانی است که بخشی از جریان پرداخت روی دامنه اصلی دیگری قرار داشته باشد.

Callback و Referrer چه تفاوتی دارند؟

Callback و Referrer دو نقطه متفاوت از جریان پرداخت را نشان می‌دهند. Callback یا آدرس بازگشت مقصدی است که هنگام ایجاد درخواست پرداخت مشخص می‌کنید تا کاربر پس از پایان فرایند پرداخت به آن بازگردد؛‌ برای مثال: https://example.com/payment/callback. این مقدار معمولاً هنگام ایجاد تراکنش در پارامتری مانند callbackUrl ارسال می‌شود.

Referrer در سمت دیگر جریان قرار دارد و درباره مبدأ ورود کاربر به مسیر پرداخت اطلاعات می‌دهد. در HTTP نام این Header به‌صورت Referer نوشته می‌شود، هرچند اصطلاح عمومی آن Referrer است؛ برای مثال ممکن است مرورگر هنگام هدایت کاربر به درگاه این مقدار را ارسال کند:

Referer: https://example.com/

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

مقدار Referer نیز همیشه یکسان نیست. بسته به Referrer-Policy و شرایط Navigation، مرورگر ممکن است URL کامل، فقط Origin یا در برخی شرایط هیچ Refererی ارسال نکند. به همین دلیل، برای عیب‌یابی باید مقدار واقعی ایجادشده در جریان پرداخت را بررسی کرد، نه مقداری که انتظار داریم ارسال شود.

چگونه تطابق دامنه ترمینال، Callback و Referrer را بررسی کنیم؟

برای پیداکردن مغایرت لازم نیست تمامی تنظیمات زیرساخت را از ابتدا بررسی کنید. چهار مرحله معمولاً مشخص می‌کند مسئله از کجا ایجاد شده است:

۱. دامنه ثبت‌شده ترمینال را مشخص کنید

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

۲. مقدار واقعی Callback در محیط Production را بررسی کنید

callbackUrl واقعی را در همان درخواستی بررسی کنید که در محیط Production برای ایجاد تراکنش ارسال می‌شود. ممکن است پس از تغییر دامنه یا Backend، یک Environment Variable همچنان به دامنه قبلی، Stage یا آدرس موقت اشاره کند؛ برای مثال:

https://old-example.com/payment/callback

در این حالت، تنظیمات محیط اصلی باید اصلاح شود.

۳. Referrer واقعی پرداخت را مشاهده کنید

حالا یک پرداخت کنترل‌شده را از همان مسیری شروع کنید که کاربران در محیط اصلی استفاده می‌کنند. در Developer Tools مرورگر، از بخش Network درخواست مربوط به ورود کاربر به مسیر پرداخت را باز کنید و مقدار Referer را در Request Headers ببینید؛ برای مثال، اگر مقدار Referer چنین باشد:

https://checkout.example.net/

مشخص می‌شود مبدأ پرداخت به دامنه اصلی دیگری تعلق دارد و باید بررسی شود چرا این Flow با ترمینال ثبت‌شده برای example.com استفاده می‌شود.

۴. دامنه‌های مورداستفاده در جریان پرداخت را کنار هم قرار دهید

در پایان، نتیجه بررسی را به‌ساده‌ترین شکل کنار هم بنویسید:

مورد	مقدار مشاهده‌شده
دامنه ثبت‌شده ترمینال	example.com
دامنه Callback	example.com
دامنه Referer	checkout.example.net

در این مثال، Callback با دامنه ثبت‌شده ترمینال هم‌خوان است، اما Referrer به دامنه اصلی دیگری تعلق دارد. بنابراین باید بررسی شود چرا پرداخت از checkout.example.net آغاز شده و آیا این Flow باید به دامنه ثبت‌شده ترمینال منتقل شود یا دامنه ترمینال نیاز به اصلاح دارد.

همین مقایسه ساده معمولاً منشأ مسئله را بسیار سریع‌تر از بررسی پراکنده تنظیمات مشخص می‌کند.

عیب‌یابی مغایرت دامنه

اگر دامنه ثبت‌شده ترمینال با دامنه‌های مورداستفاده در جریان واقعی پرداخت هم‌خوان نیست، این جدول می‌تواند نقطه شروع عیب‌یابی باشد:

وضعیت مشاهده‌شده	علت احتمالی	چه چیزی را بررسی کنیم؟
Callback به دامنه قبلی، Stage، IP یا آدرس موقت اشاره می‌کند	تنظیمات Production به‌روز نشده یا تنظیمات آزمایشی باقی مانده است	مقدار واقعی callbackUrl و Environment Variableهای محیط Production
Callback یا Referrer روی دامنه اصلی دیگری قرار دارد	Backend، Checkout یا مسیر بازگشت به دامنه دیگری منتقل شده است	دامنه ثبت‌شده ترمینال و دامنه واقعی Callback و Referrer
Subdomain دارای اینماد یا کد مالیاتی مستقل است	اطلاعات پذیرندگی آن با دامنه اصلی یکسان نیست	اینماد، کد مالیاتی و ترمینال مرتبط با همان پذیرنده
Referrer دامنه‌ای غیرمنتظره دارد	پرداخت از صفحه، Checkout یا Flow دیگری آغاز می‌شود	صفحه واقعی آغاز پرداخت و Redirectهای پیش از ورود به درگاه
Referrer خالی است	Referrer-Policy، نوع Navigation یا محیط اجرا مانع ارسال Referer شده است	Referrer-Policy، Request واقعی و Redirectهای مسیر پرداخت
فقط بعضی پرداخت‌ها یا فقط نسخه اپلیکیشن دچار مشکل می‌شوند	چند Flow، دامنه، Client یا WebView رفتار متفاوتی دارند	هر مسیر مستقل پرداخت و Request واقعی همان Flow
وضعیت مشاهده‌شده	علت احتمالی	چه چیزی را بررسی کنیم؟
Callback به دامنه قبلی، Stage، IP یا آدرس موقت اشاره می‌کند	تنظیمات Production به‌روز نشده یا تنظیمات آزمایشی باقی مانده است	مقدار واقعی callbackUrl و Environment Variableهای محیط Production
Callback یا Referrer روی دامنه اصلی دیگری قرار دارد	Backend، Checkout یا مسیر بازگشت به دامنه دیگری منتقل شده است	دامنه ثبت‌شده ترمینال و دامنه واقعی Callback و Referrer

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

اگر Referrer خالی باشد، چه کنیم؟

خالی‌بودن Referer الزاماً به‌معنای خطای پیاده‌سازی نیست؛ ارسال این Header به Referrer-Policy، نوع Navigation و محیط اجرا بستگی دارد. برای مثال، Policyهایی مانند no-referrer می‌توانند مانع ارسال آن شوند.

در بسیاری از مرورگرهای امروزی، Policy پیش‌فرض strict-origin-when-cross-origin است. در این حالت، هنگام Navigation میان دو Origin متفاوت معمولاً فقط Origin مبدأ ارسال می‌شود، نه مسیر کامل صفحه.

بنابراین اگر Referer وجود ندارد:

• Referrer-Policy صفحه را بررسی کنید؛
• Request واقعی را در Network ببینید؛
• Redirectها و صفحات واسط مسیر پرداخت را بررسی کنید؛
• مشخص کنید پرداخت واقعاً از کدام صفحه آغاز شده است؛
• اگر مشکل فقط در اپلیکیشن رخ می‌دهد، Flow آن را مستقل از وب آزمایش کنید.

در مرورگر نیز نمی‌توان Referer را مانند یک Header عادی با هر مقدار دلخواه تنظیم کرد؛ رفتار آن عمدتاً در اختیار مرورگر و Referrer-Policy است.

پرداخت در WebView چه تفاوتی دارد؟

اگر پرداخت داخل WebView انجام می‌شود، نتیجه تست نسخه وب را به آن تعمیم ندهید. بسته به Android یا iOS و نحوه Navigation، Headerهای ارسال‌شده می‌توانند متفاوت باشند؛ بنابراین Request واقعی همان Flow باید بررسی شود. برخلاف مرورگر معمولی، در WebView ممکن است نحوه ایجاد Headerها به پیاده‌سازی Native نیز وابسته باشد.

اگر از چند Subdomain استفاده می‌کنیم چه؟

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

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

بعد از پیداکردن مغایرت چه کار کنیم؟

بعد از شناسایی مغایرت ابتدا مشخص کنید مسئله در کدام سمت قرار دارد:

• اگر مقدار واقعی Callback یا مسیر آغاز پرداخت اشتباه است، تنظیمات پیاده‌سازی باید اصلاح شود. برای بررسی ساختار درخواست ایجاد تراکنش و پارامترهای درگاه می‌توانید به مستندات فنی جیبیت مراجعه کنید.
• اگر Flow فعلی کسب‌وکار عمداً روی دامنه دیگری قرار گرفته است، برای بررسی یا اصلاح دامنه ثبت‌شده ترمینال باید موضوع را از مسیر پشتیبانی جیبیت پیگیری کنید.

بهتر است قبل از هر تغییر، سه مقدار دامنه ترمینال، Callback و Referrer را ثبت کنید. بعد از اصلاح نیز همان Flow را دوباره آزمایش کنید تا مشخص شود مقادیر واقعی در Production تغییر کرده‌اند.

اگر مسئله شما به دامنه مربوط نیست و مشکل در IP مبدأ درخواست‌های ایجاد تراکنش است، راهنمای کدام IP را برای درگاه پرداخت ثبت کنیم؟ مسیر شناسایی IP خروجی واقعی سرور را توضیح می‌دهد.

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

پیش از پایان، بررسی این پنج مورد کافی است:

• دامنه ثبت‌شده همان ترمینال را مشخص کرده‌اید.
• Hostname دامنه واقعی Callback در Production را بررسی کرده‌اید.
• دامنه Referer واقعی یک پرداخت را در جریان اصلی مشاهده کرده‌اید.
• تمامی Flowهای مستقل، دامنه‌های متفاوت و WebView را جداگانه آزمایش کرده‌اید.
• اگر از چند Subdomain استفاده می‌کنید، مطمئن شده‌اید اطلاعات پذیرندگی آن‌ها یکسان است.

جمع‌بندی

برای تشخیص مغایرت، دامنه ثبت‌شده ترمینال را با دامنه واقعی Callback و Referrer مقایسه کنید. اگر یکی از آن‌ها به دامنه اصلی دیگری تعلق دارد، مسیر واقعی پرداخت و آخرین تغییرات زیرساخت را بررسی کنید. Subdomainهای همان دامنه نیز تا زمانی که به همان پذیرنده تعلق داشته باشند، به‌خودی‌خود مغایرت محسوب نمی‌شوند.