I'm sorry but that's just not true.
The two systems are vastly different in implementation. Google are acting as a financial intermediary for every transaction through use of a "virtual credit card" which is what is on your phone and what the vendors see (they never see your actual cards as they are only on Google'a servers). As a result, Google have access and knowledge of every detail of every transaction you make using their system. This aligns with their panopticon business model. By effectively acting as a middleman financial institution they don't need any agreement with banks etc. Every transaction you make actually becomes two 1. Google pays vendor, 2. Google charges your bank.
Your information is out of date.
What you say was the mechanism that Google Wallet used, in its second version. The evolution of Google's NFC payment system went as follows:
1. The initial release used a secure element (essentially a smart card chip) and installed your actual credit card information in the SE, using the standardized EMV solution straight up. (EMV is EuroPay/Mastercard/Visa, a consortium that creates payment standards). Initially only Chase cards were supported because this approach requires support from the issuer.
In this version Google was not a middleman.
2. Due to banks being very slow to get on board with SE-based NFC payments, and due to lots of opposition from carriers (who wanted to become the new payments infrastructure, see ISIS/SoftPay), Google abandoned the SE-based solution and invented something called Host Card Emulation (HCE). In this model, your actual credit card information was kept off the phone entirely, stored only in Google's servers. A proxy card was used to make payments at the point of sale, using pre-computed single-use cryptographic tokens computed on the server and stored on the phone. The proxy card allowed Google Wallet to support any and all credit and debit cards -- in theory any payment mechanism that Google's back-end payment infrastructure could support.
In this version Google acted as a middleman, as you say.
3. AndroidPay deployed after ApplePay and uses a payment architecture very similar to ApplePay, called "network tokenization". The idea is that the interchange networks can produce cryptographic credentials which can be validated by the network, which then passes the validated transaction back to the card issuer. This means that the issuing banks have dramatically less work to do to support NFC payments than in the original EMV-specified model (the one used by Google Wallet). Network tokenization was under development when Google Pay deployed initially, but far from ready to go. Apple waited until it was before launching, and as soon as it was available Google shifted to it as well. They still work somewhat differently, in that Apple uses long-lived multi-use tokens stored in the secure enclave, while Google uses short-lived, single-use tokens stored in Android, and encrypted with a key kept only in RAM and re-downloaded after each reboot.
In this version Google is no longer a middleman.
I expect that a future iteration of AndroidPay will shift to using tokens stored in the Trusted Execution Environment (TEE), discarding the RAM-only key, but that will have to wait until all of the devices using AndroidPay have the TEE with the necessary software.