اتصال برنامه اندرویدی به درگاه پرداخت ePayBank.ir

با سلام خدمت تمام کاربران سایت

من برای مدیریت سایت ePayBank.ir پیام دادم و ایشان قبول کردند که سیستم پرداخت درون برنامه ای را برای ما پیاده سازی کنند تا ما از زیر ظلم مارکت های ایرانی بیرون بیاییم

از همه شما عزیزان خواهشمندم که با ایشان همکاری بفرمایید

ممنون

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

• عدم توانایی نظارت بر برنامه ها
• شکایت کاربران از برنامه شما
• خطا در پرداخت در برنامه شما
• و ...

می تواند دلایل بسته شدن برنامه شما باشد ( حالا چه دروغ و چه راست )

پس این موضوع در کل پسندیده است ولی ممکن است در شرایط «بازار» برای شما مفید نباشد و حتی ضرر هم داشته باشد.

چنانچه از این نظر برای دوستانی که همفکری می کنند و مدیریت محترم ePayBank.ir مشکلی نباشد، ادامه این تاپیک مفید به نظر می رسد.

سلام 

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

اما در مورد شیوه ی پرداخت  :

حجم کتابخانه کم باشه !
راه اندازی کم دردسر باشه !

الان برای پرداخت درون برنامه ای بازار ، هزار تا آموزش اینور اونور هست اما هنوز که هنوزه ، خیلی ها مشکل دارن !

به نظرم من پرداخت به این شکل باشه خوبه (اگه با دیزاین پترن بیلدر باشه که بهترهم میشه) 

epaybank.requestPayment(SellerID,CleintID,ProductID,MyWebView,listener) 

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

وقتی شما برنامه اندرویدی برای فراخوانی intent اون برای پرداخت ندارید ( مثل بازار که صفحه ی پرداخت اش باز میشه ! )  پس طبعا باید پرداخت رو از طریق صفحه ی وب انجام بدید ! ، این کار در اندروید باید در WebView انجام بشه که برای برنامه نویس قابل کنترل باشه ، کتابخانه ی شما باید یک Listener برای رویداد onPurchasFinished (اتمام عملیات ، موفق یا ناموفق ! ) داشته باشه ، پس باید به این شکل تعریف میشه  :)

epaybank.onPurchaseFinishedListener listener = new epaybank.onPurchaseFinishedListener(){

	@Override
	public void onPurchaseFinished() {
		int Result = epaybank.getPurchaseResult(clientID,ProductID);
		switch(Result){
			case 1:
			
			break;
			
			....
			....
		}
	}
			
};

این چیزی بود که تو چند دقیقه به ذهن من بی سواد رسید و فکر کنم راه اندازیش برای کاربر ساده باشه ، اما بازم نیاز به برسی داره که آیا عملی هست یا نه ( و یادمون باشه که کار نشد نداره D: ) 

موفق یاشید

این کار باید خیلی اصولی انجام بشه. و باید یک API صحیح درست کنیم. قول نمی دم اما سعی میکنم که API رو براش Design کنم و حتی Lib برای Android رو هم بسازم.

برای مشخص تر شدن قضیه لطفاً دوستان یک لیست از امکانات بازار در پرداخت درون برنامه ای رو بذارن که همش رو API کنیم.

حتی جزئی ترین امکانات رو هم بذارید. لطفاً تو نظر همین جواب درج کنید. اگر هم چند تا نظر نیاز بود هیچ ایرادی نداره.

با سلام و عرض ادب و احترام خدمت دوستان گرامی

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

نحوه ارسال پارامتر ها به چه صورت بهتر است باشد ؟

گزینه اول : بصورت درخواست soap و فراخوانی متد با ارسال پارامترها بدان که سیستم فعلی بر این اساس می باشد 

گزینه دوم : پردازش درخواستهای POST یا GET شده بر روی HTTP به آدرس خاصی در ePayBank.ir

گزینه سوم :  پیشنهاد شما 

نحوه پردازش جواب  ارسالی از ePayBank.ir به منظور استعلام وضعیت پرداخت به چه صورت میخواهید باشد؟

گزینه اول ) بعد از پرداخت موفق / ناموفق برنامه با استفاده از پروتکل SOAP درخواست استعلام را به وب سرویس ارسال نماید و در نهایت با توجه به پاسخ وب سرویس نسبت به ارایه خدمات خویش به کاربر اقدام نماید.

گزینه دوم ) بعد از پرداخت موفق یا ناموفق ، با استفاده از درخواست POST یا GET بر روی HTTP به آدرس خاصی در ePayBank.ir جواب را در برنامه اندرویدی پردازش کند که آیا پرداخت موفق بوده است یا خیر ؟

سوال سوم ) بنده سه پارامتر یونیک فعلا در ذهن دارم که برنامه اندرویدی به جانب ePayBank.ir پاس کند. لطفا در انتخاب پارامتر سوم مرا راهنمایی نمایید اینکه کدام گزینه میتواند راحت تر باشد و در ثانی یونیک بودن را نیز لحاظ فرمایید.

الف ) کدپذیرندگی + کد انحصاری اختصاصی برنامه نویس برای بخشی از برنامه خویش در ePaybank.ir + شماره موبایل کاربر

ب) کد پذیرندگی + کد انحصاری اختصاصی برنامه نویس برای بخشی از برنامه خویش در ePaybank.ir + کد imei گوشی

ج) کد پذیرندگی + کد انحصاری اختصاصی برنامه نویس برای بخشی از برنامه خویش در ePaybank.ir + کد انحصاری مشتری که برنامه نویس برایش در ePaybank.ir تعریف کرده است  تا مشخص شود که خدمات برای چه کسی ارایه شده است و یا نشده است؟ 

با پارامتر سوم که یکتا می باشد میخواهیم بدانیم که مثلا مشتری 1 برای اپلیکیشن 1 پذیرنده خاص پرداخت کرده است یا نه؟

با ارسال سه مشخصه فوق میتوان همواره استعلام کرد که نیاز هست که به صفحه پرداخت بانکی ارجاع شود یا خیر؟

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

بسیار سپاسگزار خواهم بود اگر نظرات دوستان را در مورد سوالات خویش دریافت کنم.

موفق باشید

ePayBank.ir

در جواب دوست عزیز ePayBank:

JSON یا XML :

استفاده از JSON بر XML - SOAP به چند دلیل بهتر است:

• JSON بسیار کوتاه تر است و Optimize ( از نظر پهنای باند ) است
• JSON برای برنامه نویسی Javascript که بسیار در این مورد مفید است، Native است
• JSON به راحتی در اندروید/جاوا Parse می شود
• JSON کمتر دچار خطا می شود
• JSON به راحتی در Java/Android قابل ساختن است

UUID چیست ( جواب یکی از سئوالات ) :

کد یکتایی است که توسط ما قابل تولید است. توجه داشته باشید که:

• شماره سیم کارت در ایران قابل برداشتن نیست ( به آن دسترسی نداریم ).
• کد IMEI همیشه وجود ندارد ( در خیلی از Tablet ها )
• کد Android ID هم خیلی جاها وجود ندارد.
• MAC ADDRESS قابل جعل شدن است

پس UUID ترکیب این سه عبارت است ( به هر شکل ترکیب شود مهم نیست ):

imei-android_id-mac_address

حتی می تواند ترکیب Encode شده غیر قابل بازگشتی مثل sha1 آن باشد.

امنیت :

برای امنیت حتماً باید از الگوریتم های مناسب مثل AES برای Encode کردن خروجی از Client و خروجی از Server استفاده شود. الگوریتم AES پیشنهاد می شود چرا که iv می تواند همان UUID باشد. به این شکل محتوای خارج شده از Client و Server به هیچ عنوان قابل جعل نیست ( چون IV در تغییر است )

POST, GET, JSON, XML کدام به عنوان ورودی استفاده شود؟

دو گزینهPOST, GET مردود هستند، چون قابل ویرایش و تفکیک پذیری هستند.

XML هم به دلایل بالا ضعیف تر از JSON عمل می کند.

نیاز به امنیت اطلاعات داریم پس AES Encoded JSON پاسخ خوبی است.

از صفحه وب استفاده شود؟

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

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

صحت تراکنش و ورود:

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

مطمئناً امکان ارسال اطلاعات اضافی دلخواه برنامه و برگشت آن نیاز است که می تواند توسط redirectUrl ها انجام شود.

با سپاس از دوستان گرامی

لطفا برای راهنمایی دقیق اینجانب اعلان نمایید که واقعا دسترسی به شماره سیم کارت و Imei امکان پذیر نیست؟

http://www.learn-android-easily.com/2013/05/getting-imei-number-and-other-details.html

http://www.yogeshblogspot.com/getting-phone-numberimei-number-and-sim-card-id-in-android/

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

پیاده سازی api طبق درخواست دوستان طرف ePayBank.ir خواهد بود و پیاده سازی کتابخانه اندرویدی برای پوشش برنامه نویسان اندرویدی بنظرم بهتر است طرف یکی از دوستان برنامه نویس باشد چون در سمت تیم فنی ما اولویت مهم بودن روی  پارامتر ورودی و خروجی و امنیت و نحوه تولید آنها چه در سمت client و چه در سمت سرور می باشد.

لطفا امکانات بازار را نیز برای اینجانب اعلان نمایید. اینکه پرداخت ماهیانه بصورت اشتراکی نیز وجود خواهد داشت؟

اطلاعات کارت در سمت شاپرک خواهد بود که جدا از درگاه پرداخت ePayBank.ir می باشد.

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

برای اینکه موضوع روشن تر شود میتوانید به وبلاگ mortezasaheb.mihanblog.com مراجعه نمایید و صفحه بانکی را مورد بررسی قرار دهید. درگاه پرداخت ePayBank.ir فقط تنها شماره 16 رقمی کارت یا شماره شبا را جهت انتقال وجه بهنگام تسویه حساب دریافت می کند .

با تشکر تمام موارد تست شد ، پشنهاد ها /  باگ ها از این قرار هستند !

1 - پنل کاربری سایت ضعیف به نظر میرسه ،

2 - من 550 تومان پرداخت کردم ( حداقل مبلغ در کافه بازار 100 تومان هست :| ، ممکنه ما بخوایم یه تصویر رو به کاربر بفروشیم  پس شاید این مبلغ مانع باشه ! ) با موفقیت انجام شد.

3 - همانطور که در کامنت بالا گفتم در صفحه ی callback_novin.php به جای یک متن فارسی که پردازش اش کار سختی هست ، بهتره یک رشته ی JSON به ما بدید ، روال فعلی که نمایش متن فارسی و در صفحه ی بعد کد مرجع هست حرفه ای به نظر نمیرسه ! ، اما اگه JSON باشه ما هم برسی می کنیم وقتی وارد این صفحه شد ، اتوماتیک روند پرداخت رو خاتمه میدیم و با پردازش رشته پیام مناسب رو به کاربر میدیم و دسترسی کاربر رو تغییر میدیم :)

4 - وقتی کاربری یک بار پرداخت داشت ، دوباره سعی کرد پرداخت کنه ، شما باید همون پرداخت قبلی رو برگردونید ، مگر اینکه خرید قبلی رو مصرف کرده باشه ، اما در روال فعلی ، دوباره به صفحه ی پرداخت هدایت میشه !

 5 - پس باید یک روال هم برای مصرف خرید در نظر بگیرید !

6 - چرا همه ی عملیات رو با یک وبسرویس انجام نمیدید ؟ ، الان یک بار درخواست به verify2.php و یک بار به payment2.php ارسال میشه ، با این حساب برای مصرف هم باید یک صفحه consume2.php در نظر بگیرید ؟! ، میشه به این شکل عملیات رو هدایت کرد که البته شاید به نظرتون مهم نباشه ، اما کار رو حرفه ای تر نشون میده :)

paymentManager.php?Action=consume
paymentManager.php?Action=pay
paymentManager.php?Action=verify

7 - ممکنه برنامه های ما دیتابیس سمت سرور نداشته باشن ، پس ما چطور این کد مرجع رو ذخیره کنیم ؟ ، در واقع نیازی نبوده ذخیره ی این کد رو به ما بسپارید ! ، ما فقط اطلاعت پذیرنده + کد یکتا ای که برای کاربر ساختیم + شناسه محصول رو بدیم ( که همه ی اینها همیشه در برنامه هستن ) و  شما بگید محصول مصرف نشده با این مشخصات داره یا نه ! ، بهتر نیست ؟

8 - یه موضوع خیلی جالب واسم این merchentpass بود ! ، آخه چرا باید پسورد رو تو برنامه ی سمت کاربر قرار بدیم ؟ ، شما باید یک API Key برای ما در نظر بگیرید (که از نظر امنیتی بهتر بود برای هر برنامه امکان تعریف محصول جداگانه باشه ، و این key برای هر برنامه ی ما متفاوت باشه ) ، اما حداقل کاری که میشه انجام داد ، اینه که شما با الگوریتم RSA برای ما public / private key تعریف کنید تا تبادل اطلاعات و روند پرداخت امن تر باشه.

9 - به نظر همه ی اینها دلیل های قانع کننده ای می اومدن که من برنامه ی اندروید اش رو ننویسم ! ، پس تا رفع اش منتظر میمونم :)

در کل از پرداخت مارکت ها بهتر بود ، اما این شاپرک این وسط پشت سر هم میپرسه ، درسته ؟ ، پرداخت همین بود ؟ مبلغ همین بود ؟ ، پراخت انجام شد ، تکمیل رو بزن و کلی گیر دیگه :)) 

اما نکته ی مثبت دیگه هم در شاپرک ، تقریبا رسپانسیو بودن اش هست :)

مجدد تشکر میکنم :)

با سپاس از توجه و تست شما

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

- پیش فرض سیستم ما مبلغ 500 تومان برای پردازش می باشد زیرا این سیاست باعث کاهش ارسال تراکنشهای تستی می گردد  که این مورد در سیستم ما به جهت حجم زیاد تستهای انجامی پذیرندگان اتخاذ شده است.

- در صفحه callback_novin.php رسید جهت یادداشت کاربر اعلان می شود که بعدا بتواند پیگیری کند و البته وقتی بر روی لینک کلیک میکنید در صفحه webans.php امکان خروجی json هست، البته اگر مایل باشید روال نمایش کد رسید فارسی و ... را در سیستم حذف می نماییم و فقط خروجی json را در صفحه تولید می کنیم.

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

- برای تفکیک پذیری موضوع پرداختهای درون برنامه ای و جلوگیری از پیچیدگی کدها و debugging آسان فایلهای جداگانه ای در نظر گرفته شده اند و  برای ما بحث امنیت و سادگی انجام تراکنشها و دقت کار مهم می باشد. بهرحال فعلا برنامه ای مبنی بر تغییر این فرایند نداریم

- روال مصرف شدگی همان روال وریفای هست و Verify2.php همان استعلام می باشد.

- برای هر تراکنش خرید برای هر محصولی از هر Device ای در درگاه پرداخت یک کد رسید یکتا تولید می شود و این کدی هست که بهمراه کد پویای دستگاه امکان تقلب را از بین می برد. اگر بفرض مثال شما فقط کد پذیرندگی + کد یکتا برای کاربر + شناسه محصول را ارسال نمایید و برنامه بگوید که این پرداخت کرده است یا خیر ؟ براحتی میتوان این شیوه را دور زد از طریق Decompile کردن سورس برنامه، که همان قضایای crack پیش می آید البته برای کاربران حرفه ای این مورد امکانپذیر هست،بعبارتی کافیست اطلاعات همان کاربر و همان شناسه را در سورس کد جایگذاری کرد مثل همین شیوه ای که سریال ویندوز مایکروسافت را Crack می نمایند. شما با وارد کردن شناسه سریال خاصی که قبلا پرداخت شده است ویندوز خود را اورجینال می کنید و از آن استفاده می نمایید. بهرحال تولید و ارسال کد یکتا دو طرفه باید باشد تا امنیت کافی برقرار باشد، روال اینکه کد رهگیری epaybank.ir را شما برای استعلام ارسال ننمایید نیز میتوان در سیستم لحاظ کرد یعنی فقط کد پذیرندگی ، رمز پذیرندگی، کد شناسه یکتای دستگاه و کد محصول را ارسال نمایید و روال استعلام اینگونه باشد بعبارتی در این حالت دیگر ذخیره کردن کد رهگیری را نیز نخواهید داشت و برنامه نویسی برای برنامه نویس آسان میگردد.  ePayBank.ir  برای هر تراکنش خرید در سیستم کد رهگیری یکتایی را صادر می کند و از روی کد رهگیری که صادر می شود و مشخصات دیگری که دریافت می کند بررسی می کند که این کاربر برای فلان محصول پذیرنده ای پرداخت انجام داده است یا خیر؟ در ثانی در تراکنش انجامی شما بنده مشاهده کردم که شما پارامتر شناسه یکتا برای دستگاه را بصورت پویا یا داینامیک ارسال ننموده بودید یعنی یک رشته ثابت را ارسال کرده بودید که این باعث میشد اگر به شیوه ای که شما بصورت رشته ثابت ارسال کردید پیاده سازی میشد یک کاربر پرداخت را انجام میداد و باقی کاربران سودش را میبردند مثل باگی که الان در مارکت بازار هست ولی خوب سیاست پیاده سازی ما، عین روال بازار نیست.

- روال پرداخت با کدهایی که ما برای پذیرندگان صادر میکنیم به صورت امن انجام می گیرد و شناسه کدپذیرندگی و رمز عبور پذیرندگی یکتا می باشند و اینکه الگوریتم رمزنگاری خاصی را یا روال api خاصی در نظر بگیریم چندان نیازی نیست چون در سیستم ما چند مرحله امنیتی را یک تراکنش طی میکند تا به سمت درگاه بانکی هدایت شود فلذا ما امنیت تراکنشها را تضمین می نماییم

-  در مورد شاپرک نیز کل پرداختهای بانکی PSP های کشور با این شرکت انجام می پذیرند

- در ضمن بنظرم بهتر است بجای استفاده کردن از کلمه باگ ، پیشنهاد یا انتظار عنوان میشد چون کارکرد برنامه درست هست و آوردن کلمه باگ مناسب نمی باشد.

-  در پایان از توجه شما سپاسگزارم و منتظر پاسخ شما هستم.

سلام و خسته نباشید

1- اگه حداقل کف مبلغ برای افراد با مکاتبه قابل تغییر باشه بهتر میشه ، مثلا ممکن هست که برنامه 500 تومانی روزی 10 بار نصب شود ، اما یک برنامه برای فروش محتوای دیجیتال به قیمت 100 تومان روزانه 100 بار فروش داشته باشه که در مجموع سود آور تر هست :)

2- زیاد شدن مراحل پرداخت برای کاربر خسته کننده است ، من به شخصه اطلاعات پرداخت قبض مصرفی هم یادداشت نمیکنم ، چه برسه به یه برنامه ! ، در کل نظر من این بود که JSON در همون مرحله کاربردی تر هست :)

3- شما گفتید "طبق مکاتبات قبلی، برنامه نویس ابتدا باید استعلام بگیرد که این device برای محصول x پرداخت کرده است یا خیر؟ در صورت عدم پرداخت ایشان را به صفحه پرداخت ارجاع دهد" پس ما نگفتیم که کد مرجع رو ما نگه داریم ! ، فقط گفتیم بگیم آیا کاربر user1 برای Product1 پرداخت داشته ؟ و اینکه شما خودتون هم فرمودید "در صورت عدم پرداخت ایشان را به صفحه ی پرداخت ارجاع دهد ، پس یعنی اگه پرداخت شده بود ، اطلاعات پرداخت مصرف نشده ی قبلی را به عنوان خروجی JSON برگردونه و در صورت عدم پرداخت ایشان را ارجاع دهد !

4 - خیر ! ، روال مصرف شدن همان روال Verfiy نیست ، به این روال Consume میگن ، شما زحمت کشیدید و این سیستم رو پیاده کردید ، اما مثل پرداخت تحت وب ، پس درواقع تا اینجا فقط یک کار اضافه نسبت به سایر درگاه ها انجام دادید و اون ذخیره ی شناسه ی یکتای کاربر هست که خودش خیلی عالیه و باعث میشه برنامه ی ما سرور نخواد ! ، اما نکته ی اصلی اینجاست :

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

1. سیستم شناسه ی یکتا رو ذخیره کنه ( که شما خیلی عالی کار کردید و دست ما رو برای ساخت شناسه باز گذاشتید ، و کاملا انجام شده )
2. امکان مصرف محصول وجود داشته باشه (که پیاده کردنش کار سختی نیست ، چون خودم پیاده کردم ! ، کافیه برای هر پرداخت یک ستون isConsume در نظر بگیرید ، و وقتی درخواست پرداخت یا تایید اعتبار اومد ، برسی کنه اگه مصرف نشده بود [isConsume=0] اطلاعات همین پرداخت رو برگردونه)

اگه این مورد پیاد نشه ، تفاوت عمده ای با پرداخت های معمولی نداره :|

5- تمام 14 خط توضیح شما ، مربوط به این میشه که شما برنامه نویس اندروید نیستید ، توجه کنید ، ما داریم واسه کاربر کد یکتا میسازیم ، این کد Run Time ساخته میشه پس کاربر حتی با دیکامپل نمیتونه خرابکاری کنه ! این مسئاله تراکنش جعلی کلا منتفی هست ، مگر اینکه سرور شما حفره ای برای ایجاد تراکنش داشته باشه ، مشکل لایسنس های ویندوز هم همین هست ، رفع این مشکلات برای میکروسافت کار سختی نیست ، اما به دلایلی این کار رو انجام نمیده :)

6- وقتی شما بخش مصرف خرید رو پیاده کنید ، با این الگوریتم امنیتی به مشکل می خورید ، اون موقع بنده برای اثبات باگ این الگوریتم و تست نفوذ در خدمتتون هستم :)

7- در مورد شاپرک مسئله ای نبود و من کاملا تائید کردم .

8 - معمولا کلمه ی باگ برای هرکسی تفسیر مختلفی داره ، من وقتی برنامه ام Error میده میگم ، Bug داشت و باعث سقوط | کرش برنامه شد ! ، در واقع من زمانی از باگ استفاده میکنم که خروجی ، خروجی مورد انتظار من نباشه ، و این اختلاف نظر ، به خاطر نقطه ی دید متفاوت ما هست :)

9   - نکته ای که در بازخورد قبلی فراموش کرده بودم ذکر کنم ، مستندات شما هست ، من به اون ها نمیگم مستند ، میگم چند صفحه توضیح ! ، وقتی شما می تونید اون صفحه رو به عنوان مستند معرفی کنید که تک تک موارد استفاده شده ، خطا ها ، ریدایرکت شدن ها ، ارور کد ها و خلاصه همه چیز شرح داده شده باشه ، مثلا من در شروع پروژه به دلیلی به eCode=-1 هدایت میشدم ! ، حالا این -1 چی هست و چر این اتفاق افتاد رو احتمالا فقط شما می دونید :) ، توصیه میکنم مستندات گوگل برای توسعه دهندگان اندروید رو مطالعه کنید.

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

پاینده باشید :)

آقا لطفا یکی بگه این قضیه به کجا رسید؟؟؟

به غیر از پرداخت درون برنامه مارکت ها راه کار دیگه ای برای پرداخت درون برنامه ای وجود داره که مستقیم به حساب خودمون ریخته بشه و کسی ازش درصد برنداره؟؟؟

سلام دوستان 

آموزشی خوب در زمینه اتصال مستقیم به درگاه بانکی پیدا کردم میتونید با استفاد از اون با کامزد کم به درگاه بانک متصل بشین 

خیلی راحت ...

لینک http://androidpower.ir/index.php/product/pt_payment_bitpay/