کنید دنبال

مغایرت و خطا در پیاده سازی پرداخت اینترنتی(بخش دوم)

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

بخش دوم : ملاحظات پیاده سازی فلوی پرداخت

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

1)    ثبت درخواست کاربر و الگوریتم پیش از ورود به درگاه و انتقال کاربر به درگاه(Before Payment)

2)    پرداخت توسط کاربر در درگاه

3)    بازگشت کاربر به نرم افزار، تایید پرداخت و ارائه خدمات توسط سیستم(After Payment)

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

بررسی مجدد تمام محدودیت ها در Before Payment

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

1)    قیمت ها بررسی شود.

2)    موجود بودن کالا بررسی شود.

3)    مجاز بودن کاربر برای خرید بررسی شود.

4)    در صورت ورود کد تخفیف توسط کاربر، اعتبار کد تخفیف مجددا بررسی شود.

5)    سایر ملاحظات حساس که در کسب و کار وجود دارد.

سناریوی غلط پنهان در پرداخت را نادیده نگیرید!!!

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

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

اگر رزرو کردن موقت محصول را فراموش کنید، همانطور که در تصویر فوق میبینید، از نظر سیستم هنوز کالا برای هر دو متقاضی موجود است، چرا که هنوز هیچ یک به مرحله ارائه محصول نرسیده اند، بنابراین هر دو اشتباها وارد درگاه میشوند و کاربری که دیرتر از درگاه خارج میشود دچار مشکل خواهد شد. اما سناریوی درست به صورت زیر است.

طول زمان رزرو موقت را بیشتر از مدت مجاز برای پرداخت در درگاه بگذارید.

بازبینی مجدد اطلاعات در AfterPayment

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

به Client اعتماد نکنید

گاهی حفره های امنیتی زمانی ایجاد میشوند که داده های حساس سیستم را از کلاینت دریافت کنید. مثلا در یکی از مراحل سفارش گیری،  قیمت را پس از محاسبه به کاربر اعلام میکنید و سپس به دلایل مختلف(مثلا عدم محاسبه مجدد قیمت به دلیل پیچیدگی) همان قیمت را از کاربر دریافت میکنید و او را با همان مبلغ به درگاه میفرستید. قاعدتا اگر شخص هکری از این موضوع اگاه شود، به سادگی با تغییر در قیمت، با مبلغ بسیار پایین خدمات را دریافت خواهد کرد.

البته شاید سناریوی مطرح شده بدیهی به نظر برسد، اما موارد متعددی وجود دارد که به دلیل پیچیدگی سیستم و کم تجربگی، از دید توسعه دهنده دور میماند. بنابراین همیشه داده های حساس قابل محاسبه توسط سیستم را در تمامی مراحل حساس مثل پرداخت، مجددا محاسبه کنید و از Client داده حساسی را دریافت نکنید.(در سناریوی فوق در Before مجددا قیمت را محاسبه کنید و از کاربر فیلد قیمت نگیرید.)

از Double Spanding جلوگیری کنید

زمانی که کاربر در درگاه پرداخت اطلاعات کارت را وارد نموده و روی دکمه تکمیل پرداخت کلیک میکند، توسط سرویس بانک به یک ادرس اینترنتی از نرم افزار ما منتقل میشود.(ادرس After Payment) ممکن است کاربر بارها و بارها این صفحه از نرم افزار را رفرش کند. در این زمان چه اتفاقی خواهد افتاد؟ اگر الگوریتم شما به دلیل عدم شناخت صحیح سرویس بانک و یا کم دقتی به گونه ای نوشته شده باشد که با هر بار رفرش و دریافت پیام موفق، خدمات را مجددا ارائه کنید، آنگاه به ازای یک پرداخت چندین بار خدمات داده اید. بنابراین حتما موضوع Double Spanding را تست نموده و از صحت عملکرد سیستم در چنین مواردی اطمینان حاصل کنید.

ترجیحا ساز و کاری ایجاد کنید که در صورت رفرش صفحه پرداخت توسط یک کاربر در یک بازه زمانی مشخص(مثلا 1 دقیقه) خود به خود با نمایش پیام مناسب از انجام الگوریتم AfterPayment جلوگیری شود.(به زبان عامیانه اگر کاربر تا یک دقیقه، ادرس After رو رفرش کرد، بفرستیدش به فلوی عملیات مشکوک و اجازه اجرای الگوریتم اصلی پرداخت رو ندید.)

از ORM استفاده نکنید!!!

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

مدیریت خطاهای Exception را فراموش نکنید

در مراحل پرداخت به هیچ وجه Exception مدیریت نشده‌ای باقی نگذارید. در تمامی بلاک های خاص و حساس بر حسب الگوریتم پرداخت، Exception ها را مدیریت کنید و در صورت بروز آنها عملیات صحیحی را انجام دهید. به طور مثال گاهی ممکن است مدیریت یک Exception مشخص کننده ناموفق بودن عملیات باشد و پول کاربر را بازگردانید و در یک قطعه کد دیگر ممکن است Exception به معنی نامشخص بودن نتیجه عملیات باشد و به کاربر پیام خطای مناسب نمایش داده و مبلغ را تا زمان مشخص شدن علت مشکل نزد خود نگه دارید.

ثبت لاگ را فراموش نکنید

در تمامی قسمت های حساس و مهم که ممکن است خطایی رخ بدهد لاگ ثبت کنید. لاگ ها، نیروهای ویژه و قدرتمندی برای تشخیص و رفع مغایرت هستند.

با صبوری تمام سناریوهای محتمل را تست کنید.

تمامی کدهایی که توسعه داده اید را تست کنید و هیچ یک را به صورت پیشفرض صحیح و بدیهی تصور نکنید.

شما میتوانید این مقاله را در وبسایت ویرگول مشاهده نمایید.

نظر خود را بنویسید.

Theme Skin
Select your color