مشکلات درگاه پرداخت الکترونیک را در ایوند چطور حل کردیم؟

تاریخ: ۲۱ دی ۱۳۹۵
مشکلات درگاه پرداخت الکترونیک

کار کردن تو ایران یه کمی سخته. چرا!؟ چون هرچندوقت یه بار چند تا از روترها از کار می‌افتن و همه‌ی کانکشن‌ها از خارج به ایران محدود می‌شن.

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

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

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

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

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

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

مشکل کی پیش میاد؟

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

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

و فکر می‌کنید در این لحظه چه اتفاقی رخ میده؟

رینگ رینگ رینگ…

این آواز خوش زنگ تلفن‌هاست که پرده‌ی گوش شما رو نوازش می‌کنه…

و مشتریان شاکی از این‌که به شما اعتماد کردن و کل فروش‌شون را به شما سپردن!

طبیعتا شما رو استرس برمی‌داره ولی هیچ‌کدوم از درگاه‌های پرداخت حتی به تلفن فروش‌شون هم جواب نمی‌دن چه برسه به پشتیبانی!

مشکلات درگاه پرداخت الکترونیک در ایران

مشکلات درگاه پرداخت الکترونیک در ایران

راه‌حل‌هایی که به ذهن‌مون می‌رسید، اینا بودن:

  1. باید یا سرورمون رو به صورت کلی به ایران انتقال می‌دادیم.
  2. یا از سرویس‌های پرداخت واسط استفاده می‌کردیم چون اونا هم سرور داخلی داشتن هم سرور خارجی.
  3. یا سرور در ایران داشتیم که پرداخت‌ها رو با اون هندل می‌کردیم.
  4. یا راه‌حل اصلی دیگه‌ای که بهش می‌رسیم!

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

اگه از راه حل دوم -رفتن روی سرویس‌های پرداخت- استفاده می‌کردیم، باز همون مشکل رو داشتیم. چرا؟ چون این سرویس‌ها فقط مشکل اینماد رو حل می‌کنن و مشکل fail شدن درخواست‌ها به سرورهای بانکی پابرجا می‌مونه.

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

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

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

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

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

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

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

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

مشکل و راه‌حل

مطالب مرتبط

نظرات بازدیدکنندگان

  1. کاوه گودرزی می‌گه:

    مرسی امیر
    عالی بود

  2. حسین گل حسینی می‌گه:

    عالی بود پسر !

  3. محسن می‌گه:

    ایول
    حرکت خلاقانه و جسورانه‌ای به لحاظ امنیتی بوده
    ولی بازم کاربرهای با vpn با این روش مشکل میخورن درسته ؟
    و اینکه ممکنه این وسط تو مرحله آخر ارتباط اینترنت کلاینت قطع بشه و بعد از گرفتن دیتا از بانک نتونه صحت پرداخت رو به سرور اصلی پاس بده ، درست میگم یا من اشتباه متوجه شدم ؟

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

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

  4. فرنباز می‌گه:

    “پس راه حل این بود که ما دیتایی که نیاز داشتیم به درگاه الکترونیک بفرستیم رو توسط کلاینت کاربرمون انتقال بدیم و همین‌طور در برگشت هم دیتا رو توسط کلاینت کاربرمون به سرور خودمون منتقل کنیم”
    منظورتون از این جمله اینه که کاربر رو با یک ریدایرکت به آدرس سرور داخلی منتقل می‌کنید و اطلاعات رو توی url میفرستید؟ یا اطلاعات بعد از لود شدن سایتی که روی سرور خارجی قرار داره، به سرور داخلی ارسال میشه؟

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

  5. آرمان می‌گه:

    درود
    بنده استفاده از cdn رو توصیه میکنم

    1. آرمان جان cdn هیچ کمکی برای این مشکلی که ما داشتیم نمیکنه .

  6. امیر می‌گه:

    سلام
    مطلب جالبی بود.
    ولی نمیدونم تا کی باید این مشکلات عجیب هنوز تو ای تی کشور وجود داشته باشه.
    به پرداخت 3 روز قطع بود و نه اطلاع رسانی کرد . نه، ععذر خواهی می کنن. در تماس های ما هم میگین همینه سرورتون رو بیارید ایران.
    به نظرم باید خیلی جدی گرفته بشه که دیگه شرکتی به این راحتی از وظیفه ای که داره شونه خالی نکنه و حتی شاکی نشه از ما.
    تااونجا که میدونم فقط مشکل از به پرداخت بوده. درسته ؟

    1. نه به اونا هم ربط نداره و مشکل از زیر ساخت بوده ، وقتی زیرساخت ارتباط بین خارج و ایران رو قطع میکنه این مشکل برای همه پیش میاد و خیلی به درگاه یا سرویس خاص مربوط نمیشه .

  7. مجتبی می‌گه:

    سلام
    ما هم رو کلی مشتری این مشکلو داشتیم،
    موقع وصل شدن از سرور برای پرداخت، عملیات رو با پروکسی ایران (سرور اصلی خارج از ایران هست) انجام میدم، بهترین راه هم همینه، در واقع درخواست پست که تقریبا تحت هر شرایطی با پست ارسال میشه، پست از سمت کاربر هست و به احتمال زیاد آی پی ایرانه، ولی موقع دریافت توکن یا لاگین و یا وریفای (بسته به درگاه پرداخت و متدی که داره) پروکسی ست میکنم، و از آی پی ایران درخواست‌ها رو انجام میدم 🙂

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

    فقط مسئله این کار خرید یک سرور یا vps واسط هست، که اونم مهم نیست چی باشه 🙂 یعنی رم ۲۵۶ هم داشته باشه کفایت میکنه، چون فقط کار پروکسی رو برامون انجام میده، همینطور اینکه باید آی پیش تو سیستم بانک تعریف بشه.

    مزیت اینکار نسبت به کاریکه شما انجام دادین اینه که، لازم نیست دیتای اضافه ارسال کنیم، و درگاه‌هایی مثل آسان پرداخت و (گاهی هم پاسارگاد) که نسبت به دامنه حساس هستن بدون مشکل کار می‌کنن و باز نیاز به یک سیستم واسطه برای انتقال ازون دامنه نداریم!

    1. مجتبی جان اینم روش خوبیه ولی اون زمان که ما داشتیم این روشو پیاده سازی میکردیم خیلی packet loss داشتیم و عملا هیچ رکویستی به سرورهای داخلی نمیتونستیم بزنیم .
      پروکسی سرورتون باید داخل ایران باشه و چون نمیتونید بهش وصل بشید باز این مشکل سرحاش میمونه .

      1. مجتبی می‌گه:

        من روی یک vps خیلی معمولی رو به ضعیف ایران، توی تبیان پروکسی کردم مشکلی نداشتم، همین ۲ – ۳ هفته پیش که همشون تعطیل کرده بودن 🙂

  8. سید علی سجادی دزفولی می‌گه:

    هم آفرین به دانش فنی بالات و هم آفرین به اینکه این مطلب رو منتشر کردی 🙂

    1. متشکرم ، شما لطف دارین .

  9. حقیقتا تا الان فکر نمیکردم درس رمز نگاری که تو ارشد خوندیم، کلا جایی استفاده بشه..!
    کلید خصوصی و کانال نا متقارن و اینا رو میگم!

  10. وحید نجفی می‌گه:

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

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

Exam: C_TSCM52_66 | 640-875 , 70-697 , 1Z0-060 , 98-365 , NSE7 , 2V0-621D , EX300 , 70-270 , PK0-003 , MB6-702 , 210-451 , 70-532 , C_TSCM52_66 , EX300 | 350-029 , MB2-707 , 350-060   , 300-085 , 70-466 | EX300 | 70-178 , 300-209 , 300-115 , M70-101 , 1K0-001 , C_HANATEC_10 , 70-414 | 70-177 , 642-999 , 350-060 , EX300 , 9A0-385 , 9A0-385 , ICBB , 640-692 , 000-104 , 70-980 , SY0-401 , 300-320 , 1z0-429 | 300-101 | 70-532 , 300-208 , 1Z0-062 , 200-125   , JN0-633   , 1K0-001 , 1V0-603 , 70-413 , 101 , HP0-S41 , 200-105 , OG0-091 , OG0-091 , 70-413 , 70-417 , MB7-701 | 400-051 , 070-461 , 350-030 , 700-037 , 70-697 , 810-403 , MB6-702 , 70-178 , 070-331   , 210-451 , LX0-103 , 000-017 , MB2-703 | 70-483 , JN0-360 , 200-105 , 9A0-385 , 640-916 , 640-864 | PK0-003   , 642-732 , 70-486 , 300-209 , 000-106 , 1Z0-803 , 500-801 | 70-461 | 70-697 , 400-201 , 350-001 , 1Z0-808 , 070-487 , MB2-704 , CGEIT , 600-460 , 200-101 | JN0-343 , 1Z0-062   , 300-320 , 700-260 , 500-260 , 400-101 , 1z0-808 , C_TFIN52_66 , NS0-157 , 70-346 , 98-349 | 3002 , 300-080 , 700-260 , 1Z0-808 , 70-332 , 250-272 | 1V0-601 , 700-801 | 98-349 | 1Z0-062 , 117-202 , OG0-093 , API-580 , 712-50 , MB2-708 , MB6-703 , 642-874 | 70-413 , 600-199 , 220-801 | 640-692 , 70-332 , 640-911 , CISM , 100-101 | 210-060 , 70-178 , 1Z0-060 , 1Z0-062 , CCD-410 | 300-115 , MB6-703 , 210-065 , 642-999 , 3002 , CBAP , 1Z0-808 , 600-460 , human hair wigs: Lace Front Wigs   , Semi-full Lace Wigs   , Full Lace Wigs   , Human Hair Wigs   , Human Hair Full Lace Wigs   , human hair wigs   , human hair wigs   , human hair wigs   , lace front wigs   , lace wigs   , human hair wigs   , hair wigs   , lace front wigs   , lace front wigs   , lace front wigs   , human hair wigs   , human-hair-wigs    | lacewigsbuy-human-hair-wigs    | divatress-wigs-human-hair    | platinumwigs-human-hair-wigs    | headcovers-wigs-human-hair-wigs    | besthairbuy-wigs    | sistawigs-human-hair-wigs    | bestwigoutlet-wigs-human-hair    | wig-type-human-hair-wigs    | human-hair-wig    | everafterguide-human-hair-wigs    | especiallyyours-wigs    | irresistible-wigs    | epiccosplay-wigs    | divatress-wigs    | lace-front-wigs    | hairsisters-lace-front-wigs    | samsbeauty-lace-front-wigs    | lace-front-wigs-human-hair    | aprillacewigs-lace-front-wigs    | omywigs    | human-hair-wigs    ; omywigs human hair wigs   , lace front wigs   ,