قطعا در هر سیستم نرم افزاری، "پرداخت" یکی از مهم ترین و چالش برانگیزترین قسمت هاست و پیاده سازی درگاه های پرداخت نیازمند دقت بسیار بالایی در رعایت برخی اصول است. به طور کلی در تمامی کسب و کارها قسمت هایی که با پول و یا اعتبار کاربران درگیر است از اهمیت و حساسیت بسیار بالایی برخوردار است و وجود مغایرت در پرداخت میتواند عواقب جبران ناپذیری برای کسب و کار به همراه داشته باشد.
در این مقاله قصد داریم شکل های معمول و پرتکرار بروز مغایرت و روش های جلوگیری از آن را بررسی کنیم.
مقاله در دو بخش نوشته شده است. در بخش اول به معرفی مفاهیم دخیل در بروز مغایرت و سناریوهای مختلف میپردازیم و در بخش دوم(برای مشاهده کلیک کنید.) به بیان تجربیاتی کلی و بسیار مهم در مورد نحوه پیاده سازی سیستم پرداخت و اصولی که باید رعایت کنید میپردازیم. در صورتی که تجربه کمی در پیاده سازی سیستم های پرداخت دارید، در این مقاله بسیاری از فاکتورها و تجربیات مهم در پیاده سازی یک سیستم پرداخت دقیق و بدون خطا را خواهید شناخت.
مغایرت در سیستم را میتوان به معنی عدم تطابق سناریوی رخ داده در سیستم و سناریویی که انتظار آن را داریم دانست که موجب وقوع عدم همخوانی ارقام و داده ها میشود.
(طبیعتا در سیستم های مالی، عدم تطابق ارقام ممکن است موجب ضرر و زیان قابل توجهی شود. به طور مثال فرض کنید که در یک ماه، به اندازه 100 میلیون تومان کالا فروخته باشیم و در حساب 80 ملیون تومان واریز شده باشد. در این سناریو 20 ملیون تومان مغایرت داریم که ممکن است به دلیل خطاهای سیستم اتفاق بیفتد.)
· عدم اجرای صحیح سناریوهای موفق در ارائه خدمات که در صورت عدم کنترل صحیح میتواند موجب بروز مغایرت شود.
به طور کلی در سیستم های نرم افزاری و با توجه به ماژولهای مختلفی که در یک عملیات پرداخت دخیل هستند، امکان بروز خطا و مشکل انکارناپذیر است و عامل اصلی بروز مغایرت همین خطاهاست. بنابراین رویکرد ما در جلوگیری از مغایرت به دو شکل زیر خواهد بود:
1) جلوگیری از وقوع خطا و مشکل تا حد ممکن.
طبیعتا هیچ گاه نمیتوان خطا را به صفر رساند و در بسیاری از سیستم ها، عناصر و ماژولهای بیرونی در بروز یک خطا دخیل هستند؛ اما باید تمام تلاش خود را برای کاهش خطا به کار بگیریم.
2) رویکرد مناسب در هنگام بروز خطا و مشکل.
زمانی که یک خطا روی میدهد و میتواند بستر وقوع یک مغایرت را فراهم کند، باید همواره تلاش کنیم تا پیشبینی صحیحی از خطاهای ممکن داشته باشیم و در صورت وقوع هر یک سناریوی متناسبی را در راستای رفع مغایرت اجرا کنیم. به زودی یک سناریوی خاص از این مورد را بررسی خواهیم کرد.
مفهوم پرداخت در یک سیستم، زمانی معنی خواهد داشت که قصد ارائه یک محصول به کاربر داشته باشیم. با توجه به اینکه چه نوع محصولی ارائه میکنیم، الگوریتم های متفاوتی را برای پیاده سازی درگاه پرداخت خواهیم داشت.
به طور کلی محصولات قابل ارائه به صورت زیر هستند.
سناریو های مختلف مغایرت و خطا با توجه به قرارگیری کالا در دسته بندی های فوق متفاوت است که مواردی از این تفاوت ها در به صورت زیر است.
· فروش یک کالای یکتا به چند کاربر به دلیل عدم کنترل خطای صحیح
· فروش بیشتر از ظرفیت یک کالای غیریکتا به مشتریان
· فروش کالا با قیمت نادرست به دلایلی همانند عدم کنترل دقیق تغییر قیمت لحظه ای، عدم شناخت صحیح توسعه دهنده از فرآیندهای مالی سیستم و یا سوء استفاده کاربران از سناریوهای دیده نشده امنیتی در سیستم.
عناصر دخیل در یک فرآیند پرداخت
برای انجام موفق یک پرداخت معمولا ماژولهای نرم افزاری مختلفی که الزاما متعلق به یک سیستم نیستند و از طریق وب سرویس ها با یکدیگر در ارتباط هستند وجود دارد. از جمله این ماژولها میتوان موارد زیر را نام برد.
1) سرویس درگاه پرداخت بانکی
2) ماژول پرداخت در نرم افزار ما
3) ماژول های ارائه دهنده خدمات در سیستم های نرم افزاری دیگر
برای روشن تر شدن موضوع به مثال زیر توجه کنید.
فرض کنید که در نرم افزار خود قصد فروش بلیت پرواز دارید. سناریوی پرداخت شامل سه قسمت زیر است.
1) سرویسهای درگاه پرداخت: ممکن است از هر یک از PSP هایی که امکان ارائه درگاه دارند، سرویس بگیرید. (درگاه های مختلف مثل بانک زرین پال، سداد، به پرداخت ملت، آسان پرداخت و ...)
2) الگوریتم های نرم افزار ما: قطعا شما نیاز دارید اطلاعات پرواز خریدار را به سرویس دهنده ارائه کنید، مبلغ را از طریق درگاه پرداخت دریافت کنید و سپس دستور صدور بلیت را به سرویس دهنده بدهید.
3) ماژول ارائه سرویس پرواز: آژانس های هواپیمایی مختلفی هستند که به صورت وب سرویس امکان رزرو بلیت را فراهم میکنند و شما باید از طریق آنها بلیت را دریافت کرده و به کاربر تحویل دهید.
همانطور که در مطالب بالا مشاهده کردید، در یک فرآیند فروش بلیت سه ماژول از سه سامانه مختلف دخیل هستند. در صورت عدم پاسخگویی صحیح هر یک از ماژولهای فوق، یک خطا روی خواهد داد و اگر خطا به درستی مدیریت نشود، میتواند موجب بروز مغایرت شود.
مدیریت خطا به این معنی نیست که سیستم به هیچ وجه نباید با مشکل مواجه شود. طبیعتا هر مقدار که تعداد ماژولهای نرم افزاری دخیل در یک عملیات افزایش میابد، جلوگیری از خطا سخت تر و ناممکن تر میشود. بنابراین مدیریت خطا را میتوان در دو مورد زیر خلاصه کرد:
1) پیاده سازی سناریوهای مدیریت خطا به صورت خودکار در سیستم تا حد ممکن و جلوگیری از مغایت
2) مدیریت خطاهای غیرقابل کنترل توسط سیستم از طریق تیم پشتیبانی محصول
طبیعتا اگر سیستم نتواند به صورت خودکار خطا را مدیریت کند، نیاز است تا ماژولهای اطلاع رسانی تقویت شوند و تیم پیشتیبانی با روشهای صحیح مانع بروز مغایرت شود.
با توجه به دو مورد فوق، کلید اصلی مدیریت خطا و جلوگیری از مغایرت را میتوان، پیشبینی صحیح از خطاهای ممکن در سیستم و ارائه راهکار سیستمی یا غیر سیستمی برای هر نوع خطا دانست.
مراحل رزرو بلیت معمولا به صورت زیر است:
1) رزرو اولیه بلیت
2) دریافت مبلغ از کاربر
3) صدور نهایی بلیت
سناریو شماره 1
در موارد بسیاری ممکن است در مرحله صدور نهایی بلیت و پس از دریافت مبلغ از کاربر به دلیل طولانی شدن بیش از حد فرآیند توسط سرویس دهنده، خطای time out اتفاق بیفتد. در این زمان دو سناریوی زیر اتفاق میفتد:
1) اگر پول را به کاربر پس بدهیم، ممکن است سمت سرویس دهنده صدور بلیت موفق بوده باشد و متضرر شویم.
2) اگر پول را برنگردانیم، کاربر نسبت به عدم دریافت بلیت معترض خواهد بود.
هر دو سناریوی فوق در حالت عادی باعث بروز مغایرت میشود. در چنین مواردی باید یک تصمیم گیری کلی از سمت سازمان در مورد برگرداندن یا عدم برگرداندن پول به کاربر اتخاذ شود و باقی مراحل رفع مغایرت توسط تیم پشتیبانی و از روش های غیرسیستمی حل شود.
سناریو شماره 2
در مواردی ممکن است، قیمت بلیت در حین عملیات پرداخت دچار تغییر شود. دو سناریوی زیر ممکن است اتفاق بیفتد:
1) تکمیل پرداخت با قیمت قبلی که موجب بروز مغایرت میشود.
2) اصلاح قیمت در حین مراحل پرداخت که تقریبا ناممکن و بسیار پیچیده است.
3) ناموفق کردن عملیات، عدم درخواست صدور بلیت نهایی و برگرداندن مبلغ پرداخت شده به کاربر
فرض کنید که قصد دارید تا سامانه ای برای فروش شارژ راه اندازی کنید. اگر در این سامانه خطای time out اتفاق بیفتد دو سناریوی زیر محتمل است.
1) پول کاربر را پس بدهیم. ممکن است شارژ سیمکارت انجام شده باشد و چون غیرقابل بازپس‌گیری است محتمل ضرر شویم.
2) پول کاربر را نگه داریم. ممکن است شارژ انجام نشده باشد و موجب نارضایتی کاربر شود.
در سناریوهای فوق راه حل جلوگیری از مغایرت را سازمان تعیین میکند و صرفا با پیشبینی خطا و تصمیم گیری در مورد آن در سازمان میتوان از مغایرت جلوگیری کرد. ممکن است برخی از سناریوهای پیشبینی شده به صورت سیستمی و برخی به صورت غیر سیستمی مدیریت شوند.
زمانی که کاربر در درگاه پرداخت اطلاعت کارت خود را وارد میکند مبلغ از حساب او کسر شده و کاربر به نرم افزار باز میگردد. در این زمان نرم افزار باید پرداخت کاربر را تایید نهایی و خدمات را ارائه کند. برای تایید نهایی باید دو سرویس زیر به ترتیب فراخوانی شود، در غیر این صورت بانک عملیات پرداخت را ناموفق تلقی کرده و مبلغ کسر شده را پس از نهایتا 24 ساعت به حساب کاربر بازمیگرداند.
1) Verify Transaction
2) Sattle Transaction
زمانی که Sattle انجام شود، مبلغ به طور قطع از حساب کاربر کسر میشود. اما در اینجا یک نکته قابل توجه است. زمانی که کاربر از درگاه پرداخت به نرم افزار منتقل میشود، نوبت به ارائه خدمات ما میرسید. اگر به هر دلیل در ارائه خدمات ناموفق باشیم نیاز است تا مبلغ به حساب کاربر بازگردد. بنابراین درگاه های پرداخت سرویسی با عنوان Reverse Transaction برای بازگرداندن آنی پول به حساب کاربر نیز ارائه میکنند.
یک نکته مهم
سناریوی ایده آل برای کسب و کار به صورت زیر است.
اما همیشه این سناریوی ایده آل قابل پیاده سازی نیست. چرا که برخی از درگاه های پرداخت پس از عملیات Sattle، اجازه فراخوانی Reverse را نمیدهند.
در اینگونه موارد دو سناریو از سمت کسب و کار مطرح میشود.
1) سناریوی به نفع مشتری
ناچاریم قبل از عملیات Sattle، سرویس را ارائه کنیم. در این صورت اگر در ارائه سرویس ناموفق باشیم، متد Reverse قابل فراخوانی بوده و مبلغ به حساب کاربر باز میگردد. اما زنگ خطر زمانی به صدا در می‌آید که اگر با موفقیت سرویس را ارائه کنیم و سپس Sattle را فراخوانی کنیم، اگر فراخوانی Sattle به هر دلیل با خطا مواجه شود، خدمات را به کاربر ارائه کرده ایم و مبلغ نیز به حساب کاربر باز خواهد گشت.
2) سناریوی به نفع کسب و کار
متد Reverse را نادیده میگیریم و قبل از ارائه خدمات، Sattle را انجام میدهیم. بنابراین حتی اگر در ارائه خدمات ناموفق باشیم، امکان بازگشت پول به حساب کاربر به صورت سیستمی وجود ندارد و کاربر از کسب و کار طلبکار میشود.
اجرای هر یک از سناریوهای فوق، وابسته به تصمیم گیری سازمان است و هیچ یک را نمیتوان سناریوی درست تر در نظر گرفت.
اگر این مقاله برای شما مفید بود لطفا با سایر دوستان به اشتراک بگذارید.
مقاله مرتبط بعدی (بخش دوم مقاله)
شما میتوانید این مقاله را در وبسایت آموزشی من به آدرس زیر مشاهده نمایید.
برای پیگیری آموزش ها و مقالات بیشتر، به صفحه لینکدین و وبسایت من سر بزنید.
