Tap. Pay. Done. If you're the owner of an NFC enabled Android phone running 4.4+, then you've probably heard of Android Pay. The app supports adding cards from many different banks and works in many major retailers, and it's pretty easy to set-up as well. Google is practically begging you to sign-up!

That is, unless, you're a power user who has a rooted device. For us, we had to choose between having root access and all the benefits it entails (ad-blocking, theming, Xposed, etc.) and using Android Pay. Google has stated that restricting Android Pay access for rooted users was a precautionary step to prevent any chance of financial security breaches.

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. - jasondclinton_google, a security engineer at Google speaking on our forums

Fortunately, XDA always finds a way (although this time, unintentionally). By rooting your device without making modifications to the /system partition (ie. systemless root by XDA Senior Recognized Developer and Developer Admin Chainfire), users were able to bypass the root restriction and access Android Pay. In a Google+ post, however, Chainfire mentioned that this "fix" is merely "by accident, and not by design, and Android Pay will be updated to block it." Well it looks like Google has finally stepped in and updated their SafetyNet API, 91 days after the release of the systemless rooting method.

Hello Darkness, My Old Friend

There are several reports going around on Reddit and on our own forums that the newest SafetyNet check detects systemless root, meaning you can no longer use Android Pay with a rooted device. If you're an Android Pay user with a device rooted using the systemless root method, then you might notice that the app still opens for you, and you'll be in denial (I know, it's hard to admit...) but unfortunately it's true. Android Pay only checks your device for passing the compatibility device suite when the app is first installed and opened, when a new card is added, and at the time of a transaction. Users on our forums are noting that the app may give you a green check-mark, lulling you into false hope that it worked but alas, no, the transaction will not process any more.

Not all is lost, however. Fortunately, you can disable su from the SuperSu app before making a purchase to temporarily allow your device to pass the CTS check. Then after you've made your purchase, you can open the SuperSu app, ignore the 'update binary' pop-up, and re-enable su. A minor inconvenience, sure, but at least you'll still be able to enjoy your Xposed modules ad-blocker while making purchases on your phone.

Correction: Xposed modules will still trip the CTS check, so you will also have to disable Xposed before using Android Pay.