Different mobile wallets work in different ways. This article from 2014 has a good overview, from which I've taken the quotes below. As far as I know, nothing major has changed since then.
[Google Wallet] issu[es] the customer a Google Wallet Virtual Card. This Virtual Card is issued by Bancorp Bank through Google, and it essentially acts as an intermediary between the customer's preferred card and the merchant.
Instead of having your Chase-issued Visa card information sent from the merchant's terminal to the merchant acquirer, the Google Wallet Virtual Card requests the funds from your preferred card, and the Virtual Card information is then sent to the merchant, who subsequently sends it on to the payments processor. From there, that information is processed as a traditional card's information would be.
In other words, when you load a card into Google Wallet, you're choosing to use it as a funding source for yet another (virtual) card, which is what actually gets sent to the merchant. There's no direct link to your card, so your data is safe.
When you first set up Apple Pay, [you send the card data to Apple]. Apple next “sends the encrypted data, along with other information about your iTunes account activity and device (such as the name of your device, its current location, or if you have a long history of transactions within iTunes) to your bank. Using this information, your bank will determine whether to approve adding your card to Apple Pay.” In a sense, this setup process is like the initial authorization in a traditional credit card payment. In a simple credit card transaction, card details are sent to the bank for authorization, and an approval comes back to the merchant that lets the transaction go through.
The Apple Pay setup, however, appears to be the first and only time your real credit card information is passed around between Apple and an issuer. Once the information gets to the card network, it's decrypted, and the card network issues a token called a Device Account Number (DAN). The DAN is device-specific. The card network sends this DAN to Apple along with other information “such as the key used to generate dynamic security codes unique to each transaction,” according to Apple's support page.
In other words, Apple works directly with your bank to generate a special token that is unique to your device, and then you use that as payment through any merchant because the issuing bank will honor it as valid.
Apple works with banks to generate a token that works like a card (rather than the merchant-specific ones mentioned in the question), and directly charges your account. But if the bank doesn't support it, you're hosed.
Google Wallet issues you a new virtual card from their partner bank, and then that bank charges your real card before authorizing any transaction.