If it works, it's by happenstance not officially. According to the link above (official FAQ):

> If the operating system is an Android variant (also called a 'custom ROM'), such as LineageOS or Pixel Experience, then the wero app can’t be installed for security reasons.

The thing is, with most banks you aren't even allowed to use the Wero app that has this play integrity restriction. The banks integrate Wero directly into their own apps. So its mostly up to your bank.

It does not say anything about remote attestation, only rooted/unlocked phones. Most likely it works fine if you run GrapheneOS with a locked bootloader.

Many European banking apps work on degoogled Android like GrapheneOS or /e/OS fine, as long as you have locked the bootloader and USB debugging disabled.

I think most/many banks had their own nfc tap-to-pay solution before Google/Apple Pay came along. Any idea why the banks chose to give that up?

It can be both, the plumbing is straight forward, simply a matter of will to implement. UPI in India, Pix in Brazil, FedNow in the US, etc. Trimmings are things like paying via QR code and alias support (phone, email IDs). Pix had native alias support, Wero is alias support on top of SEPA Instant payment rails (with a ~ten second settlement SLA).

This gets you to utility cost recovery fee structures and sovereignty over your payment infra, versus other countries controlling your value transfer capabilities.

https://en.wikipedia.org/wiki/Instant_payment

https://en.wikipedia.org/wiki/Wero_(payment)

https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

https://www.ecb.europa.eu/paym/retail/instant_payments/html/...

I agree, I’m not saying it’s totally correct or there aren’t answers, but those are the current rules at least in my bank.

Instant payments bypass typical surveillance and fraud systems and so need some kind of authentication, if you don’t want to 2fa every time you’re at the checkout then the application has to have been previously authenticated (e.g setup with some kinda TAN from your bank) and execute on an attested device. We can def extend attestation to other devices (e.g is the kernel modified, does the app have reasonable version and checksums etc) but again, who is gonna fund that for 10 users?

edit: We have a long road to go before this stuff gets better, I think we should be happy at each step instead of really wishing we were already at the finish.

There's technical possibility and then real world practicality.

For the same reason, a pure WebAuthn flow in a compliant browser could technically implement secure payment confirmation mandated by the DSP, but afaik no bank does that, and the W3C is still working on the spec.

Our governments can't even manage not to depend on Microsoft/Google/AWS (and Palantir, the US military industrial complex, Israel, ...), our banks are regularly under the fire of extraterritorial bullshit due to the USD dependence.

Being worried about consumer devices and their OS is cute, but it's missing the forest for the trees.

Which bank? I work in this space for a large european bank and we wouldn’t be able to do this.

That’s authenticated and 2fa’d, so it doesn’t have the same use case as a tap to pay system, though. I’m not defending these choices, but there is a reality here.

Aren’t your problems solved by carrying a bit of plastic issues by your bank? Why isn’t that enough?