چرا کنسل کردن در زمان Verify اهمیت دارد ؟ about parbad

[Sina-Soltani]

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

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

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

[Sina-Soltani]

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

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

[msngithub]

اها نکته مهمی بود چون من پرباد رو به EF Core وصل نکردم و صرفا از Memory استفاده میکردم و خب همه چی در حافظه انجام میشد و بعد تایید پرباد و Verify کردن من ثبت اطلاعات رو در دیتابیس خودم انجام میدادم
با توضیحاتی که شما دادید پس ممکنه بعضی بانک ها هم خروجی دستور Fetch برای IsAlreadyVerified و هم خروجی دستور Verify که Status مقدار PaymentVerifyResultStatus.AlreadyVerified میتونه داشته باشه رو اشتباه برگردونند و این خروجی رو ما از پرباد درست نگیریم ؟
خب توی این شرایط هم من بجای کنسل میتونم همون رکورد فیش پرداختی که دارم رو وضعیتشو مشخص کنم که اجازه ثبت مجدد نده دیگه

سوال مهمی که پیش میاد چه چالش مهمی میتونه استفاده از Memory جهت کار با پرباد برای من درست کنه ؟ با توجه به اینکه گفته بودید حالت Memory رو فقط برای تست استفاده کنید ولی ازونجایی که کل عملیات بانکی اگه در حافظه باشه خب وقتی صفحه Callback اجرا میشه تا من تایید ذخیره توی دیتابیس خودم رو ندم متد Verify رو فراخونی نمیکردم بازم برای من استفاده از Memory چالش درست میکرد ؟
البته نمیدونم بهتر بود این پرسش جدا میبود چون یک مقدار مرتبط بود با پرسش قبل همینجا ارسال کردم

[Sina-Soltani]

خب توی این شرایط هم من بجای کنسل میتونم همون رکورد فیش پرداختی که دارم رو وضعیتشو مشخص کنم که اجازه ثبت مجدد نده دیگه

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

سوال مهمی که پیش میاد چه چالش مهمی میتونه استفاده از Memory جهت کار با پرباد برای من درست کنه ؟ با توجه به اینکه گفته بودید حالت Memory رو فقط برای تست استفاده کنید

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

[msngithub]

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

سوال اول
ممکنه بعضی بانک ها هم خروجی دستور Fetch برای IsAlreadyVerified و هم خروجی دستور Verify که Status مقدار PaymentVerifyResultStatus.AlreadyVerified میتونه داشته باشه رو اشتباه برگردونند و این خروجی رو ما از پرباد درست نگیریم ؟ ( با فرض اینکه از حالت Memory داریم استفاده میکنیم )

سوال دوم
ما الان از دو شیوه میتونیم IsAlreadyVerified رو چک کنیم ، هم دستور Fetch هم دستور Verify ، هر دو اطلاعات رو از سرور بانک داره میگیره ؟ یا یکی سرور بانک یکی دیتابیس خود پرباد ؟ یا در هر دو حالت ترکیب سرور بانک و دیتابیس پرباد هست ؟

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