(Long post warning);
(In this posting, I use "NFC" as shorthand for the established (pre-Apple Pay) system used by extant credit-cards and banks for short-range (under 10cm) wireless payments, I believe this is ISO/IEC 14443).
NFC-for-payments
(I think that) I understand how NFC-for-payments works: In the case of NFC-ready cards (that have the Wi-Fi-like logo on them), a closed and secure chip contains a copy of your credit card information, an NFC payment terminal interrogates your card (using a principle similar to RFID), and the terminal gets your details and then issues the charge to the merchant's payment-processor and that's it.
So far, so straightforward: NFC is just yet another way of getting your account details out of your physical credit card, just like the magnetic-stripe or the EMV chip. Once the terminal has your card details (card number, expiry, etc) it makes no difference to the merchant how they got those details - they could have been submitted manually by physically keying-in the embossed numbers on the card.
However, I understand that "standard" NFC-for-payments, by default, is an analog of the magstripe, in that it just reads a straight copy of the card details: the NFC chip does not generate any one-time-use card number or even subvert the credit-card system with its own account/digital-wallet system. I also understand that NFC, by default, does not employ any over-the-air encryption or even a challenge-response system, meaning it's hypothetically possible to run a handheld reader by people's purses and coat-pockets to skim low-value amounts[1] from "dumb" NFC cards, or an attacker could hide an NFC sniffer beside an NFC terminal to capture NFC data mid-flight[2]. That's concerning. I wonder how the NFC system was authorized by Visa, Mastercard, AMEX et alii given how insecure it is.
Recently, but long before Apple Pay was announced, Android phones had NFC functionality that allowed users to clone their credit cards' details onto the NFC chip, and then use the NFC-enabled phone as a substitute card at NFC payment terminals. Assuming that the same security issues that affect NFC still apply, then I suppose it's no-wonder that Apple didn't include an NFC feature in the iPhone, at least initially.
Apple Pay
Apple Pay uses the same NFC protocol - which is why you can use Apple Pay with any NFC terminal. Apple wanted to make it more secure, but they couldn't encrypt the OTA signal because that would break compatibility with existing NFC terminals - so they added security by not sending the raw, original credit card details but instead Apple Pay in the iPhone itself generates and sends a one-time, single-use credit-card number, which is then transmitted via NFC. This is so that if the radio transmission were to be intercepted then the attacker would have no use for the details (because if the single-use card number was already charged they couldn't charge it again - and if they got their charge through first then the bona-fide merchant would see their charge declined and they could dispute it immediately).
Because Apple Pay then becomes its own system-atop-another-system (because Apple controls the single-use credit card numbers) this means they need to require customers' banks to agree to join their system on an individual basis (so the bank's systems can accommodate Apple's single-use credit-card numbers) - this explains the slow roll-out of Apple Pay, and it also explains why they can justify asking for a 0.15% cut of every transaction: because they are adding-value with the added security from their single-use system.
But how does Apple Pay work at the back-end, between the NFC terminal and the customer's own credit-card account? The merchant receives the single-use credit-card number and would presumably still process it the same way they handle a normal credit-card number: they pass it to their payment processor who then charges the network (Visa, MasterCard, or AMEX), who in-turn charges the customer's bank/credit-card provider... but how can any of those involved know what the customers' original credit account details are? Apple is the one generating these single-use codes. I understand that credit-card numbers include the identifier of the originating bank (which is why all of my cards from the same bank share their initial 8 digits) - so the Apple Pay system either generates a single-use code within the customer's bank number-space (i.e. with their bank's prefix) - or it must generate a single-use number with Apple's own prefix, in which case Apple would then receive the charge and then pass it on to the originating bank themselves.
Two possibilities for the back-end:
If Apple uses the customer's bank's prefix, then the bank gets the charge sent directly to themselves and Apple is not a payment intermediary - all Apple Pay does is generate a single-use number. Apple would have no way of knowing how much money was actually charged and so they could get cheated-out of the 0.15% cut they're asking for. This system would require some way of translating the single-use codes to actual account details - I guess Apple provides that to the banks via a back-end side-channel.
However, if Apple uses their own bank prefix, then it means that every transaction passes through Apple's system: they would have access to the details for every transaction and form a shopping-habits profile for all of their users. They would also be able to know exactly what amounts are being spent and claim their 0.15% cut and keep the single-use-card-details mapping a secret - they would then proxy (forward) the charge on to the customer's bank.
...neither of the above strike me as being particularly ideal solutions.
Everything is terrible
So I come to the conclusion that Apple Pay is a "patch" for NFC, NFC itself being an insecure add-on for an already outmoded system (that being the concept of reusable card details).
So I ask, when NFC was originally introduced, why didn't they introduce and mandate single-use payment details (managed by banks or the payment network directly, instead of a third-party)? And it would not have been a stretch to also use a challenge-response or (a reasonably future-proof) OTA encryption system - this would have completely obviated the need for Apple Pay.
Now, if it turns out that NFC already actually has OTA encryption and banks already support single-use details[3] (isn't that what EMV does anyway?) then what value does Apple Pay add?
Is this the result of the incumbent card networks (Visa, MasterCard, AMEX, etc) being so resistant to change that they'd rather add new features that inherit the underlying system's insecurity and/or technical incompetence which allowed an insecure system like NFC to be deployed into production, and without at-least pushing for OTA encryption as a patch after release? It's a mystery that given the sheer amount of money that card-networks claim (and where does it all go?) that we don't see them working on their own innovative or disruptive platforms... it's a no-brainer.
Footnotes
[1] I understand in many places, NFC charge amounts below a certain threshold, say $20 or £10, do not require a PIN for charge authorization authentication - ostensibly to speed-up the customer experience when making small purchases, such as a cup of coffee or a train-fare.
[2] And given the production-quality and attention-to-detail of present-day ATM card skimmers it's entirely possible that organized-criminals could devise even harder-to-find NFC skimmers given only the requirement for a passive receiving antenna and microcontroller + memory board.
[3] I remember reading about some banks a few years ago that generated single-use credit numbers for customers to use for online shopping, though this is a per-bank feature that is not inherently supported by the credit-card networks themselves.
