Apple Pay vs Current C

[iapplelove]

*facepalms* They don't store any credit card data the Secure Card. And you know something.... Someone takes my credit number and uses it .... no problem, the bank takes the charges off.

Someone hacks CurrentC and gets my checking account information, they can wipe out my checking and saving account. And I am not reimbursed or made whole by the bank.

Break it down for you:

Credit number taken = Bank takes the liability
checking/saving acct wiped out by CurrentC hack = I have to take the liability.

I'm pretty sure it was sarcasm

 

[aristobrat]

No it's not. It is only known and stored by your CC issuer.

And those would be the other companies I'm referring to.

All passing of info from your iPhone is by tokens. There is no CC number on your iPhone that can be passed to anyone from your iPhone. There is NO way anyone or any company can acquire or determine your CC number from the tokens they receive. The token can only deciphered by the CC issuer.

I never said otherwise (regarding Apple Pay), and I've made the same point regarding CurrentC and checking account numbers, if MCX uses tokenization.

EDIT: Maybe YOU should read the article you linked since it does a good job of explaining and CLEARLY states your CC (or PAN) number is NOT stored or used in any transaction.

Here's a quote from the article. I will underline the part where the PAN is used used during a transaction.

When you go to pay in a store, your iPhone transmits the token to the merchant along with the token cryptogram, which is generated at transaction time by the Secure Element using the token and additional transaction-specific data. The token and this security code are sent through the normal payment networks where the token is finally mapped back to your PAN and your bank (hopefully) authorizes the transaction. The merchant never sees your actual account number, nor even your name. Your private information stays private and secure.

A full credit/debit transaction is made up of multiple steps, and looks something like this:

1. Cardholder requests a purchase from the merchant.
2. Merchant submits the request to their acquirer.
3. The acquirer sends to the request to the issuer.
4. The issuer sends an authorization code to the acquirer.
5. The acquirer authorizes the transaction.
6. The authorization is returned to the merchant.

In step #4, the Apple Pay token is mapped back to a real credit/debit card number.

Kudos to Apple for getting everyone's real credit/debit card numbers out of steps 1-3, which is where all of the big hacks to date have taken place. But the real credit/debit card number is used in step #4, which seems to be a surprise to some people.

 

[JoeTomasone]

Now this I like.
Something like this from a retailer perspective - if we could get them to collectively use it.
Not a bad price either.

http://www.theverge.com/2014/10/29/7086929/the-guy-behind-google-wallet-is-back-to-change-payments-all-over-again

2 thoughts:

1. That looks like a nice portable reader for wait staff in restaurants.. Except it looks *awfully* fragile. *drop* *crash* Ooops, sorry sir; no credit card payments today....

2. "Poynt integrate industry standard SSL TLS, DUKPT, TDES, PKI and AES"

FTFT.

----------

http://www.kirklennon.com/a/applepay.html

All I'm saying is that Apple Pay transactions still require the real credit/debit card number, and that number is stored on the servers of other companies.

"The issuers maintain a “token vault” that maps back tokens to their respective PANs". "Issuers", in all but rare cases, is the BANK that issued your credit card, and who obviously has the number on file.

You are making it sound like some MCX-like entity besides your bank or (in those rare cases) the payment network (MC/Visa/AMEX, though Amex does issue it's own cards as well) is holding a PAN to DAN conversion database. That is a misstatement of the facts. The DAN should only be held by the device and the issuer, which is to mean the entity that completes the billing transaction - i.e. the end of the payment chain for a given payment.

----------

A full credit/debit transaction is made up of multiple steps, and looks something like this:

1. Cardholder requests a purchase from the merchant.
2. Merchant submits the request to their acquirer.
3. The acquirer sends to the request to the issuer.
4. The issuer sends an authorization code to the acquirer.
5. The acquirer authorizes the transaction.
6. The authorization is returned to the merchant.

In step #4, the Apple Pay token is mapped back to a real credit/debit card number.

Kudos to Apple for getting everyone's real credit/debit card numbers out of steps 1-3, which is where all of the big hacks to date have taken place. But the real credit/debit card number is used in step #4, which seems to be a surprise to some people.

The "issuer" in step #4 IS YOUR BANK. They created the number, they sent you the card, they bill you, they collect your money. How could they NOT map the DAN to the PAN? They created BOTH of them!

Again, you make it sound like there's some nebulous entity in between the merchant and the issuer that can also map DAN to PAN.. There isn't.

 

[Julien]

And those would be the other companies I'm referring to....

But the real credit/debit card number is used in step #4 [by your financial institution], which seems to be a surprise to some people

So you are saying the financial institution that issues your Credit Card number actually has your Credit Card number. You honesty can't say with a straight face that you think people don't understand that their CC issuer actually knows their CC number?

So this is your definition of "other companies" having your CC number? You and your financial institution are 1st parties so it can NOT be defined as "other companies". Other companies by definition MUST be a 3ed party.

 

[aristobrat]

"The issuers maintain a “token vault” that maps back tokens to their respective PANs". "Issuers", in all but rare cases, is the BANK that issued your credit card, and who obviously has the number on file.

That's where I misunderstood. I have two VISA cards issued by two different credit unions, where everything about those cards is handled by companies other than the credit unions. I thought most banks not BofA/Citi/AMEX-sized had other companies take care of that for them. Thanks for clarifying that.

 

[deeddawg]

1. That looks like a nice portable reader for wait staff in restaurants.. Except it looks *awfully* fragile. *drop* *crash* Ooops, sorry sir; no credit card payments today....

Certainly a concern, but I firmly believe that if non-American waitstaff can manage these devices without catastrophy I suspect most American waitstaff should be okay. When I was last in Toronto it was neat not having my card leave my sight; payment processed right at the table by my server with the wireless terminal even printing the slip.

See http://www.nytimes.com/2007/11/21/dining/21hand.html

The hurdles are merchant and end user adoption, not technology availability.

4. The issuer sends an authorization code to the acquirer.
In step #4, the Apple Pay token is mapped back to a real credit/debit card number.
... But the real credit/debit card number is used in step #4, which seems to be a surprise to some people.

I know your confusion was cleared up in later posts, but for the benefit of other readers:

The Issuer is whomever issued your credit card to you. So by definition they're always going to have your credit card number, they're the ones that created it.

Usually the issuer is the bank or other financial institution you got your card from such as Wells Fargo, Chase, CapitalOne, etc. but as you noted sometimes smaller institutions such as credit unions may outsource this service.