When a customer adds their card to Apple or Google Pay, Apple and Google will automatically generate a new card number called a DPAN (Device PAN) with a new expiration date. The DPAN is completely different from the real card number:
Issuers often use a paired "DPAN BIN" for each PAN BIN (with the same funding type and commonly 8-digits long), but this is not guaranteed to be consistent.
This is all done behind the scenes and not surfaced to cardholders explicitly. Whenever customers pay for something with Apple or Google Pay, this DPAN is sent to the merchant/processor and they never see the real card number or the real expiration date.
One issue with this flow though is that the information that a merchant can surface about the card associated with a purchase is different from a customer’s real card number, as merchants would reference the DPAN’s last 4 digits instead.
Apple and Google solve this by sending the real card number’s last 4 digits to the processor alongside the DPAN. This means that on our end we will charge the DPAN but we will surface the real card number’s last 4 digits 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 DPAN last 4 digits in the dynamic_last4 property so that merchants can confirm details about the DPAN we charged. Note that for Apple Cards added to Apple Pay, Apple does not surface the real card number's last 4 digits. In this scenario, the last4 and dynamic_last4 both refer to the last 4 digits of the DPAN. This is a unique case as the intention is for Apple Cards to be utilized with Apple Pay.
Since 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 original card’s last 4 digits. However, for Apple Pay we ignore the DPAN and use the 4242424242424242 test card number automatically. Since the 4242 test card number is a Visa card, this means 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.