Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

HXGuyAZ

macrumors 6502
Original poster
Sep 3, 2014
345
1
From what I understand, when you use Apple Pay, the phone generates a random number to use as the credit card number, which is one time use, and the merchant never actually knows your real credit card number.

How normally if you buy something and want to return it, the merchant asks to put it back on the same card you bought it from. How would this work if that generated number is a one time use and I assume is discarded after use?
 
From what I understand, when you use Apple Pay, the phone generates a random number to use as the credit card number, which is one time use, and the merchant never actually knows your real credit card number.

How normally if you buy something and want to return it, the merchant asks to put it back on the same card you bought it from. How would this work if that generated number is a one time use and I assume is discarded after use?

Why would the number be discarded after use? I would think they'd be able to reverse the charge just using the authorization code created. It's not like the banking system doesn't have a record of the transaction, the store just doesn't get anything more than the auth code.
 
Why would the number be discarded after use? I would think they'd be able to reverse the charge just using the authorization code created. It's not like the banking system doesn't have a record of the transaction, the store just doesn't get anything more than the auth code.

Maybe I misunderstood it than, I thought it generated the number once and then discarded it. But it seems like it does generate it once, and is transaction specific, and can't be used again...but it's not discarded so it could probably be used to reverse a transaction.
 
The merchant uses the same token to send you a credit to your account. You give the token to the merchant again using your phone.
 
The merchant uses the same token to send you a credit to your account. You give the token to the merchant again using your phone.
This. Everything basically just works in reverse.

Also, as a side note, when I used :apple:Pay today at Walgreens, the printed receipt had the last four of the device number and NOT the last four of the credit card.
 
Last edited:
It's helpful to remember that Apple Pay is just a payment processor. It's not Apple giving us all a line of credit and telling us we can only use that credit on our phones. These are our regular credit cards that we use every day, and in everything except the mode of transmission (NFC instead of swiping), transactions will be the same as with the credit card in hand.
 
From what I understand, when you use Apple Pay, the phone generates a random number to use as the credit card number, which is one time use, and the merchant never actually knows your real credit card number.

This isn't actually true. There is a separate number generated (the device account number) but it's kept. What's generated randomly is a cipher that is used WITH the device account number to authenticate the purchase.

So if a return has to happen, the device account number will still be valid, and the refund will go through fine.
 
From what I understand, when you use Apple Pay, the phone generates a random number to use as the credit card number, which is one time use, and the merchant never actually knows your real credit card number.

How normally if you buy something and want to return it, the merchant asks to put it back on the same card you bought it from. How would this work if that generated number is a one time use and I assume is discarded after use?

The Device Account Number is what replaces your real card number, and that doesn't number change.

What you're thinking of is the one-time dynamic security code, which is randomly generated for each transaction and used alongside the Device Account Number (think CVV -- sort of).

So returns are not a problem.
 
It's helpful to remember that Apple Pay is just a payment processor.
While it may be helpful, it isn't really exactly correct. The above implies the payments go through Apple instead of the normal card processing chain when they don't. What Apple provides is tokenization on the origination end (and token authentication to the payment processor) in exchange for a per-transaction fee from the bank.

These are our regular credit cards that we use every day, and in everything except the mode of transmission (NFC instead of swiping), transactions will be the same as with the credit card in hand.
You're forgetting a KEY benefit -- the transaction is NOT the same because your credit card number is not being sent through the networks or stored with the merchant where it's then subject to later breaches. Since the tokenization is a one-time transaction it also precludes any "skimmer" or "sniffer" technology from netting anything useful to hackers.

----------

So returns are not a problem.

Yeah, they're not going to be an issue. Just another transaction performed as a credit instead of a debit.

I really doubt that nobody in the payment card industry who were involved in creating the EMV Tokenization standard ever thought about how to do a return/refund... :D

Here's a good read: EMV Payment Tokenisation Specification - Technical Framework
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.