Image generated by OpenAI's DALL·E
Apple Pay was introduced by Apple in October 2014 and enabled users to make contactless payments with their iPhones for the first time. Google Pay, originally known as Android Pay, launched in 2015 and was renamed Google Pay in 2018. However, both services have only been available in Germany since 2018. NFC technology forms the basis for secure and fast transactions for both payment services.
In the US, Apple Pay dominates the mobile payments market with a 92% share in 2020, while Google Pay accounted for just 3%. In Germany, on the other hand, the use of Apple Pay and Google Pay is less widespread, as traditional payment methods such as cash and debit cards are still preferred. Nevertheless, the acceptance of both services is continuously increasing, especially in urban areas and among younger consumers. According to a 2023 study, 23% of Germans now regularly use mobile payment services.
Acceptance is growing continuously – but how secure are Apple Pay and Google Pay?
Apple Pay vs. Google Pay are modern digital payment systems that enable contactless payments via smartphone, smartwatch or tablet. Both services are based on NFC technology, which allows wireless communication between the device and the payment terminal. They use tokenization to protect users' sensitive card data. Instead of the actual credit or debit card number, a unique, encrypted token is transmitted that is only valid for this transaction.
Apple Pay stores these tokens in the Secure Enclave, a hardware-based security module on Apple devices that is physically isolated from other parts of the system. Google Pay manages and stores the tokens in its own cloud, enabling seamless synchronization between different devices. This approach offers a high level of flexibility in use, as no special hardware is required and compatibility with a wide range of Android devices is ensured.
Compared to physical cards, both services offer additional protection mechanisms. Transactions are approved using biometric data such as Face ID or fingerprint (Apple Pay) or fingerprint or facial recognition (Google Pay). In addition, if the smartphone is lost, there is no need to block the card directly, as the digital tokens work independently of the card data and can be easily reset.
Summary and key findings in advance
The individual aspects are examined in detail below. For those in a hurry, here is a brief summary and the key findings that would normally be at the end.
Apple Pay and Google Pay take different approaches to payment processing, both based on modern security standards, but with specific strengths and weaknesses. Apple Pay relies on local processing of all sensitive payment data, which is stored in the device's secure element. This isolated hardware effectively protects tokens and cryptographic keys from manipulation and attacks. Since payment authorization takes place completely offline and no transaction data runs through Apple servers, this minimizes potential attack vectors. This means that Apple neither has access to the payment information nor stores personal data.
Google Pay, on the other hand, combines cloud-based processing with the secure environment of the Android operating system, such as the Trusted Execution Environment (TEE) and the Android Keystore. These enable the secure storage of tokens and cryptographic keys on the device. However, Google Pay requires an active internet connection for most transactions, as payment authorization is handled through Google's servers. This allows for greater device flexibility and synchronization, but poses a higher risk as sensitive information is stored and managed centrally. Google Pay uses tokenization and dynamic cryptograms, but is based on a cloud-based architecture that uses modern encryption standards and includes centralized data management, which can introduce potential attack vectors.
Security priorities are crucial when choosing the right payment service. Apple Pay offers a high level of protection and privacy through local processing and complete isolation of payment data. Google Pay scores with flexibility and broad device support, but has to deal with a greater dependence on the cloud and centralized data management. Both systems rely on robust security mechanisms, but for me personally it prompted a switch back to an iPhone.
Apple Pay: Architecture at a Glance
Apple Pay uses a security model that combines the principles of tokenization and local processing. When a card is added to the Wallet app, the card details are sent directly to the bank or card provider via an encrypted connection. The device-specific token created in this process, the so-called Device Account Number (DAN), is generated exclusively by the bank or card provider and is permanently linked to the respective device. The DAN is then stored in the Secure Element, an isolated and certified chip (Secure Element). This area processes all sensitive payment data independently of the operating system and effectively protects it against unauthorized access or manipulation.
During the payment process, the smartphone communicates with the payment terminal via NFC after the user has authorized the transaction using biometric methods such as Face ID or Touch ID. The Device Account Number (DAN) stored in the secure element is used, supplemented by a dynamic cryptogram code that is generated specifically for this transaction. This code contains device-specific and transaction-specific data such as a timestamp and a unique one-time identifier. This mechanism ensures that the payment data cannot be reused or manipulated.
Payment authorization with Apple Pay takes place entirely locally on the device, meaning that no internet connection is required for the actual payment process. This ensures that payments can be made securely and reliably regardless of network coverage. An internet connection is only necessary when setting up a new card in the Wallet app. In this step, the card is verified by the bank or card provider, and a device-specific token is created and securely stored in the device's secure element. After one-time activation by the bank, Apple Pay works completely autonomously, without further communication with Apple's servers.
Google Pay: Architecture at a Glance
Google Pay relies on a security model that combines the principles of tokenization and server-side processing. When a card is added to the Google Pay app, the card details are sent to Google's servers via an encrypted connection. There, a device-specific token, the so-called Device Primary Account Number (DPAN), is generated. This token is linked to the device and authorized by the bank or card provider. Unlike Apple Pay, the DPAN is not stored in a dedicated hardware module such as the Secure Element, but in the secure environment of the Android operating system.
The DPAN is stored in the secure environment of the Android operating system, which is based on technologies such as the Trusted Execution Environment (TEE) or the Android Keystore architecture. The TEE is an isolated area of the main processor that is not directly accessible by apps or the operating system and protects sensitive data such as cryptographic keys or DPANs. The Android Keystore API also provides an interface for secure storage and encryption operations. Depending on the device configuration or manufacturer, this data is stored either in hardware-based keystores or in a software-based secure environment to ensure the integrity of the sensitive information.
During the payment process, the smartphone communicates with the payment terminal via NFC after the user has authorized the transaction using biometric methods such as fingerprint or facial recognition. The DPAN stored in the device is used together with a dynamic cryptogram code that is generated specifically for the respective transaction. This code contains transaction-specific data such as a timestamp and a unique identifier, which ensures the security of the transaction and the data cannot be reused.
Payment authorization with Google Pay requires an active internet connection, as the verification and approval of the transaction takes place on Google's servers. A network connection is therefore required for the actual payment process. This simultaneously enables the synchronization of payment data and card information across multiple devices - a new link to another device and the card is still required.
Apple Pay vs. Google Pay - security vulnerabilities
Both systems have a similar security record, as vulnerabilities have been identified in the past, but these were quickly fixed by Apple and Google. Examples of this include replay attacks on Visa cards in connection with Apple Pay and NFC data exfiltration on locked devices in the case of Google Pay.