0.05% worldwide. It's higher in the US because we're still using the magstripe.
Apple Pay is rolling out worldwide, which is why I used the world figures. However, the Apple cut is still more than US fraud rates.
Not to mention that the US is moving to chip, which should drop card present fraud rates even more.
Also, a lot of the costs that you mention are mostly one-time costs regardless of the mobile payment systems the issuer chooses to support, so it won't cost nearly as much to support, say, Samsung Pay or Android Pay later.
Doesn't matter. The claim was that Apple Pay was more convenient and did not add extra cost for the banks. That's not true.
Btw, those are not one-time costs, as anyone in IT knows. Servers costs plenty of money to maintain.
As a side note, for issuers who rely on networks to handle tokenization, those related costs add up too. For example,
Mastercard gets:
- 50 cents to create a token
- + 10 cents per token per month to keep it "alive"
- + 2.5 cents per token/detokenization
... I wish there was someone knowledgeable that could give insight into what Discover could have added to their backend system to prevent the update requirement, or what Apple had to add to their client software to make payment communication possible. It's all speculation otherwise.
If I had to guess, I'd say that Apple had to add either the Discover payment Java applet to the iPhone's and Watch's Secure Elements... or support for it, or both... via an OS update.
Remember, Apple doesn't do any payment processing itself for NFC. That's all done by each credit network's proprietary applet in the secure element, which are the only pieces of software allowed to talk to the merchant terminal.
(The secure element has a processor, that when activated by the NFC radio, looks at the transaction and picks the correct stored payment applet ... e.g. MC / Visa / AMEX / Discover... to hook to the radio.)