!!! Overview
[{$pagename}] is a [Mobile-Digital Wallet] and [Contactless Payment] system.

[{$pagename}] works using a device-based [Secure Element]. [1]

[{$pagename}] does not store the real card or token data in their cloud servers. The on-device [Secure Element] essentially performs [Card-Emulation] in addition to secure storage. 

[{$pagename}] sends payment data to the contactless terminal when you Tap & Pay utilizing [NFC] and the [EMVCoS Contactless Suite of Specifications] to communicate with the [Contactless POS]. 

[{$pagename}] does not store the real card data inside the [Secure Element]. [{$pagename}] stores a token that conforms to [EMVCo Tokenization] specification. This token (along with a cryptogram) that gets sent to [Contactless POS]. [Apple] refers to the "Device Account Number" (DAN) as the [EMVCo token|EMVCo Tokenization] in their documentation.[2]

During the authorization flow, the card network identifies the [Payment Token] and converts them into [Primary Account Number] with the help of a [Token Service Provider] ([TSP]) and sends the real [PAN] over to [Card Issuer] for [authorization].

Since [Apple] owns and controls the [Secure Element] embedded inside the device thereby avoiding unnecessary challenges from the [Mobile Network Operators]. The [Secure Element] ([Secure Enclave]) is typically protected by [Touch ID] or [FACE] ID.

!! [Secure Enclave] and [Touch ID] 
Each [{$pagename}] transaction is authenticated using [Touch ID] or the user’s passcode. The [Secure Enclave] manages the [Authentication] process and enables a [Payment Transaction] to proceed.

Could there be some [Cryptography] Functions involved?

!! How it Works

! Adding a Card to [{$pagename}]
When a customer adds a [Payment Card] to their wallet, the [Primary Account Number] details are submitted to Apple Pay servers. 

[{$pagename}] sends the information over to the corresponding [Issuer Bank|Card Issuer] asking for a [Payment Token] in return. 

The [Issuer Bank|Card Issuer] calls a [Token Service Provider] ([TSP]) and requests for a [Payment Token]. As far as we know, the [Payment Network] themselves play the role of TSP at present.

The TSP vaults the [PAN], maps it to a [Payment Token] and returns the token and a [Payment Token-Key]. 

The [Issuer Bank|Card Issuer] receives a token and [Payment Token-Key], and adds a [CVV-Key] to the mix. 

The [Issuer Bank|Card Issuer] returns the [Payment Token], [Payment Token-Key] and [CVV-Key] back to [{$pagename}]. 

[{$pagename}], acting as its own [Trusted Service Manager] ([TSM]) provisions the [Payment Token], [Payment Token-Key] and [CVV-Key] and maybe other data into the [Secure Element]. This combination is the "[Token|EMVCo Tokenization]" that [Apple] calls as "Device Account Number" [DAN] in its press releases.

!! Making a POS Payment
When a customer taps or waves their iPhone in front of a [point of sale terminal|Contactless POS], a payment transaction is initiated. 

Apple Pay uses [EMVCo’s Contactless Suite of Specifications] to communicate with the contactless reader terminal. 

When it is time for the [Secure Element] to send information to the terminal: 
* First,  the [Secure Element] generates a [Dynamic Cryptogram] using a combination of the [Payment Token], [Payment Token-Key], transaction amount, transaction counter etc. 
* Second,  the [Secure Element]  generates a [Dynamic CVV Value] using the [CVV-Key]. 
* Second, the [Secure Element] passes the [Payment Token] the [Dynamic Cryptogram], the [Dynamic CVV Value] and other payment and chip data elements to the terminal using the [EMVCo’s Contactless Suite of Specifications].

To put this in Apples terms, The Device Account Number or DAN represents the [Payment Token], the One-time Unique Number represents the [Dynamic Cryptogram] and the Dynamic Security Code represents the [Dynamic CVV Value].

The [Payment Network|Card Processor] identifies that it is a [Payment Token] and not a real [PAN] based on BIN tables. Consequently, they send a request out to the [TSP] to de-tokenize passing in the [Payment Token] and the [Dynamic Cryptogram]. 

The [TSP], among other things, validates the [Dynamic Cryptogram] using the [Payment Token-Key] that it shared earlier during the provisioning process. If the [Dynamic Cryptogram] is valid, the [TSP] de-tokenizes and returns the real [PAN] back to the [Payment Network|Card Processor]. 

The [Payment Network|Card Processor] attaches the real [PAN] to the authorization request and sends it over to the [Issuer Bank|Card Issuer] for authorization.

The [Issuer Bank|Card Issuer] validates the [Dynamic CVV Value] based on the [CVV-Key] it shared earlier during the provisioning process. Then it authorizes the transaction depending on the customer’s account status. The authorization status flows back from the [Issuer Bank|Card Issuer] to the [Payment Network|Card Processor], back to the [Payment Card Acquirer|Acquirer] and back to the [Merchant] where your receipt gets printed.

!! About the [{$pagename}] [Payment Token]
The [Merchant] is sent the [Payment Token], which is a Virtual Credit Card Number, from the [Card-Emulation] process. With [{$pagename}] this will appear as a Credit Card Number issued from the bank that issued the Credit Card that is stored in [{$pagename}] that was selected to make the payment. 

You may see the last four digits of this [Payment Token] on the receipt of your purchase. If the cashier asks for the last four digits used in the transaction, (Generally, they should not), you should give the last four of your [Payment Token]. (TBD Where to find this value.)

As far as we know this [Payment Token] will be the same every time you select the same Credit Card for payment within [{$pagename}]. 

!! Patent Filing 
The U.S. Patent and Trademark Office published Apple's application for a "[Method to send payment data through various air interfaces without compromising user data|http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=1&p=1&f=G&l=50&d=PG01&S1=(705%2F75.CCLS.+AND+20140116.PD.)&OS=ccl/705/75+and+pd/1/16/2014&RS=(CCL/705/75+AND+PD/20140116)|target='_blank']," which details a readily deployable digital system based on existing mobile hardware technology. Prior to today's filing, most of Apple's payment-minded patents have focused on use case scenarios, not backend infrastructure. Uses the term [Secure Element].[3] 

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Apple Pay vs Google Wallet : The Secure Element|http://www.gmarwaha.com/blog/2014/10/02/apple-pay-vs-google-wallet-the-secure-element/|target='_blank'] - based on 2015-02-09
* [#2] - [How Apple Pay Really Works and Why You Should Begin Using it Immediately|http://www.kirklennon.com/a/applepay.html|target='_blank'] - based on 2015-02-09
* [#3] - [About Touch ID security on iPhone and iPad|http://support.apple.com/en-us/HT5949|target='_blank'] - based on information obtained 2015-02-21