When a customer adds their card to Apple Pay or Google Pay, Apple and Google will automatically generate a new card number called a DPAN (Device PAN) with a new expiry date. The DPAN is completely different from the real card number:

• If customers add the same card to multiple devices, a different DPAN is generated each time
• If the card is removed from their device, the DPAN is invalidated automatically
• If the same card is added again, a new DPAN is generated

Issuers often use a paired "DPAN BIN" for each PAN BIN (normally eight digits long and with the same funding type), but this is not guaranteed to be consistent.

This is all done behind the scenes and is not surfaced to cardholders explicitly. Whenever customers pay for something with Apple Pay or Google Pay, this DPAN is sent to the merchant/processor and they never see the real card number or the real expiry date.

However, one issue with this flow is that the information that a merchant can surface about the card associated with a purchase differs from the customer's real card number, as merchants would reference the DPAN's last four digits instead.

Apple and Google solve this by sending the last four digits of the real card number to the processor, in addition to the DPAN. This means that, on our end, we will charge the DPAN but we will surface the last four digits of the real card number in the last4 property in the API. This makes it easier for merchants to report details about the card used. Separately, we will also put the last four digits of the DPAN in the dynamic_last4 property so that merchants can confirm details about the DPAN that we charged. Note that for Apple Cards added to Apple Pay, Apple does not surface the last four digits of the real card number. In this scenario, the last4 and dynamic_last4 both refer to the last four digits of the DPAN. This is a unique case as the intention is for Apple Cards to be utilised with Apple Pay.

As we don't have the real card number, the fingerprint value will be calculated based on the DPAN instead of the real card number. This means that if the same card is added to two separate devices, the same card points to two different DPANs and would lead to two different fingerprints in the API or the Dashboard.

In Test mode, a card's last4 property will still match the last four digits of the original card. However, for Apple Pay, we ignore the DPAN and use the 4242424242424242 test card number automatically. As the 4242 test card number is a Visa card, this means that the card brand and funding type reflected in the Dashboard and API will be Visa and credit, even if the actual card that was used is from a different brand or has a different funding type. For Google Pay, Google replaces the DPAN with one of the test card numbers from their test suite, and it will have the same issue of not matching the actual card used.