Hacker News Reader

Comment by hprotagonist | Hacker News Reader

I unabashedly love apple pay and use it preferentially whenever I can.

in the US, it's faster than chip-and-pin cards by a LOT. It rolls a new number every time I use it, so i can pay at sketchy gas stations at 2 AM and not care about skimming. More and more gas stations are upgrading their pump POS pads so i can refuel my bike without digging under my armour for my wallet.

On websites, my only quibble is that it's often very hard or not possible to enter discount codes or other special checkout options like "pick up in store" when using the apple pay button(s); when I don't have any codes, I dearly appreciate not having to make an account for that merchant and i'm significantly more likely to spend money at websites that support it.

View on HN

> It rolls a new number every time I use it, so i can pay at sketchy gas stations at 2 AM

Nope. That's deliberately confusing Apple marketing. You get one PAN per device. The new "number" is just the EMV unpredictable number. You get that with any EMV card.

https://emvlab.org/emvtags/show/t9F37/

> and not care about skimming.

Because the PAN is only valid for online authorized EMV transactions.

So, yep? They didn't claim it was a unique feature of Apple Pay.

They make it sound like there is a special "Apple sauce" that they built and strongly suggest they generate a new PAN for every transaction. The suggest that a "token" instead of a PAN is used for the transaction. This is very misleading. If you read it very carefully they are not wrong, but for the uninitiated a wrong impression is crated.

They are using an industry standard protocol that is 25 years old.

suggest that a "token" instead of a PAN is used for the transaction

Maybe because people know the word "token" and don't know what a "PAN" is. Apple has built a trillion-dollar company by speaking at the level of its customers, not technobabble.

Your average customer doesn't know what either really mean.

I know that a "token" is some value that is used in the transaction. I still have no idea what a PAN is.

Primary account number, the 16 digit card number.

> but for the uninitiated a wrong impression is created

I'm somewhat uninitiated, and I definitely got the wrong impression. So thanks for your clear-up.

You are right that the core of Apple Pay security is functionally identical to chip and contactless transactions.

However a seemingly trivial but important difference with Apple Pay is that it doesn't use your physical card number—instead it uses a different card number randomly assigned to your device. The payment networks can therefore recognise Apple Pay-assigned numbers and know to demand full Apple Pay authentication when they are used.

This reduces the scope for downgrade attacks.

Insightful commentary on some of the value-adds of Apple Pay.

I do wonder if the security gain is significant enough to make Apple Pay integration a gross-positive for all parties. Apple appears to charge a ~0.1-0.2% fee per transaction made via Apple Pay [0], so it might be reasonable that the security adds enough value in its own right to make sense from a fraud/insurance perspective.

Might also be the fact that possibly being "Top of wallet" on Apple Pay (Which users might use anyway, irrespective of if their normal card is supported) provides enough value to take a small hit in fees.

[0] https://appleinsider.com/articles/16/02/22/apple-halved-tran...

I live in New Zealand and both Google Pay and my Garmin watch have unique numbers. This doesn't seem to be Apple exclusive at all? I have 2 Garmin watches, 2 Google Pay capable devices and a single physical card and the numbers are all different. At least, the last four digits are.

Nobody said it was an Apple exclusive.

But to be fair, after trying to do payments in various other ways, Google eventually built their Android payments platform to be an almost perfect 1:1 recreation of Apple Pay.

(And this is a recurring theme with Android. I'm not saying Google aren't within their rights to build things however they wish, but it is remarkable how often Google make loud smug noises about how they've done things differently to Apple—only for those points of differentiation to quietly disappear a few years later. Say what you will about Apple, a company that makes plenty of horrible mistakes, but it's remarkable how often they do get things exactly right the first time.)

How does one read "However a seemingly trivial but important difference with Apple Pay is that it doesn't use your physical card number" that as not suggesting it's something only Apple does?

Is that US-only maybe? I've had the last 4 digits of my CC printed on receipts paid with ApplePay in Europe.

The last four digits of your physical credit card number are stored by Apple Pay for the purposes of account identification.

There are varying reports of people seeing unfamiliar (i.e. device) numbers and their card number on receipts. I've no knowledge about exactly why there's no consistency, but my suspicion is that Apple Pay sends these four digits as metadata during the contactless transaction. Older contactless terminals would ignore it and naively print four digits of the account number, whereas newer terminals might recognise that metadata and print that on the receipt instead.

It's also possible that the physical card's last four digits are being sent back to the terminal by the network.

Yes, so unlike almost all the gas pumps before that used just the mag stripe it's much more secure. Contactless at the pump is great.

Mostly there, you get a tokenized PAN (DPAN) for every card enrollment. Remove, and re-add a card to your digital wallet and you'll get a new DPAN.

The unpredictable number is an (of a few) inputs into the generation of the CVV3, which is also based on a dynamic key from the issuer. Key rotation is on the order of weeks to months (depending on issuer). This is the "unique number" per transaction (part of tag 57 https://emvlab.org/emvtags/show/t57/ )

DPAN is only good for card-present transactions, provided CVV3, transaction counters, etc.

> Remove, and re-add a card to your digital wallet and you'll get a new DPAN.

Has anyone made a habit of rotating DPANs on a regular basis like this? Does Apple or your bank get irritated at some point?

Only possible problem I can think of is that you would trigger some of the fraud rules on Apple’s, network’s or issuer’s side as all theses parties have the ability to trigger yellow or red flows during the token provisioning. You would then probably have to call your issuer for assistance every time you want to provision new card to your device.

Why would you do this?

So that retailers won't be able to use DPAN to uniquely identify me across transactions.

On the flip side, the ability to look up your past purchases can enable returns without receipts.

The other week a store clerk failed to look up my purchase when using my physical credit card, but succeeded when using the same credit card via Apple Pay. I would have been out of luck if I had rotated my Apple Pay number.

Or perhaps your device could store previous identifiers and offer those to the vendor to lookup in their system? Assuming the vendor isn't doing something shady like building an association table between identifiers, this would preserve your privacy and let you change your identifier as much as you like.

I do. Every update of watchOS since version 6 seems to break activity syncing between my watch and phone. So I end up having to restore from backup every time, and thus reset ApplePay.

So far my banks have not complained.

I involuntarily do this (annually), when getting a new iPhone every year. My iOS Wallet app resets, and I'm forced re-add all my cards (although it does remember what cards where added previously). Never thought too much about it.

I would avoid doing this. Mastercard guidance (and I assume Visa is the same) is to treat this behaviour as fraudulent.

I once had a very long call trying to explain to a very upset Mastercard person why this behaviour wasn’t an issue. I don’t think they understood.

Mastercard client/user or Mastercard support/staff?

Mastercard staff member responsible for Apply Pay best practices.

I think there's also a button in settings to get a new card number?

That's an Apple Card thing I believe, not Apple Pay--and it rotates a different card number than the one in your physical Apple Card or device-specific card number. It's the one you're supposed to use on legacy online stores and rotating it is similar to ShopSafe, etc.

Another nice feature thing about Apple Pay (and maybe some others?) is automatic updating.

Some place I could not use Apple Pay with was involved in a breach, and so my bank notified me that I was getting a new card, and to start using it as soon as it came in the mail.

At about the same time as I got the email notice that this was happening, I got a notification on my iPhone that the card had been updating in Apple Pay to the new one. No action was required on my part.

I have no idea how they did that. I know there is a credit card updater service provided by at least Visa, MC, Discover, and AmEx that allows merchants with those cards on-file to ask for updates. We use that where I work, but the interface to it involves posting a file that contains one record per card we want updated in a fixed field format straight out of the punched char days (but wider than punched card). Then, typically in two or three days, a similar file comes back with update records for some of those cards. More updates trickle in that way over the next few days. And some never get a response.

Anyone know what it takes to get access to the kind of updates Apple is getting, where apparently the banks push the updates and they are very timely? Is this something only very high volume entities can get?

That's cool, but it must not be universal, because I've always had to re-setup my debit card.

It's up to the issuer to support the service, not just the company charging the card.

https://developer.visa.com/capabilities/vau

I've come across this in the Stripe API as a standard feature of a lot of cards. I haven't had one do this myself, but I also haven't lost a credit/debit card.

As someone who uses Stripe for a SaaS product, this is an amazing feature. It means not having to email/call the client just because they got a new card, and instead billing keeps going as if nothing changed.

TSYS EnsureBill

I think Google Pay does this too. Last time my debit card expired & a new one got issued, I went to replace the one stored in Google Pay; it was only in the fraction of a second between hitting the delete button & the card being removed that I noticed it had already automatically updated to the new number

> It rolls a new number every time I use it,

Are you positive about this?

When I used Apple Pay (in Germany) I always got the same card number. It was my understanding that the number is generated when you add a card to Wallet and is unique to your device, but not transaction.

EDIT: The Apple support site [1] claims the following:

> Full card numbers aren’t stored on the device or on Apple Pay servers. Instead, a unique Device Account Number is created, encrypted, and then stored in the Secure Element.

I believe this aligns with my understanding.

[1] https://support.apple.com/guide/security/credit-debit-prepai...

I believe OP means it generate a new payment token that's sent over for each purchase

That is not a unique feature of Apple Pay. It happens for any contactless 'card' payment.

Right but Apple, Android, Samsung, Walmart, NBCUniversal, TacoBellFritoLaySnappleGroup Pay are pretty much the first contactless payment platforms to really gather steam in the US.

Visa and MasterCard didn’t have the advantage of a phone platform that make contactless payment actually more convenient than magstripe so the value in rolling it out was pretty low.

Contactless is much more convenient than magstripe in nearly all situations where it's available - it's just that the US took forever to roll it out. By the time it reached a usable level of penetration, the phone platforms were ready to go.

I thought that you had a fixed number, but Apple generates some kind of unique code, which is sent to the terminal. I.e., the terminal doesn't see your actual number.

I've definitely had the last 4 digits printed out on a receipt. While it is conceivable that those were transmitted separately I find that somewhat unlikely.

I believe tokenization is a feature that is ultimately coming, but not quite there yet (and can also be supported by normal cards).

Disclaimer: I take interest in the payment-world, but am by no means an expert and have made the above claims only to the best of my knowledge.

EDIT: It appears the process of generating the device specific card number is already tokenization.

> After the validation, the card network acting as a TSP (Token Service Provider) creates a token (which is called a DAN or a Device Account Number in the context of Apple Pay) and a token key. This DAN is generated using tokenization and is not the actual card number.

[1] suggests that while some cryptography is done for each transaction, the token is the card number and still only unique to the device, not the transaction.

Said cryptography should be according to the EMV standard [2] and is also performed by a normal card (potentially minus the tokenization).

[1] https://www.freecodecamp.org/news/how-apple-pay-works-under-...

[2] https://en.m.wikipedia.org/wiki/EMV

> I've definitely had the last 4 digits printed out on a receipt. While it is conceivable that those were transmitted separately I find that somewhat unlikely.

I noticed this too. Some merchants print the last four of the device account number (DAN) and some print the last four of the actual primary account number (PAN).

I asked about it on /r/ApplePay [1]. /u/martialplum provided this explanation:

> Although the card number sent to the reader from in the transaction is the device account number, this gets de-tokenized along the way to your bank (either by the payment network or some third party) and the actual card number is the one used for authorization. Some issuers use the actual card number in the response they send back to the merchant (data element 2 in ISO 8583). Depending on how the card reader formats the receipt, it's not uncommon for merchant copies of the receipt to show the full device account number (expected), but show the last 4 of the actual card number for convenience when someone shows them the card on their device, which will show the same numbers.

The "ISO 8583" text in that was a link to this [2].

[1] https://www.reddit.com/r/ApplePay/comments/bnedl7/receipts_a...

[2] https://en.wikipedia.org/wiki/ISO_8583#Data_elements

There is a lot of deliberately confusing marketing. "Tokenization" simply means that a new PAN is generated once per device. This is a normal PAN registered with the payment scheme and your issuer. It has to be a normal PAN, otherwise it would never pass through all the exiting payment infrastructure.

What is generated per transaction is the EMV unpredictable number, but this is part of the EMV protocol and done for any EMV transaction. Think of this like the dynamically generated symmetric key for an SSL session.

Why do you say it's deliberately confusing?

Because we have a whole thread with dozens of comments full with people that don't understand what this means but seem to think it is a selling point for Apple.

> What is generated per transaction is the EMV unpredictable number, but this is part of the EMV protocol and done for any EMV transaction.

What about when magstripe emulation is in use, does Apple Pay support that in the US?

EMV is the antithesis of magstripe and the two have absolutely nothing to do with each other. Contactless EMV is NFC.

EMV transactions still use track data format from magstripe world to ensure backward compatibility.

Unfortunately the United States exists, so there has been a need for magstripe emulation over NFC. I don't know exactly how it works — I think it's some kind of hack on top of EMV — but it does exist.

Nope, Apple Pay is EMV only.

Only Samsung Pay does magstripe emulation.

Are you sure? Only Samsung (and LG apparently?) have the hardware feature where it tricks a magnetic stripe reader into thinking a card was swiped. However, the kind of magstripe emulation I meant is a feature of EMV where it can provide the same information as a magnetic stripe would, but over NFC, for compatibility with legacy (US) payment systems. Does Apple not support this latter system either? (It's apparently not supported for Apple Card, but Google isn't helping me for Apple Pay.)

You claim it's "Deliberately confusing"...

Which bit is confusing (or remotely deceptive)?

> When you make a purchase, Apple Pay uses a device-specific number and unique transaction code. So your card number is never stored on your device or on Apple servers, and when you pay, your card numbers are never shared by Apple with merchants.

Are you claiming this is untrue? Or deceptive?

What's actually happening, if I understand it correctly, is that when you setup Apple Pay you essentially get a _second_ card issued to you for that account that otherwise works just like a normal card but is only used by Apple Pay. It's still your card, still stored on the device, and still shared with merchants. If it wasn't you couldn't actually spend money with it.

Hopefully your bank has fraud controls on it to prevent it from being used outside of the way Apple Pay does (which requires your phone or a physical card so prevents theft) but that's not required and without it there is nothing stopping the card from being used like any other.

The device "card" number doesn't change with each purchase but it does have an additional one-time unique crytpogram as well as a dynamic security code that is needed to use that device number.

Yeah, absolutely love it. Just by virtue of breaking the £30 limit for contactless payments I now just never need my wallet. For a long time I held off upgrading my previous iPhone, and it never really occurred to me that Apple Pay was a killer app, but it's probably the single biggest quality of life upgrade that a piece of technology has given me in 5 years or so. My only sadness is that not many websites support it - where they do, you don't have to type out endless steps in a wizard, just give a thumbprint and that's it.

Not sure how contactless limits are set, but I suspect it's by the merchant. In Canada most are $100, though there's a handful of places that do $200. Costco is $400. If you go over the limit, you get promted to insert your card and use a pin.

Signing a signature is basically obsolete - in fact I can't remember the last time I did. Restaurants usually have a wireless terminal they bring over.

It's strange how regional those types of things are though. I am always surprised traveling in the US when I'm asked to sign (even with chip or contactless, which makes zero sense).

I believe in the UK it's by the card issuers as a security measure (it's definitely a flat £30 for most cards). They're happy to be liable for that amount a few times until the fraud prevention measures kick in, but not more. Apple's appetite for risk is perhaps a little bigger.

I don't think I've signed anything for 10+ years tbh, but the UK went pretty heavily for chip and pin early one. But honestly it's a coinflip whether I remember my pin these days.

Apple probably requires fully authenticated bi-device on-line transactions making the risk much smaller.

The EMV part requires the merchant device to be online or the process won't happen and the phone part requires user authentication; you'd have to break both at the same time to abuse it. Probably still possible, but much harder than stealing a card and using it until you hit the limit or get flagged.

Probably also why EMV contactless without PIN and EMV contactless with PIN have different limits (amount of transactions and transaction amounts).

The contactless payment subject to the £30 limit do not use the same protocol as Apple Pay. The limit is lifted because it is a more secure protocol similar to Chip&PIN with a random per transaction CVV. By comparison payment with contactless on card is dumber. It’s essentially equivalent to paying online with your card screaming its number to whoever wants to scan it.

If you use ApplePay on an older terminal, which does implement the more secure protocol, it falls back to the same protocol as used by contactless cards and is subject to the £30 limit.

Speaking as someone currently in the throes of trying to get their website setup to accept Apple Pay...it is an enormous hassle. Probably 5x the hassle of setting up PayPal and 10x the hassle of setting up Stripe.

First you need to join the Apple Developer Program. Why? I'm not developing an app.

To join the Apple developer program you need an Apple device that will do two factor auth. So I go buy an iPhone 6 with a cracked screen solely for this purpose.

Then you need Apple to approve your DUNS number. I am one of the minority who already had one, so I didn't have to go through the whole process with Dun & Bradstreet to get one, but Apple would not accept it for several weeks until suddenly they did, with no change to the number or other company info.

And then, you need to schedule a phone interview! This is the point I'm at right now, so I can't tell you how many more hurdles there are to clear. I haven't had luck yet with the Apple "click here and your phone will ring any moment with a call from us" button on their website. Phone never rings.

And I haven't even got to the part where I pay $100 before accepting any payments, which Stripe and PayPal sure don't require.

You have to endure a lot of friction to eliminate payment friction for your customers.

Huh, maybe it's because I'm using off-the-shelf software, but I've managed to get Invoice Ninja's Apple Pay integration [1] working with my Stripe account, with very little hassle.

[1] https://www.invoiceninja.com/payments-apple-pay/

To clarify for readers (doesn’t matter for you), terminals that support Apple Pay probably also support tap room pay with credit cards that have that feature. It’s just as fast as Apple Pay (once you have your card out).

Would you say it’s faster without having to use FaceID?

I’d say if you’re already using your phone while waiting in line, Apple Pay is faster. Otherwise, tapping a credit card is faster.

Also, overseas with a US CC you almost always have to sign, even if you have a PIN on the card, because the card are set to prefer signature (sometimes you can get away with a PIN; eg, in a parking garage with no cashier).

However, with Apple (okay, now Garmin) Pay, I never have to sign.

I went to the UK last year and made great efforts to contact Citibank in advance to get a PIN added to my card.

When it finally arrived in the mail (a week after request, literally hours before my flight), it turns out it's not even a Chip-and-PIN PIN, it's for cash advances. I still did a lot of signing reciepts and waiting for poor underpaid M&S cashiers to sort things out.

>More and more gas stations are upgrading their pump POS pads so i can refuel my bike without digging under my armour for my wallet.

This is literally the first time I've heard a use case that would actually make me care about contactless versus a swipe/insert. Grabbing my phone off the RAM mount would be considerably easier pulling my gloves off and trying to fish out my wallet.

In the past, I've always been incredibly apathetic toward the "convenience" factor of contactless, but that's a real -- if niche -- win.

I've always found contactless to be significantly faster than insert and more reliable than swipe - have you not found the same thing?

I find insert/chip is much slower because I have to leave the card in the device and pay close attention to the screen to figure out when I'm allowed to remove it. With a swipe pulling my card out, swiping, putting card can in wallet is a single action.

Sure, but that's not contactless, that's chip and pin. Contactless is exactly that; you need not touch the machine (though many do).

I always thought it would save you touching the communally-used PIN pad and thereby avoid potential contagion.

If you have an Apple Watch, you don’t even have to grab the phone.

Aren't you confusing Apple Pay vs Apple Card? I think only Apple Card as the beaver you talk about, rolling a new number every time you use it.

Not only is the actual authentication faster, most of the time when I use Apple Pay signature is not required. Even with large transactions it blasts right through and prints out a no-signature receipt.

It's all stuff which I never cared much about but definitely enjoy when it works right. It doesn't hurt that with the Apple Card I get 2% cash back when I use the phone.

The lack of discount codes for Apple Pay always puts me in a quandary of whether I want to just save the time or if it’s worth the hassle. From my experience it seems like I run into a lot of Shopify-backed sites, so I’m not sure if this is due to inherent Apple Pay problems or if it’s that a widely-deployed solution doesn’t support it.

As far as I can tell, that's just poor design on Shopify's part. You can work around it by adding a discount code while checking out with a different method, bailing out, then going back through Apple Pay. It's kind of crazy that it's been broken for so long.

Apple’s UX guidelines make things like discount codes and expedited shipping harder to implement.

I've never implemented it, but their examples show expedited shipping and it looks pretty straightforward.

https://applepaydemo.apple.com

Unfortunately, their docs are explicit about discount codes, "Do not ask the user to perform any other tasks before presenting the payment request. For example, if the user needs to enter a discount code, you must ask for the code before they press the Apple Pay button."

https://developer.apple.com/library/archive/ApplePay_Guide/C...

Why? Just make me choose shipping and discount options, then present me payment options. All Apple needs to know is the total to charge. Shopify just fucks this up by only having an option to enter a discount code after you've already missed your change to choose Apple Pay.

I have actually started preferring 76 stations because they all support the 76 app which lets me pay without credit card. My card was skimmed (and recreated into a new physical card!) earlier this year, which almost certainly happened at a gas station.

I'm holding out; i don't want to install yet another app, i want to wave my watch at the thing and have gas come out without mobil knowing more about me.

Back in the 90's Mobil had a little thing you put on your keychain that did this. It was shaped like a plastic tube about the size of a match, but thicker.

I don't know what happened to it. My guess is that since most gas stations are small businesses, they didn't want to pay to upgrade all of their pumps.

I find myself using these systems more as well. Publix, Kroger, and Walmart all have respective apps where you can scan a QR code on the screen (for both non-self-checkout and self-checkout) and pay using a card on file. Although, I think I use them only because they've chosen to not support Apple Pay and other mobile payment providers.

I'd continue using the Walmart app to pay in their stores even if they did start supporting Apple Pay on their terminals.

That's because those sales show up as being in the "online shopping" category for my credit card despite actually taking place in store, and I've got a card with very good cash back rewards for online shopping.

Shell and Exxon have the same.

and Sunoco

I prefer St1 stations in Finland because I can pay with the St1 credit card inside the St1 app. Really, the biggest benefit of using the app is that I don't have to stand in front of the payment terminal during winter, but I can rather just stay in the warm car until the pump is initialised and then just quickly go fill up.

> not having to make an account for that merchant

I had forgotten that was a thing. I'll have to remember to reach for the phone the the next time I'm ordering something off of a second- or third-choice website.

Reply on news.ycombinator.com