Actually it's quite a bit different. Apple Pay is built on top of the 3D Secure and EMV Payment Tokenisation Standards (created by EuroPay, Visa and MasterCard but also implemented by Amex and others).
Apple Pay itself (the code done by Apple) has nothing to do with EMV or tokenization. That's done by the credit card entities with their own secret code installed in the Secure Element.
Heck, the Secure Element code could get changed to send real account numbers... or even pictures of money instead of numbers... during NFC transactions, and Apple Pay would never know. It doesn't have to. All it knows is about the API to talk to the
actual payment applets in the Secure Element.
While how the website detects and interacts with Safari might be Apple specific, everything from there back is standardised and there's nothing stopping other browsers doing essentially the same thing.
Umm, not sure what you mean. Can you explain in more detail?
To me, it sounds like Apple is simply treating Safari as an app with Apple Pay, same as any other such app, except for providing a Javascript API for web apps instead of displaying the UI itself.
If I'm right, each website still talks to whatever payment processor its owner has set up. And each one of those has its own API.
--
Which was my point: every time someone comes up with a new payment method, a website has to add code for it to work.
A more generic way would be for browsers to recognize common payment tag fields and offer to fill in a one-time token account info (similar to the way that most browsers do it now with a saved hardcoded account number) using the payment source of your choice.
Alas, every payment provider wants branding and lock-in, so unless someone writes some browser plug-ins to do this, it's not likely
