Android Pay and Custom ROM

Status
Not open for further replies.
Search This thread
I tried using Android Pay at the local McDonald's yesterday; Google Wallet via NFC has always worked, but Android Pay gave me a message to the effect of "[Credit Union Debit Card] is not available for use through Android Pay at this time...." I assume that message is different than "your phone's rooted, sux to be you" since I'm able to open the app, add cards, etc. Can anyone confirm this, that my Android Pay is otherwise working, save for my credit union just not being on board yet?

I'm using the downloaded Android Pay app vs. the actual 'upgrade' from the old Google Wallet, btw.
 

luigidk

Senior Member
Dec 6, 2011
718
274
I tried using Android Pay at the local McDonald's yesterday; Google Wallet via NFC has always worked, but Android Pay gave me a message to the effect of "[Credit Union Debit Card] is not available for use through Android Pay at this time...." I assume that message is different than "your phone's rooted, sux to be you" since I'm able to open the app, add cards, etc. Can anyone confirm this, that my Android Pay is otherwise working, save for my credit union just not being on board yet?

I'm using the downloaded Android Pay app vs. the actual 'upgrade' from the old Google Wallet, btw.
That is the same problem we are all having

Sent from my LG-V510 using Tapatalk
 

Citizen_Snips

Senior Member
Apr 23, 2012
4,023
2,554
Google Pixel 8 Pro
Google Pixel Watch 2
No I still had the issue of it not letting me add any cards. I enter the 3 digit security code as promoted and then I hit accept. From there it loads for another few seconds then tells me it cannot verify the OS I am using is android or android compatible and that android pay cannot be used


Edit: I got this email today. So maybe soon? :D

ecbab2bd932b90dc5788ab335323c2d7.jpg

0d7486f2dc9d656c4b517e444dbc2214.jpg
 
Last edited:

ratflinger

Senior Member
Jul 18, 2010
93
3
Just used the OPs method for my root but otherwise stock rom Nexus - worked just fine. Accepted my AMEX & got the confirm email. Like the OP said, under SuperSU setting uncheck the 1st box and that unloads SuperSU, setup Pay & reclick on SuperSU. It comes right back up rooted.
 

dcwiker05

Senior Member
Dec 10, 2008
830
183
Ephrata PA
I have an LG G4 And even rooted I could get to the point where I was able to add a card, but I get this error every time I try... Even did what the op said disabled root cleared data etc

Request failed
An unexpected error has occurred please try again later.

Been trying for days :/
 

Citizen_Snips

Senior Member
Apr 23, 2012
4,023
2,554
Google Pixel 8 Pro
Google Pixel Watch 2
Just used the OPs method for my root but otherwise stock rom Nexus - worked just fine. Accepted my AMEX & got the confirm email. Like the OP said, under SuperSU setting uncheck the 1st box and that unloads SuperSU, setup Pay & reclick on SuperSU. It comes right back up rooted.
Tried dozens of time, literally. Does not work on pure nexus project no matter what.
 

dcwiker05

Senior Member
Dec 10, 2008
830
183
Ephrata PA
Extremely annoying. The old one worked on any custom ROM just fine. Why did they even split the apps? Seems counter productive to me. I was using NFC to tap and pay in 2011/2012 with my galaxy nexus yet I can't use it today with my N5 lol. What gives, Google?
I was wondering the same thing, why can't they integrate wallet into pay and have it be one app, why ha e a separate app just for p2p money transfer. I also thought the same thing when they split docs/slide/spread why not have one app like office suit pro etc. And breaking street view out if maps, if you're gonna take it out of maps, integrate it into earth, it doesn't need to be it's own app. I like having the lest amount of apps possible on my phone and Google has slowly taken 3 apps and split them into like 10 -__-

Sent from my LG-H811 using Tapatalk
 

silvertrain78

Senior Member
May 31, 2014
384
171
I went into my Superuser app and unchecked superuser access fired up Android pay and it work without any problems then I went back to superuser checked it again to allow root rebooted my phone for good measure and all is good. I have root still and Android pay access
Which ROM?

Sent from my Nexus 5 using Tapatalk
 

msgfromside3

Senior Member
Nov 23, 2010
744
131
I went into my Superuser app and unchecked superuser access fired up Android pay and it work without any problems then I went back to superuser checked it again to allow root rebooted my phone for good measure and all is good. I have root still and Android pay access
Are you able to make a transaction with root on? My chase card gave me a crap and I am wondering if it is because I made the transaction with root enabled or chase card's problem like others are saying. I haven't tried again, but wondering.

But yeah, Google broke the experience completely. Wallet worked just fine and now AP is broken.
 

HTCore

Senior Member
Dec 12, 2004
411
78
LA
I was wondering the same thing, why can't they integrate wallet into pay and have it be one app, why ha e a separate app just for p2p money transfer. I also thought the same thing when they split docs/slide/spread why not have one app like office suit pro etc. And breaking street view out if maps, if you're gonna take it out of maps, integrate it into earth, it doesn't need to be it's own app. I like having the lest amount of apps possible on my phone and Google has slowly taken 3 apps and split them into like 10 -__-

Sent from my LG-H811 using Tapatalk

For all banking and credit stuffs, it seems that entirely different entity than Google controls Android Pay. It might be the reason that they separated from Wallet. Though, I think in near future we will see both in one single app.
 
Found this article while browsing through Reddit:

https://koz.io/inside-safetynet/

If I'm reading correctly, this is the reason why APay's not working for custom ROM users? It's all Greek to me, I was scrolling down through this like Wayne in 'Wayne's World' reading the contract he signed:

"Yes...uh huh...yes....mmmm, I like what you've done here....yes....."
 
  • Like
Reactions: adeptustech

baknblack

Senior Member
Sep 12, 2010
637
160
Kentucky
Samsung Galaxy S10+
Found this article while browsing through Reddit:

https://koz.io/inside-safetynet/

If I'm reading correctly, this is the reason why APay's not working for custom ROM users? It's all Greek to me, I was scrolling down through this like Wayne in 'Wayne's World' reading the contract he signed:

"Yes...uh huh...yes....mmmm, I like what you've done here....yes....."

Sounds pretty darn tough to bypass.

Sent from my Nexus 5 using Tapatalk
 
  • Like
Reactions: adeptustech
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 149
    Agreed. If they want adoption to take off, maybe making it accessible to the earliest of adopters would be a good idea.

    Hey Josh,

    Android users who root their devices are among our most ardent fans and when this group speaks, we listen. A few of us around Google have been listening to threads like this one and we know that you're disappointed in us. I'm a security engineer who works on Android Pay and so this thread struck me particularly hard. I wanted to reach out to you all and tell you that we hear you.

    Google is absolutely committed to keeping Android open and that means encouraging developer builds. While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact.

    That "ensuring" is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and--by proxy--real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite--which includes checks for the security model.

    The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases. I know that many of you are experts and power users but it is important to note that we don’t really have a good way to articulate the security nuances of a particular developer device to the entire payments ecosystem or to determine whether you personally might have taken particular countermeasures against attacks--indeed many would not have.

    Let's keep the dialogue open: I'll be monitoring this and other threads for constructive ideas. I won't be able to reply to all messages but we will keep listening. We love our community and we want you to keep challenging us.
    30
    This thread is so embarrassing. We had the chance to work with Google, instead people decided to have a pissing match and use this thread as a forum to vent their frustrations with the "limited" ability of root. Then many go on to site their experience in the Linux or security research community only to provide credibility to their opinion....

    All while no one actually tried to discuss how the security checks take place, what they do, and why they fail, what widevine is, how oemcrypto works to check system properties, or even how through all of this a scm call is made in secure context to the trustzone.

    Also these petty differences on semantics just make us look like more of a idiotic crowd. I know I can't request for a thread to be closed, but if I had one "close this thread because it's embarrassing" card, this thread would hands down be what I'd use it for.
    23
    This thread is so embarrassing. We had the chance to work with Google, instead people decided to have a pissing match and use this thread as a forum to vent their frustrations with the "limited" ability of root. Then many go on to site their experience in the Linux or security research community only to provide credibility to their opinion....

    All while no one actually tried to discuss how the security checks take place, what they do, and why they fail, what widevine is, how oemcrypto works to check system properties, or even how through all of this a scm call is made in secure context to the trustzone.

    Also these petty differences on semantics just make us look like more of a idiotic crowd. I know I can't request for a thread to be closed, but if I had one "close this thread because it's embarrassing" card, this thread would hands down be what I'd use it for.

    Agreed. Wish Granted.
    21
    So what does that mean though? You're still open the possibility of allowing Android Pay to work on a rooted device?

    I don't want to falsely get your hopes up, so to be completely honest: I don't know of any way to currently or in the near future make an assertion that a particular app's datastore is secure on a non-CTS compatible device. As such, for now, the answer is "no". I could speculate about the future but I'm just one engineer.

    I understand that rooting my device makes me more vulnerable, though I feel the the benefits outweigh the risks. I also know that when I choose to root my device I'm taking the responsibility upon myself to ensure that my phone remains secure. If there were some sort of breech, I would have no one to blame but myself. Could a disclaimer of some sort be added into the user agreement? Something that makes it clear that users with rooted devices are taking all the liability upon themselves?

    I think what you are asking for is a "power user" bit that we would pass along when you set up Android Pay with a card. Something like, "I'm an Android Pay user who understands the risks but I want to root anyway." I think that this would be too hard to build a risk model for: every financial institution in the world would need to build a risk model that incorporates this signal and weigh it against all of the other signals that go in to approving or declining a transaction.

    Frankly, I just don't understand the reason for changing the model. I have been an avid user of Google Wallet for several years. I love the tech. Why make the change to tokenization? I understand that it's more of a standard and more secure. But the virtual cards seemed to work just fine. I've never had an issue with them. Better yet, why not let the user choose whether or not they use the tokens.

    I can't speak for Google but I think that the virtual card didn't work particularly well for my use-case: I didn't get the full name of the merchant on my credit card statements and I didn't get all of the reward points that I was supposed to be getting. I also found chargebacks to challenging. With tokenization--which I've been using for months--my relationship with my credit card company is much better.

    Simply put, rooting is more important to me. So if that means forfeiting the ability to use Android Pay, so be it. I just don't see why it has to be that way.

    Yea, I don't blame you: I completely understand that you are disappointed. I wish that you could get the benefits of rooting without the root.

    ---------- Post added at 09:45 PM ---------- Previous post was at 09:41 PM ----------

    Wow, never expected this :)

    I greatly appreciate the response, like the commenter above, if I had to make a choice between having a rooted phone that I can make my own and being able to use Android Pay, the rooted phone would win out. However, I'm hopeful that the security concerns of moving money using phones and customers' ability to use their phones as they see fit can co-exist.

    I'm glad to see that Google's taking active steps to see what the power user/dev community is doing and thinks about advances in Android and its various related applications. Thanks for reaching out to us, it's a cool thing, and make sure to say hi to Eric/Sergei/Larry/et. al. for me ;)

    Glad to reach out and completely understand why you find root valuable.

    Actually, I'm just a lowly engineer so I think you're about as likely as I am to ever casually say hello to the founders. ;)
    18
    Hey Josh,

    Android users who root their devices are among our most ardent fans and when this group speaks, we listen. A few of us around Google have been listening to threads like this one and we know that you're disappointed in us. I'm a security engineer who works on Android Pay and so this thread struck me particularly hard. I wanted to reach out to you all and tell you that we hear you.

    Google is absolutely committed to keeping Android open and that means encouraging developer builds. While the platform can and should continue to thrive as a developer-friendly environment, there are a handful of applications (that are not part of the platform) where we have to ensure that the security model of Android is intact.

    That "ensuring" is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and--by proxy--real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model. We concluded that the only way to do this for Android Pay was to ensure that the Android device passes the compatibility test suite--which includes checks for the security model.

    The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant. The merchant then clears these transactions like traditional card purchases. I know that many of you are experts and power users but it is important to note that we don’t really have a good way to articulate the security nuances of a particular developer device to the entire payments ecosystem or to determine whether you personally might have taken particular countermeasures against attacks--indeed many would not have.

    Let's keep the dialogue open: I'll be monitoring this and other threads for constructive ideas. I won't be able to reply to all messages but we will keep listening. We love our community and we want you to keep challenging us.

    So what does that mean though? You're still open the possibility of allowing Android Pay to work on a rooted device?

    I understand that rooting my device makes me more vulnerable, though I feel the the benefits outweigh the risks. I also know that when I choose to root my device I'm taking the responsibility upon myself to ensure that my phone remains secure. If there were some sort of breech, I would have no one to blame but myself. Could a disclaimer of some sort be added into the user agreement? Something that makes it clear that users with rooted devices are taking all the liability upon themselves?

    Frankly, I just don't understand the reason for changing the model. I have been an avid user of Google Wallet for several years. I love the tech. Why make the change to tokenization? I understand that it's more of a standard and more secure. But the virtual cards seemed to work just fine. I've never had an issue with them. Better yet, why not let the user choose whether or not they use the tokens.

    Simply put, rooting is more important to me. So if that means forfeiting the ability to use Android Pay, so be it. I just don't see why it has to be that way.