Difference between revisions of "Mobile Payment"

From MgmtWiki
Jump to: navigation, search
(→‎Context)
(→‎Compared Designs)
 
(12 intermediate revisions by the same user not shown)
Line 3: Line 3:
  
 
==Context==
 
==Context==
 +
 +
==Payments on Apple==
 
In 2022, the European Commission conducted an investigation in hashtag#Apple, which was prompted by concerns related to competition within the payment market. The specific concern was that hashtag#applepay, being the sole option available to iPhone users for contactless payments, might be limiting or suppressing competition in the industry.  
 
In 2022, the European Commission conducted an investigation in hashtag#Apple, which was prompted by concerns related to competition within the payment market. The specific concern was that hashtag#applepay, being the sole option available to iPhone users for contactless payments, might be limiting or suppressing competition in the industry.  
  
Line 20: Line 22:
  
 
🖇️𝗕𝗶𝗼𝗺𝗲𝘁𝗿𝗶𝗰 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻: Users will retain access to authentication features such as Face ID and will retain control over certain functionalities to tailor their payment experience according to their preferences.
 
🖇️𝗕𝗶𝗼𝗺𝗲𝘁𝗿𝗶𝗰 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻: Users will retain access to authentication features such as Face ID and will retain control over certain functionalities to tailor their payment experience according to their preferences.
 +
==Payments on Google==
 +
* [https://www.customerfutures.com/p/visas-new-pathway-to-empowerment Visa's new pathway to Empowerment Tech, and is Google Wallet the next Google Maps?]
 +
We’ve known for a while that Google was adding Government ID to the digital wallet. But now it’s here in the UK, and you’ll be able to scan your passport.
 +
 +
And it’s putting even more identity cats amongst the already very crowded UK ID pigeons.
 +
 +
The hawk-eyed Richard Oliphant sets out the mixed response to this pretty big news (link below):
 +
 +
“Competing with the Google Wallet - and, one assumes, the Apple Wallet - to provide identity verification and authentication will make this even more challenging.
 +
 +
“Survival will depend on the ability of identity providers to differentiate their products and expand their reach into regulated industry sectors through integrations with the likes of Docusign and Adobe.
 +
 +
“Whilst certification against the DIATF makes strategic sense, I wonder whether the stringent data privacy requirements might pose a problem.
 +
 +
“They won't, for example, allow Google to monetise identity data and feed it into their Targeted Advertising Machine . (This is less problematic for Apple).
 +
 +
“If Google certifies its Wallet against the DIATF, I regard it as more likely that they will seek to certify a version of their Wallet as an "EU Digital Identity Wallet" under the EU eidas framework.
 +
 +
“This would allow them to offer their Wallet for strong customer authentication in EU banking (and other regulated sectors) and to store EU mobile driving licences too.”
 +
 +
Lots and lots of debate around this.
 +
 +
From ‘it was inevitable, and who else can match the user experience’ to ‘are you kidding, more surveillance?’.
 +
 +
But the more important take isn’t about identity wallets.
 +
 +
It’s about the *other credentials* that customers can wrap around them.
 +
 +
Proof of insurance.
 +
Proof of attendance.
 +
 +
Proof of membership.
 +
Proof of license.
 +
 +
And much, much more. A long tail of evidence about people that isn’t currently digital or portable.
 +
 +
Until now.
 +
 +
Google has the reach, the business relationships, the balance sheet, and the wallet infrastructure to make verifiable credentials go mainstream. And I mean for *everyone*.
 +
 +
A bit like Google Maps.
 +
 +
And frankly, like Google Maps, they can do it all for ‘free.’
 +
 +
Why?
 +
 +
Because even if they can’t see what’s in the wallet (though likely they will), customers will get more *utility* with it.
 +
 +
And that means more transactions, more payments, and more revenue.
 +
 +
Just like Google Maps.
 +
 +
You make the core utility free, then make money from all the data that surrounds it. The vast 2nd-order data networks that emerge as a result.
 +
 +
You see, the smart brands won’t make money WITH customer data. They’ll make money BECAUSE of it.
 +
 +
Welcome folks, to the 2nd-order impacts of digital ID.
 +
 +
Will Google Wallet be as big as Google Maps? I wouldn’t bet against it.
 +
 +
==Compared Designs==
 +
 +
* [https://undercodetesting.com/apple-pay-vs-google-pay-a-deep-dive-into-security-privacy-and-technical-implementation/ Apple Pay vs Google Pay: A Deep Dive into Security, Privacy, and Technical Implementation] August 17, 2025
 +
 +
Apple Pay vs Google Pay: Security Comparison
 +
{|  border="1" padding="2" width="888px"
 +
|-
 +
|Feature || Apple Pay || Google Pay
 +
|-
 +
|Card Data Storage || Stored locally in a Secure Element chip on the device || Stored on Google’s cloud servers in encrypted form
 +
|-
 +
|Tokenization || Uses a Device Account Number (DAN) unique to your device || Uses a Payment Token linked to your card info stored on Google servers
 +
|-
 +
|Biometric Authentication || Required for every transaction (Face ID, Touch ID || Also required (Fingerprint, Face Unlock), but implementation varies
 +
|-
 +
|Transmission Security || Sends DAN during payment; real card number never leaves device || Sends token during payment; real card number stored remotely
 +
|-
 +
|Privacy Model || Apple does not track your purchases or store card data on servers || Google may retain purchase history, device ID, and profile data
 +
|-
 +
|Known Vulnerabilities || Rare; e.g., Express Transit bug allowing payments on locked iPhones || Rare; e.g., bypassing unlock step in older Android builds
 +
|-
 +
|Security Philosophy || Hardware-first: Secure Enclave + local-only data || Software-first: Cloud flexibility + fraud detection via data analytics
 +
|}
 +
 +
 +
===KARUNAKARA RAO KARNATI===
 +
 +
Apple Pay vs Google Pay Security
 +
 +
* Apple Pay Security
 +
1. Credit Card Info – You first add your card details into Apple Wallet.
 +
2. Pass Credit Card Info – The info is securely sent to the bank for verification.
 +
3. Store to Chip. – Apple Pay doesn’t store your real card number. Instead, it creates a Device Account Number (DAN) stored in the phone’s secure chip.
 +
4. DAN Used in Transactions – When you pay, Apple Pay sends this DAN instead of your actual card number.
 +
5. Bank Validates – The bank processes the DAN and approves the transaction.
 +
 +
Important Point: Apple never stores your card number on its servers. The sensitive data stays only on your device in the secure chip.
 +
 +
* Google Pay Security
 +
1. Credit Card Info – You add your card into Google Pay.
 +
2. Store Info to Google Server – Unlike Apple, Google Pay sends card info to its cloud servers.
 +
3. Payment Token Generated – Google creates a Payment Token that represents your card.
 +
4. Token Sent to Merchant – When you pay, this token is sent to the eCommerce server (merchant).
 +
5. Token Passed to Bank – The token is validated against the real card info stored in Google’s servers.
 +
6. Bank Approves – The bank checks the actual card info and approves the transaction.
 +
 +
Important Point: Google Pay relies on cloud tokenization, meaning your card info is stored on Google’s servers in the encrypted format.
 +
 +
* Apple Pay vs Google Pay Main Difference
 +
** Apple Pay: Card info never leaves your device → stays safe inside a secure chip.
 +
** Google Pay: Card info goes to Google’s servers → secure but involves a third party storing your card data.
 +
[[File:Apple vs Google Pay.jpg]]
 +
 +
===Byte Byte Go===
 +
https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handle-card
  
 
[[File:Apple google pay.jpg]]
 
[[File:Apple google pay.jpg]]

Latest revision as of 21:18, 22 September 2025

Full Title or Meme

Mobile Payment success is greatly determined by the functional of the mobile devcie.

Context

Payments on Apple

In 2022, the European Commission conducted an investigation in hashtag#Apple, which was prompted by concerns related to competition within the payment market. The specific concern was that hashtag#applepay, being the sole option available to iPhone users for contactless payments, might be limiting or suppressing competition in the industry.

In response to these concerns and regulatory pressures, Apple is opening up its NFC technology to third-party mobile wallet and payment service providers in the EEA and beyond. This shift marks a significant change in the mobile payment industry. Traditionally, Apple has exclusively reserved its NFC technology for Apple Pay and Apple Wallet.

Several foundational payment concepts and features are at play in this development. Let's explore them:

🖇️𝗡𝗙𝗖 (𝗡𝗲𝗮𝗿 𝗙𝗶𝗲𝗹𝗱 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻) 𝗧𝗲𝗰𝗵𝗻𝗼𝗹𝗼𝗴𝘆: Apple is taking a significant step forward by enabling third-party mobile wallet and payment service providers to access the NFC (Near Field Communication) capabilities found within iOS devices. What sets this move apart is that these providers won't required to rely on Apple Pay or Apple Wallet as intermediaries for accessing NFC technology.

🖇️𝗔𝗣𝗜 𝗔𝗰𝗰𝗲𝘀𝘀: Apple will have to create a pathway to utilize NFC technology on Apple devices seamlessly, as if they were Apple Pay or Apple Wallet themselves.

🖇️𝗛𝗖𝗘 (𝗛𝗼𝘀𝘁 𝗖𝗮𝗿𝗱 𝗘𝗺𝘂𝗹𝗮𝘁𝗶𝗼𝗻) 𝗠𝗼𝗱𝗲: In the context of Apple, HCE allows an iPhone to act as if it were a physical contactless smartcard, like a credit card, when interacting with compatible payment terminals or access control systems, without the need for a physical secure element.

🖇️𝗠𝗼𝗯𝗶𝗹𝗲 𝗪𝗮𝗹𝗹𝗲𝘁𝘀: Apple's decision extends to all third-party mobile wallet app developers operating within the European Economic Area (EEA). This broader access is a significant departure from the previous closed ecosystem and signals a more inclusive approach.

🖇️𝗖𝗿𝗼𝘀𝘀-𝗕𝗼𝗿𝗱𝗲𝗿 𝗧𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻𝘀: Apple's commitment extends beyond the boundaries of the EEA. Users can utilize these third-party apps for payments in stores located outside the EEA.

🖇️𝗕𝗶𝗼𝗺𝗲𝘁𝗿𝗶𝗰 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻: Users will retain access to authentication features such as Face ID and will retain control over certain functionalities to tailor their payment experience according to their preferences.

Payments on Google

We’ve known for a while that Google was adding Government ID to the digital wallet. But now it’s here in the UK, and you’ll be able to scan your passport.

And it’s putting even more identity cats amongst the already very crowded UK ID pigeons.

The hawk-eyed Richard Oliphant sets out the mixed response to this pretty big news (link below):

“Competing with the Google Wallet - and, one assumes, the Apple Wallet - to provide identity verification and authentication will make this even more challenging.

“Survival will depend on the ability of identity providers to differentiate their products and expand their reach into regulated industry sectors through integrations with the likes of Docusign and Adobe.

“Whilst certification against the DIATF makes strategic sense, I wonder whether the stringent data privacy requirements might pose a problem.

“They won't, for example, allow Google to monetise identity data and feed it into their Targeted Advertising Machine . (This is less problematic for Apple).

“If Google certifies its Wallet against the DIATF, I regard it as more likely that they will seek to certify a version of their Wallet as an "EU Digital Identity Wallet" under the EU eidas framework.

“This would allow them to offer their Wallet for strong customer authentication in EU banking (and other regulated sectors) and to store EU mobile driving licences too.”

Lots and lots of debate around this.

From ‘it was inevitable, and who else can match the user experience’ to ‘are you kidding, more surveillance?’.

But the more important take isn’t about identity wallets.

It’s about the *other credentials* that customers can wrap around them.

Proof of insurance. Proof of attendance.

Proof of membership. Proof of license.

And much, much more. A long tail of evidence about people that isn’t currently digital or portable.

Until now.

Google has the reach, the business relationships, the balance sheet, and the wallet infrastructure to make verifiable credentials go mainstream. And I mean for *everyone*.

A bit like Google Maps.

And frankly, like Google Maps, they can do it all for ‘free.’

Why?

Because even if they can’t see what’s in the wallet (though likely they will), customers will get more *utility* with it.

And that means more transactions, more payments, and more revenue.

Just like Google Maps.

You make the core utility free, then make money from all the data that surrounds it. The vast 2nd-order data networks that emerge as a result.

You see, the smart brands won’t make money WITH customer data. They’ll make money BECAUSE of it.

Welcome folks, to the 2nd-order impacts of digital ID.

Will Google Wallet be as big as Google Maps? I wouldn’t bet against it.

Compared Designs

Apple Pay vs Google Pay: Security Comparison

Feature Apple Pay Google Pay
Card Data Storage Stored locally in a Secure Element chip on the device Stored on Google’s cloud servers in encrypted form
Tokenization Uses a Device Account Number (DAN) unique to your device Uses a Payment Token linked to your card info stored on Google servers
Biometric Authentication Required for every transaction (Face ID, Touch ID Also required (Fingerprint, Face Unlock), but implementation varies
Transmission Security Sends DAN during payment; real card number never leaves device Sends token during payment; real card number stored remotely
Privacy Model Apple does not track your purchases or store card data on servers Google may retain purchase history, device ID, and profile data
Known Vulnerabilities Rare; e.g., Express Transit bug allowing payments on locked iPhones Rare; e.g., bypassing unlock step in older Android builds
Security Philosophy Hardware-first: Secure Enclave + local-only data Software-first: Cloud flexibility + fraud detection via data analytics


KARUNAKARA RAO KARNATI

Apple Pay vs Google Pay Security

  • Apple Pay Security
1. Credit Card Info – You first add your card details into Apple Wallet.
2. Pass Credit Card Info – The info is securely sent to the bank for verification.
3. Store to Chip. – Apple Pay doesn’t store your real card number. Instead, it creates a Device Account Number (DAN) stored in the phone’s secure chip.
4. DAN Used in Transactions – When you pay, Apple Pay sends this DAN instead of your actual card number.
5. Bank Validates – The bank processes the DAN and approves the transaction.

Important Point: Apple never stores your card number on its servers. The sensitive data stays only on your device in the secure chip.

  • Google Pay Security
1. Credit Card Info – You add your card into Google Pay.
2. Store Info to Google Server – Unlike Apple, Google Pay sends card info to its cloud servers.
3. Payment Token Generated – Google creates a Payment Token that represents your card.
4. Token Sent to Merchant – When you pay, this token is sent to the eCommerce server (merchant).
5. Token Passed to Bank – The token is validated against the real card info stored in Google’s servers.
6. Bank Approves – The bank checks the actual card info and approves the transaction.

Important Point: Google Pay relies on cloud tokenization, meaning your card info is stored on Google’s servers in the encrypted format.

  • Apple Pay vs Google Pay Main Difference
    • Apple Pay: Card info never leaves your device → stays safe inside a secure chip.
    • Google Pay: Card info goes to Google’s servers → secure but involves a third party storing your card data.

Apple vs Google Pay.jpg

Byte Byte Go

https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handle-card

Apple google pay.jpg

References

  • See wiki page on NFC
Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Mobile_Payment&oldid=25084"