Posts by PaymentGuy

Apple takes another swing at Epic, says Unreal Engine could be a 'trojan horse' threatening security

Re: "to slide a change into the app that blatantly evaded App Review."

They didn't try to sneak. They planned to get 'caught' so they could formally challenge a monopoly under competition law.

Re: Is anyone stupid enough to believe....

Alternatively, Epic could argue that it could drop its in-app prices by (e.g.) 20%. Epic get the same revenue either way, but customers benefit.

Re: I don't see why Apple should get 30% of in-app purchases.

" I do see why apple should get that 30%, they should, because they can, i.e. because they have (no doubt carefully and cleverly) worked out that this is the max they can squeeze out"

Exactly. The very definition of anti-competitive practices and should be challenged. If there were multiple options *on that platform*, and 30% was the standard, then fair enough.

It differs from Google in that it is at least possible to use a different app store & payment method to avoid Google's 30%.

Re: "most egregious acts of sabotage that Apple has experienced with any developer,"

Nah - they purposefully triggered an action that would open up the route to challenge the legality (under competition law) of the Ts&Cs.

Epic move: Judge says Apple can't revoke Unreal Engine dev tools, asks 'Where does the 30% come from?'

"Yeah you can go to Android. And pay 30% commission there too."

Or use a different app store. The point isn't how effective that would be, the point is that it's just not possible on Apple.

Re: Switching to Android

"The fact that they market and brand as privacy focussed"

They say they don't let *third parties* have access to your data. This is not the same thing at all.

Re: Switching to Android

"Google Slurp Fest and their 30%"

Or an alternative app store; not an option iOS and potentially anti-competitive (I mean, it is, but not /yet/ legally speaking) - which is Epic's point.

Consumer campaign to keep receiving printed till receipts looks like a good move – on paper

Re: The security guard monitoring it wanted to see

Who said anything about not cooperating with police?

Re: I'll keep my receipt thanks.

"They can make a citizens arrest or they can just call the police and you walking off it makes you look guilty. In real life they will just detain you till the police get there then whose job is it to arrest said store guard for false imprisonment?"

What you've missed here is the following:

The police have power to arrest someone on suspicion of committing an offence, even if an offence hasn't been committed; i.e. "I think there may have been an offence, and I think you may have committed it."

Everyone else has to *know* that an offence has been committed, and then may arrest someone they suspect of committing it. Triggering a security scanner is not an offence. Unless they *know* that something has been stolen, they *cannot* arrest you. If they try it, then *they* have committed at least one offence.

"This is how the law works in practise, the innocent till guilty part doesn't come into play until you get to court. The police aren't going to assume you are innocent as it's literally their job to catch criminals."

Rubbish. The police will not subject themselves to the paperwork, and their own accusations of false arrest, based solely on the word of a doorman. Failure to stop for a security scanner is not an offence; neither is failure to comply with a security guards. It is trivial for the police to establish whether or not a theft is in occurring as soon as they show up; if they cannot, then what on earth are they going to present to the court when they get there?

Re: The problem is there's no defined standard, so it's roll-your-own (again)

"In order to not be challenged it would need to be digitally signed"

Nonsense. Most physical receipts are not tamperproof, so why would this suddenly be a requirement for digital receipts? If the retailer disputes the transaction, their financial records will show whether the sale took place. And if the payment wasn't in cash, it will be easy for the customer to show that a transaction did take place; this sufficient proof of purchase - irrespective of the availability of any receipt - for any statutory claims against the retailer.

Of course, for unwanted items and other 'goodwill' claims, the retailer can define any conditions they wish; the consumer has no statutory rights in this instance.

Farewell, Android Pay. We hardly tapped you

"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!

Re: Phone support?

Android Pay does not use a Secure Element.

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.

"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.

"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.

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

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.

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.

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).

"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).

Re: A convenience

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

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 ;-)

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).

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.

Re: What could possibly...?

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

Re: What could possibly...?

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

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)

Re: What could possibly...?

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

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.

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.

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.

Re: Ahhh technology...

Ah - an Apple Pay user :-)

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.

Re: Simpler solution for Phone Bonk to Pay

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

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.

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.

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?

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.