نيازمندی های پرداخت درون برنامه ای - زرين پال

با سلام،
با توجه به نيازسنجی صورت پذيرفته و جمع آوری مستندات صورت پذيرفته در ساير شيوه های پرداخت موبايلی رايج، عملا صورت نياز عام پياده سازی شده، به صورت زير خواهد بود.

هر درخواست پرداخت بوسيله يک uniqueID مشخص از سوی توسعه دهنده نرم افزار موبايل، مشخص می گردد که می بايست پس از پرداخت به وسيله uniqueID مشخص شده قابليت رهگيری پرداخت وجود داشته باشد. عملا با اين شيوه دوستان قادر خواهند بود که به هر شيوه ای uniqueID را در سمت خودشون ايجاد و به شيوه های متفاوت کنترل نمايند، مثلا برای نسخه های متفاوت نرم افزار، uniqueID های متفاوت ايجاد نموده و با استعلام UniqueID از سوی زرين پال وضعيت پرداخت را مشخص نمايند. ابهام موجود در اين بخش اين هست که شيوه برخورد زرين پال، با اين uniqueID به چه صورتی تعريف گردد و عملا زرين پال اجازه ايجاد درخواست با uniuqueID های تکراری را ميسر نموده و يا بر اساس درخواست اجازه ايجاد درخواست تکراری را ميسر ننمايد.
با توجه به نوع نياز دوستان، ظاهرا زرين پال نبايد کنترلی بر روی اين uniqueID داشته باشد و تنها امکان اخذ گزارشات متفاوت بر اساس پارامتر مورد اشاره ميسر باشد و عملا تکرار درخواست در سمت توسعه دهنده نرم افزار صورت پذيرد.
به صورت نمونه چنانچه با UniqueID درخواست پرداختی ايجاد گردد و در زمان مقرر پرداخت توسط کاربر صورت نپذيرد و يا بنا به هر دليلی پرداخت توسط کاربر با شکست مواجه گردد چنانچه اين کنترل در سمت زرين پال افزوده شده باشد امکان پرداخت ميسر نخواهد بود و عملا اختلالات زيادی ايجاد خواهد شد و باز توليد مجدد UniqueId ها ناممکن خواهد بود.

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

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

به نظر من بهتر است برای uniqueId شما توسعه دهنده را مجاب به استفاده از اطلاعات زیر کنید:

package //ex: com.uncocoder.course.app.calculator
applicationVersion //ex: 2.03
supportedVersion //ex: 1
deviceUuid //ex: 'androidId-IMEI-MAC'
consumable //ex: 0 or 1

• package: هر نرم افزار می تواند تنها یک نام پکیج به خود اختصاص دهد. پس نام پکیج اصلی ترین عامل unique بودن یک نرم افزار است.
• applicationVersion: نسخه نرم افزاری که در حال حاضر جهت استفاده آماده است چون به آن نیاز داریم.
• supportedVersion: نسخه ای که پرداخت با آن سازگار است. به طور مثال اگر ورژن نرم افزار 2.03 باشد و ورژن پرداخت قابل ساپورت 1 معرفی شود، تمام کاربرانی که نسخه 1 و به بعد آنرا خریده اند می توانند از این نسخه هم استفاده نمایند. اما اگر به طور مثال 2 باشد یعنی تنها کاربرانی که نسخه 2 را خریده اند می توانند از از نسخه 2.03 استفاده رایگان نمایند.
• deviceUuid: چنانچه بصورت هر ترکیبی از androidId-IMEI-MAC تعریف شود، می تواند معرف unique بودن Device باشد. پس خرید ها به ازای هر device انجام پذیر خواهد بود. حالا ممکن است شخصی هزاران تومان پرداخت کرده باشد و قصد انتقال License های خود را داشته باشد. این کاملاً نیاز است که توسط API زرین پال ساپورت شود که کار دشواری هم نیست. انتقال License ها باعث می شود نرم افزار در گوشی های پیشین قابل استفاده نباشد.
• consumable: چنانچه این فیلد 1 باشد یعنی خرید برای مصرف است و هیچ مالکیتی را در بر ندارد. به طور مثال خرید جواهرات بازی. در این شرایط فیلدهای applicationVersion و supportedVersion قابل استفاده نخواهد بود. حتی پس از Verify شدن تراکنش توسط کاربر گوشی، این اطلاعات قابل حذف از بانک zarinpal نیز می باشد اما جهت مراجعه آینده اگر نگهداری شود بهتر است. در این شرایط توسط زرین پال هیچ جستجوی جهت تکراری بودن درخواست صورت نخواهد گرفت و هر درخواست در رکورد جداگانه قابل ثبت است.

این اطلاعات می تواند در قالب یک Input به سرور اعمال شود. بهتر است برای خرید های مصرفی API جداگانه ای وجود داشته باشد که مشخص شود که دو فیلد applicationVersion و supportedVersion لازم نیست.