* Posts by PaymentGuy

28 posts • joined 22 Feb 2018

Farewell, Android Pay. We hardly tapped you

PaymentGuy

"But Android/Google Pay? It uses generated card numbers that are only good once."

Where on earth does this misconception come from? It's just not true!

PaymentGuy

Re: Phone support?

Android Pay does not use a Secure Element.

PaymentGuy

Nonsense! The £30 limit is there because there's no cardholder verification (PIN) below that point; this is why it can go higher than £30 on mobile. It is perfectly possible (and is the case in many places around the world) to do low-value contact transactions without PIN or other verification.

And if it's a fraudulent transaction, the interchange the issuer gets is by far outweighed by the fees involved in processing chargebacks and refunds.

PaymentGuy

"More accurately, payments using phone NFC are vastly more secure than cards during the transaction, mainly due to the use of one-time tokens preventing any possibility of cloning or really copying anything relevant at all."

Exactly the same mechanism is used in a card. The difference is that the card number from a plastic card can generally also be used outside the phone (internet, MOTO) whereas that from a phone cannot. But the number itself is the same from transaction to transaction - it's the cryptogram, not the card number, that is tied to an individual transaction.

"Once you've notified your bank that your card is missing any liability for fraudulent use falls on them, so they're very good at dealing with such reports."

And the same with the phone, if you tell your bank it's missing.

PaymentGuy

"Google Pay (Android Pay) uses a generated 1 time card number that is matched to your real card details by the payment processing company (Visa/Mastercard) and then discarded."

This is incorrect.

PaymentGuy

As it says, that's a long-known theoretical vulnerability, and one that

a) is not possible on certain cards where the result of PIN entry is cryptographically signed

b) is not applicable to contactless at all, since the card is not asked to verify the PIN

PaymentGuy

Transactions themselves aren't encrypted (between card and reader). But that's not really the point, because each transaction contains a unique cryptogram which can only be generated by the real card for that one transaction. The real benefit of mobile is that the card number cannot, unlike plastic cards, be used for online/MOTO transactions - or put on a mag stripe card to get cash out of an ATM.

PaymentGuy

Apple use a Secure Element - a dedicated chip equivalent to the security of a bank card. Android Pay may, at best, use a TEE - an area of the main CPU nowhere near as secure as the SE. But secure enough, with the design of the solution, for this use.

PaymentGuy

The card number is neither encrypted, nor one-time use. It is, however, device-specific (tokenised) and tied to *Pay transactions. There is, however, a one-time use transaction-specific cryptogram for any chip transaction (contact or contactless).

PaymentGuy

"For one, your credit card number & such never leave your phone during a transaction"

That's incorrect. The card number *must* leave the phone, otherwise the retailer has no way to charge your account. But it's a device-specific number, not the 'real' card number (which isn't on your phone at all).

PaymentGuy

Re: A convenience

Or if you call the card issuer, they can block & remove the card.

PaymentGuy

Re: A convenience

Android Pay itself (or Apple, Samsung, etc.) has no maximum. If you got a £100 maximum then you're either using Barclays's app, or you came across a retailer who has their own upper limit for contactless or your issuer has put a limit on there.

Samsung Pay's only benefit, for me, is that it is present on Gear - unlike, for obvious reasons, Android Pay ;-)

PaymentGuy

Re: Seems to be the way things have to be ... in the name of "progress"

Not even sure what you mean here. Apple and Android Pay don't work with each other in the same way that any iOS app and Android app don't work with each other. The important thing is that they all work on the same contactless terminals, along with cards, in the same way that any video medium would work on the same TV given a standard common interface (which is what EMV contactless has).

PaymentGuy

Re: What could possibly...?

Strictly speaking, neither do Android/Apple Pay. The same number is used for every transaction, but they're only used for Android/Apple Pay transactions; i.e. can't be used for online or MOTO.

PaymentGuy

Re: What could possibly...?

They're only obliged to do this for debit cards.

PaymentGuy

Re: What could possibly...?

So the sooner we can ditch mag stripe, the better.

PaymentGuy

Re: What could possibly...?

Less detail, in fact, since the only place the CVV appears is on the back of the card (unless you're Amex of course)

PaymentGuy

Re: What could possibly...?

It's enough for what, exactly? What do you think you can *actually* do with those details?

PaymentGuy

Re: What could possibly...?

So you're fine with a physical card, where the same card number is used everywhere (in person, online, over the phone, mail order, on the mag stripe) but not with the tokenised payments used in mobile, where that card number can be used only in person, on that device, and only after you've unlocked it for use?

OK then.

PaymentGuy

Yes - it's just that Apple are bloodier-minded and there's currently (if ever) no other way for Barclays to get their cards on Apple devices.

PaymentGuy

Rather, it's MBNA who don't support Android Pay. Amex's supports their own cards in Apple, Android, and Samsung - as well as their own Android app (and probably others). You can actually have the same Amex card three times on a Samsung device if you load it in all three apps.

PaymentGuy

Re: Ahhh technology...

Ah - an Apple Pay user :-)

PaymentGuy

And with Apple & Samsung, annoying as it may be, you have to authenticate every transaction with PIN/fingerprint whether or not the phone's unlocked. So more secure, if less convenient.

PaymentGuy

Re: Simpler solution for Phone Bonk to Pay

Until you try to pay over the applicable limit (e.g. £30 in UK).

PaymentGuy

Re: I still don't understand

When paying at a physical terminal (i.e. contactless) the only entities that know *what* you've bought are the retailer and yourself - and whoever the retailer or yourself decide to tell.

Even your bank doesn't know what you bought - only where you bought it from (including the type of retailer it is) and how much it cost.

There is nothing of interest in the transaction data from the terminal to the card (or mobile) other than the amount and date of the transaction. So it's not possible for the card/mobile to know *what* you bought or who you bought it from.

Now - a mobile may infer the retailer based on your location, but it's unlikely. The *Pays will receive information from the card network (not the mobile) in order to provide you with notifications, which is where the retailer name & location in the wallet's transaction history comes from. So they will be building up a picture of where you shop - but not what you buy.

On the web/app, it's another matter. Retailers may directly integrate with *Pays and therefore more data may be directly available from the retailer.

PaymentGuy

Re: Cash

Neither are they for card payments, except possibly by the retailer. But then, unless you tell them, they've no idea who you are in the first place.

PaymentGuy

Re: We want PayPal

And how do you propose identifying your PayPal account? Log into the merchant's terminal for every transaction? Or perhaps use some sort of payment token - such as a phone - to identify the account?

PaymentGuy

So much wrongness in one sentence!

“Samsung Pay, which uses technology developed by its LoopPlay, has a feature neither of its main rivals can boast, as it can act as a passive magnetic reader. This means it can act as an Oyster card without being woken up”

LoopPay, not LoopPlay.

MST *sends* data to a mag stripe reader. Rather than being a passive reader, it's the complete opposite.

Oyster does not use mag stripe at all - it's Mifare/DESFire-based. In fact, none of the *Pays can emulate Oyster.

MST requires the phone to be woken, and Samsung Pay activated, since it's then actively broadcasting card data to whoever's listening.

Biting the hand that feeds IT © 1998–2019