UPI payments failure in many apps #32
Comments
|
@mdazharuddin1011999 I just did. It is also not working. |
|
I just verified and it is actually failing. This problem is from their side probably due to their efforts to make payments more secure. Until a workaround is found it is better to remove the plugin from pub since basically all prominent UPI apps are unable to complete the transaction. So please migrate to use payment gateways like Razorpay for now. |
|
I have marked the package as |
|
I think you missed good amount of testing before marking it as discontinued. The bug reporter seems to be in a hurry to term things as not working without specifying proper use cases, too. I did some testing today, using my fork of upi_pay's that has changes as in my pending pull request. 2 apps gave errors, that also not about "maximum limit exceeded" or "risk threshold exceeded" which are standard UPI errors that I faced when trying to perform too many transactions per day or very close to each other in time. Several other apps worked. More details in this comment: drenther/upi_pay#18 (comment) and drenther/upi_pay#19 (comment) |
|
As I already said. Currently the package is unusable and I plan to keep it in discontinued until it has been fixed. Also I tested properly with 4 different apps and got same problem in all of them. It may be true that other apps are working for now but popular ones like PhonePe, Amazon pay, GPay and Paytm all failed. |
azhar1038
changed the title
|
That's what my point of saying that discontinuation is premature because some apps do work. You could inform users in README that currently these apps work, and these don't. May be just set up a wiki page here and update it if you can, so your effort can be used with other apps if someone wants to. Otherwise you are just pushing down your own sincere work without enough reason and blocking people from making their own ways of using the package. Of course, if you have other reasons that say that the package is unstable, it's a different matter. |
|
I feel like changes are being made to make those apps more secure. And the apps that are working for now may stop working soon. Also I personally feel like if the big apps are not working, it makes the plugin basically useless from the user point of view. If things start to work, plugin will be back that's not a problem. But at the same time you are also right! So I think changing the status from discontinued to unlist would be better. What do you think? |
|
I disagree with the mindset of labelling some apps as big and some as not. Some of those not being counted as big apps are those that implement SIM linkage for their apps strictly and hence enhance security for users. So any rational user who wants to use UPI for 0 commission discharge will find any working app as good enough; because it doesn't matter which app works. I am totally judging some of the big apps here about their security errors unless they state very clearly what issue they see. Are there any inter process communication/Intent call related new CVEs open for Android causing them to do this? https://www.cvedetails.com/product/19997/Google-Android.html?vendor_id=1224. You got to be transparent when blocking users from getting functional workflows going. Otherwise, we can simply pretend security issues and just stop everything in the world from working. I will accept their "security enhancements" if there are known severe (8+ score) CVEs open in Android Intent APIs. Otherwise, I'll just use other apps. That's the mindset of one of the users of flutter packages like this. I would say that you should not downgrade status of your package, and just maintain a wiki with test reports and include its link in the package README, and clearly state that please use apps reported as not working at your own risk. This way, your whole Intent tunnel is available for everyone who wants to make their own decisions about how and if to use the package. My recommendation will not be to even unlist and keep it alive with these annotations added. |
|
Okay. Thanks for your guidance. I really appreciate it. I will make the package available soon with proper mention about the apps that are not working! |
|
Hello, |
|
I have check that who ever has register UPI for business will get an MCC and only that will pay through this method. |
While that is true, government had also looked to make UPI available for business payments without working as a merchant. See https://economictimes.indiatimes.com/internet/npci-looks-to-encourage-upi-payments-at-small-merchants/articleshow/69860986.cms. This is an evolving field, and corrections like these for making it more organic and practical are happening. That could be the reason why several apps even allowed the payments to go through even if packages like these don't supply the merchant code and the signature. It makes no sense anyway that an individual can use an UPI payment app; but another app sitting on the same mobile cannot do the simple, secure and impotent action of pre-filling the payment form by making a software call towards carrying out such individual payment transactions. User is anyway going to review and enter the PIN to make the payment work, so what's the big deal about preventing non-merchants from using the APIs. |
|
Please look at drenther/upi_pay#17 |
|
So merchant payment is the way to avoid these risk errors? |
|
Most likely the reason. I did tests where I let google pay, phone pe etc. fail with errors that indicate something is wrong with your account overuse, and then test with an app within next 5 minutes on the same calendar day and that works, which completely invalidates the truth of these errors reported by the failing apps. It's a masked error to indicate the same - please sign the requests as a merchant. However; as I have mentioned in the changed README.md, I don't buy this direction of some of these major UPI apps. I believe that user has control over payment as he/she has to use the PIN and also gets a chance to verify all details before entering the PIN. All that such a package is doing is to automate filling a payment form, which has no security dangers in itself. So though I'll be adding support for merchant payments, that would be one of the functionalities, not the only one. Please do review deeply and let me know if you agree with my thinking and direction. If that's the case then I would, over time, bring all my work to this package. |
|
Hi @reeteshranjan, I was unable to make a transaction in PhonePe. So, is it safe to assume that because of security concerns this will not work. Or is there a work around I can look at? |
As far as my testing and knowledge goes, there is no work around. You may see PhonePe documentation to see if there is anything that can help. |
|
So, that's it? No solution? I really needed this now, coz i am intending to make an app for raising fund for my friend who lost all her family due to COVID and using payment gateways like razorpay will not be feasible for us coz they deduct transaction fee. |
|
Sorry to hear about your friend. You can try with merchant account or try using upi_pay plugin. All the best. |
You can use other apps that are working. Few apps don't work properly. You can get more details about what's happening with UPI apps here https://github.com/drenther/upi_pay#upi-apps-functional-status-dynamics, and also look at last known working apps (as per my testing) here https://github.com/reeteshranjan/upi_pay/blob/master/APPS.md. |
|
Please follow drenther/upi_pay#38 |
The last time I have checked with the dev version of the package it was working fine. But today when I have checked nothing is working. I have also tried to switch to the stable version 2.2.0, but the same problem.
The Problem
No matter what UPI app I trigger, it just says, "Maximum limit exceeded...." and the transaction just got failed.
NO ERROR MESSAGE IS LOGGING
Just to cross-check I manually went to GPay & Paytm app to transfer money. It was successful.
The text was updated successfully, but these errors were encountered: