This document on Apple's site explains it:
...
From reading that, it seems like Apple has it fairly locked down as it's tied in over a dedicated hardware bus to the secure enclave. They could always add a second NFC chip to handle other types of NFC transactions (and I wish they would for things like unlocking my doors),
...
but I may be wrong as I'm no expert in this field. I'm just interpreting what I've read with my limited capacity to understand it.
All such chip systems have a dedicated line. You see, Apple did not invent any of the NFC Controller/Secure Element concept. The system and chips were already thought out long before Apple started using NFC. (How else do you think contactless payments worked all this time?)
You are right that the whole point of the Secure Element is that it is the only thing allowed to talk over NFC to the payment terminal. This prevents user programs from intercepting and spoofing comms. Also, allowing other NFC applets would not compromise Apple Pay.
--
NFC applets are registered by id:
When you hold a card up to a store terminal, the terminal sends what NFC Application IDs (AIDs) it can support. E.g. MC, Visa, Oyster, etc. The NFC Controller in your device picks out which Secure Element applet is registered for that AID, and shunts further comms to that particular applet in the Secure Element.
The Secure Element can send events (such as "payment complete") to the user application associated with that particular Secure applet, to alert the user.
In other words, an Oyster card id from a terminal would cause the Oyster app to pop up. A Mastercard app id causes the Mastercard (or often, a combination Wallet app such as Apple Pay or Android Pay) to start. Ditto for other bank cards, loyalty cards, travel cards, door swipe cards, you name it.
Each NFC applet only sees comms meant for it. And user apps only see rather bland events meant for them.
--
User's choice for applet to UI binding:
The most important part is that normally the device owner gets to pick what user app launches for each NFC app id. Obviously most of the time there's only one user app (say, for Oyster) so it doesn't matter. BUT for credit cards... where the payment applets are always static for a particular type (MC/Visa/etc)... the choice is really about which WALLET app to open to talk to that particular applet.
In other words, there's no reason why an Australian bank could not have its own branded wallet UI register and use the same MC/VISA/AMEX/etc payment applets that the Apple Pay UI talks to. And of course, they could use TouchId or Iris Scan or a passcode just like other iOS apps for user validation.
Apple pay's payment mechanism is through the payment processors (in us see visa and MasterCard) via the already set protocols and non Apple Systems
Correct. Apple itself does nothing during a contactless payment transaction. All that is handled by the Mastercard/Visa/etc applets in the Secure Element.
--
Registration of an account:
Apple takes the cut from the fee that the banks charge the merchants (interchange fees) for providing the secure system of enrolling the cards and the transaction.
Currently, Apple has a lock on registering user accounts with payment applets in the Secure Element. They did this in order to extract money by selling banks such access to their own customers.
This is an artificial restriction gateway designed to make money, nothing else.
Another option is to do something like what Samsung does: they provision a Visa payment applet that any app can use, and Visa ITSELF acts as the gateway for adding new token account numbers.