Digital wallets have transformed the payments ecosystem. Apple Pay and Google Pay have accelerated the shift toward contactless and tokenised transactions, offering enhanced convenience and improved security compared to traditional card payments.

However, from an IT Audit and Risk Advisory perspective, the critical question is not simply whether data is encrypted or tokenised — it is who actually touches the data.

That architectural decision reshapes:

  • GDPR exposure

  • PCI DSS scope

  • Third-party risk

  • Governance complexity

  • Residual compliance risk

Regardless of the model, card data is tokenised. The difference lies in where sensitive data resides and who becomes a data custodian.

Read the Advisory from Australian Government regarding Payment Security
https://www.aph.gov.au/Parliamentary_Business/Committees/Joint/Corporations_and_Financial_Services/Mobileanddigitalwallet/Report

Apple Pay: Architecture Built on Local Isolation

Apple’s design philosophy is centred around data minimisation and hardware-backed security.

Technical Model

  • Card details are never stored on Apple servers.

  • The Primary Account Number (PAN) is converted into a Device Account Number (DAN).

  • The DAN is stored in the device’s Secure Element (a hardware chip).

  • Merchants and e-commerce servers only see the token — never the real PAN.

  • The issuing bank resolves the DAN to the actual card number during authorisation.

This model deliberately removes Apple from long-term custody of cardholder data.

GDPR Impact

Under GDPR principles (particularly Article 5 – Data Minimisation and Purpose Limitation):

  • Strong data minimisation posture.

  • Apple avoids acting as a persistent card data processor.

  • Reduced personal data footprint across the ecosystem.

  • Lower breach blast radius in case of compromise.

From a privacy risk perspective, limiting central storage directly reduces regulatory exposure.

PCI DSS Impact

  • Merchant PCI scope is significantly reduced.

  • Apple’s architecture limits exposure of cardholder data environments (CDE).

  • Fewer systems fall within PCI assessment boundaries.

  • Reduced segmentation and monitoring complexity.

Scope reduction directly translates to lower audit burden and lower compliance cost.

Audit Takeaway

  • Clear separation of duties.

  • Hardware-backed cryptographic controls.

  • Reduced systemic exposure.

  • Lower residual risk due to architectural isolation.

The security strength is embedded in the design itself.

Google Pay: Centralised Trust & Token Lifecycle Management

Google Pay also uses tokenisation, but the architectural model introduces a centralised trust layer.

Technical Model

  • Card information is tokenised.

  • Token lifecycle involves Google servers.

  • Google participates in storage, routing, and token management.

  • Banks receive card data via Google infrastructure.

In this model, Google becomes part of the transactional data flow.

GDPR Impact

  • Google operates as a data processor.

  • Greater emphasis on Data Processing Agreements (DPAs).

  • Stronger requirements for purpose limitation controls.

  • Cross-border data transfer assessments become relevant.

  • Higher compliance complexity overall.

This does not imply non-compliance — but it increases governance obligations.

PCI DSS Impact

  • Google systems fall within PCI scope.

  • Larger attack surface due to centralised architecture.

  • Greater reliance on procedural and contractual safeguards.

  • Increased dependency on vendor assurance and control testing.

Scope is not eliminated — it is managed centrally.

Audit Takeaway

  • Security posture can still be strong.

  • Governance and third-party risk management become critical.

  • Control testing shifts from hardware isolation to process maturity and operational controls.

  • Vendor due diligence becomes a core compliance pillar.

Here, risk is managed through layered controls and governance frameworks.

Architecture-Driven Compliance

This is not about “Apple good, Google bad.”

Both models can be compliant with:

  • GDPR

  • PCI DSS

  • Local data protection laws

  • Financial regulatory frameworks

The distinction lies in architectural risk distribution:

  • Apple reduces risk by eliminating data custody.

  • Google manages risk by controlling data centrally.

As auditors and risk advisors, architecture matters as much as encryption.

Encryption protects data.
Architecture determines exposure.

Sometimes the strongest control is not adding another safeguard — it is removing yourself from the data flow entirely.

Key Risk Advisory Questions for Organisations

When assessing digital wallet integrations, consider:

  1. Who is the data custodian at each stage of the transaction lifecycle?

  2. Where is the token generated, stored, and resolved?

  3. Does this integration expand our PCI scope?

  4. Are we relying on contractual controls instead of technical isolation?

  5. How does this architecture affect our GDPR accountability model?

Digital payment innovation is accelerating — but regulatory accountability remains with the organisation.

Design decisions today shape audit findings tomorrow.

Read more Blog articles from our website
https://www.secsolutionshub.com/pci-compliance-challenges-and-how-to-achieve-it-in-2025/