That's the old documentation style. They redesigned their documentation last year. It hasn't made it to all documentation yet, but new stuff uses the new design. Still has some strange UI bugs, but it's at least responsive now.

https://developer.apple.com/library/ios/documentation/Swift/...

I assume it's the same effect I see with Opera (blink) on Android. Fixed positioning and small screens don't play well together, especially when zooming. They should have designed it with also a mobile layout but probably they didn't think it was worth the trouble for that kind of site. I expect that most of its audience comes from Macs, so at least 11" screens.

I run a subsidiary of First Data (called Clover). I wrote and published the code for a few reasons:

- so I could answer questions more accurately and thoroughly during press interviews and with current and prospective partners. Nothing beats running code for this.

- My team doesn't trust me to write production code much any more but I need my kicks. ;)

- I'd like for people to understand Apple Pay crypto well -- it's the best I've seen in the payments industry. I'd like to even see something like this standardized for protecting cardholder data (both for card-present/POS transactions and e-commerce), where 3DES/DUKPT is still standard practice.

- There's been some misunderstandings that Apple Pay In-App is a closed system and you need to partner with them to use it. This is an existence proof that this is not the case.

- For people who are their own processor/gateway (e.g. very large companies), this gives them a bit of a head start on understanding what they need to do.

First Data has a commercialized version of Apple Pay in their new e-commerce gateway: http://www.payeezy.com/ (not to mention many gateways which process through First Data and support Apple Pay).

This is basically showing what code you may need to implement on your server if you are not working directly with a processor/gatewa. After you decrypt the data you have technically all the appropriate information you can use to stay processing the credit card for the amount specified. Basically code similar to that is executed by Stripe server when they receive the transaction, and Stripe handle the processing to submit it to the appropriate merchant bank. Basically any large company that process credit card transaction and submit it to be processed by the bank will need to get the decrypted data. As the example documentation explains be sure to keep all your keys secret.