@khanzadimahdi سلام وقت بخیر. این مرج رکويست رو بررسی میکنین لطفا.

@khanzadimahdi سلام وقت بخیر. این مرج رکويست رو بررسی میکنین لطفا.

سلام. مرسی که PR رو گذاشتین و کانفلیکت ها رو رفع کردین.
از اونجایی که توی invoice یکسری متد پابلیک جدید ایجاد شده یه مقدار بحث بر انگیز هست. این متدها بیشتر کاربرد خارجی دارن و با این متدها ما پیاده سازی بیزینس لاجیکمون رو داریم با API بانک کاپل میکنیم. لطفا کمی بیشتر فرصت بدید تا بیشتر فکر کنیم. در نهایت اگه راهکار بهتری پیدا نشد این تغییرات رو مرج میکنیم. ممنونم.

سلام وقت بخیر. با این مرج به راهکاری رسیدین؟
@khanzadimahdi

سلام وقت بخیر. من راجبش فکر کردم. اینکه با یه flag بیایم باگ رو حل کنیم کار درستی نیست!
روشی که به ذهنم میرسه اینه که کاربر باید از ادرس callback برای گرفتن اطلاعات پرداختش استفاده کنه. بدین صورت که شما توی ادرس کالبک میتونید یه توکنی بزارید و بعدش موقع برگشت اون توکن رو برای جستجو توی دیتابیس استفاده کنید

/invoice/1233/verify

مثلا اگه ادرس بالا رو برای callback در نظر بگیریم میتونیم از id مربوط به invoice اطلاعاتشو از دیتابیس بکشیم بیرون.
قبول دارم پکیج باید یه مقدار تغییر کنه تا جلوی این مشکلی که شما بهش اشاره کردین رو بگیره! نباید از invoice uuid برای وریفای کردن پرداخت بانکی استفاده کرد.
میتونیم اون invoice uuid رو کلا حذف کنیم و پکیج رو به صورت major اپدیت کنیم! خودمم دلیلی برای وجود invoice uuid نمیبینم! برای هرکدوم از درگاه هایی که به این مقدار نیاز دارن میتونیم توی کانفیگ یا توی پکیج یه تابع hook اضافه کنیم که بشه یه تابع رو بهش register کرد و چیزی که برمیگردونه رو به درگاه بفرسته.
این تابع رو میتونیم توی config.php خودمون هم بزاریم که یه پیاده سازی پیش فرض داشته باشه.

class Pasargad {
      private static $generatePaymentUuid

     public static function RegisterPaymentUuidGenerator(callable $func) {
          self::$generatePaymentUuid = $func
     }
}

حالا کاربر میتونه نحوه تولید شدن اون کدی که به درگاه میدیم رو کنترل کنه و ما هم از invoice میایم uuid رو حذف میکنیم تا جلوی این روش اشتباه پیاده سازی رو بگیره

نظرتون چیه؟

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

اگه میخوایم breaking change بدیم و تو درگاهایی که نیازش دارن مسولیت پر کردن مقدارشو به عهده کاربر بزاریم، میتونیم ساده تر جلوبریم و صرفا مقدارشو ازشون بگیریم و ولیدیشنش رو تو درایور انجام بدیم و اگه درست نبود یا خالی بود اکسپشن بدیم.
در مورد کانفیگ هم تا جایی که میدونم اگه فانکشن توش پاس بدن به ارور سریالایز میخورن توی کش کانفیگا.
@khanzadimahdi