Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Pissingintowind
Jul 27, 2006
Better than shitting into a fan.
Hello goons! In an effort to prevent the iPhone thread from getting overrun by Apple Pay Chat, I've offered to answer some questions here. I work for one of the largest payments companies in the world, but, of course, nothing I say publicly on :siren:The Internet:siren: reflects the views of my employer.

Some sample questions I can knock out if people are interested:
  • How is Apple Pay different from Google Wallet?
  • Why won't Apple let me use Apple Pay on my iPhone 5S? The drat thing has a fingerprint reader!
  • How do the economics of a payment transaction work (merchant discount rate vs. network pricing vs. interchange)?
  • Why do I have to press a credit or debit button when I've clearly swiped a debit card?
  • What are some of the best rewards cards on the market (and why are rewards debit cards so rare nowadays)?
  • Why did it take the US so long to get EMV (chip) products?
  • What the hell is up with all of these card number breaches?
  • What are the different anti-fraud mechanisms on cards?
  • If I'm a merchant, how can I minimize my card processing costs?
...and much more! Feel free to ask me anything - if I can't answer for confidentiality reasons, I'll just say that.

Adbot
ADBOT LOVES YOU

Grassy Knowles
Apr 4, 2003

"The original Terminator was a gritty fucking AMAZING piece of sci-fi. Gritty fucking rock-hard MURDER!"

Pissingintowind posted:

Hello goons! In an effort to prevent the iPhone thread from getting overrun by Apple Pay Chat, I've offered to answer some questions here. I work for one of the largest payments companies in the world, but, of course, nothing I say publicly on :siren:The Internet:siren: reflects the views of my employer.

Some sample questions I can knock out if people are interested:
  • How is Apple Pay different from Google Wallet?
  • Why won't Apple let me use Apple Pay on my iPhone 5S? The drat thing has a fingerprint reader!
  • How do the economics of a payment transaction work (merchant discount rate vs. network pricing vs. interchange)?
  • Why do I have to press a credit or debit button when I've clearly swiped a debit card?
  • What are some of the best rewards cards on the market (and why are rewards debit cards so rare nowadays)?
  • Why did it take the US so long to get EMV (chip) products?
  • What the hell is up with all of these card number breaches?
  • What are the different anti-fraud mechanisms on cards?
  • If I'm a merchant, how can I minimize my card processing costs?
...and much more! Feel free to ask me anything - if I can't answer for confidentiality reasons, I'll just say that.

If I'm a merchant, how can I minimize my card processing costs?

Question Mark Mound
Jun 14, 2006

Tokyo Crystal Mew
Dancing Godzilla
If American banks can support Apple Pay now, what is the reason why the rest of the world isn't able to support it right away, too? I had always heard that America lagged behind when it came to payments (e.g. chip and PIN not being anywhere near as commonplace as, say, in the UK)

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

Kaizoku posted:

If I'm a merchant, how can I minimize my card processing costs?

CardFellow has an incredible website in general, which includes this extremely helpful guide.

I'll make a couple of key points:

First of all, if you are a brick-and-mortar merchant, and your effective merchant discount rate is more than 2.75% (including any monthly fees), you are getting ripped off. Switch to something like Square immediately until you think of a long-term plan. The same applies to eCommerce merchants - if you are paying more than 2.95% + $0.30, immediately switch to Stripe.

Second, in almost every situation, you are going to want "Interchange Plus" pricing. Heartland is a processor that typically comes highly recommended. Basically, instead of a blended rate like Square or Stripe, you'll pay actual interchange (specific to card product and merchant segment), plus a markup. Here is what you can expect to see for Interchange Plus:

Credit (Visa Traditional Rewards at a Retail segment merchant taken as an example):
Interchange (paid by the acquirer to the issuer, but you end up covering it for the acquirer): 1.65% + $0.10
Visa fees (paid by the acquirer to Visa, but again, you end up covering it for the acquirer): 0.11% + $0.02
Acquirer markup (paid by you to the acquirer): 0.35% + $0.06
Total to you (credit): 2.11% + $0.18 per transaction

Debit (debit Interchange is typically capped by law, so the product doesn't matter):
Interchange: 0.05% + $0.21
Fees: 0.11% + $0.02
Markup: 0.35% + $0.06
Total to you (debit): 0.51% + $0.29

Since the US is around 50% debit and 50% credit, your overall effective rate is the average of the two: 1.31% + $0.24. This means that as long as your average ticket is above $20 or so, you're doing better than Square's blended 2.75%.

Finally, it's usually better to own your card readers. Don't lease something for $40/month that you can buy for a few hundred bucks. It's like paying the cable company to lease your cable modem.

If you have a specific question, I can dive into more detail. Otherwise, I highly recommend reading the CardFellow guide that I linked above (I am not affiliated with CardFellow in any way).

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

Question Mark Mound posted:

If American banks can support Apple Pay now, what is the reason why the rest of the world isn't able to support it right away, too? I had always heard that America lagged behind when it came to payments (e.g. chip and PIN not being anywhere near as commonplace as, say, in the UK)

Apple Pay relies on a new EMVCo tokenization security standard that was assembled from scratch last year. This was an enormous undertaking for Visa, MasterCard, and American Express, and frankly, I'm shocked that it was pulled off in the amount of time that was available. Effectively what happens is that on a network processing level a card number to "token" card number mapping is maintained. Apple Pay uses the "token" card number for transactions, so the merchant never sees the actual card number. The US market has one major thing going for it: uniformity. All MasterCard POS transactions are processed by MasterCard's Banknet network processing system. All Visa POS transactions are processed by VisaNet. In many other countries, local processing systems process Visa, MasterCard, and American Express transactions, sometimes even by law. This fragmentation will make it extremely difficult to scale Apple Pay internationally, especially where the local processing system is a mandated, slow-moving, government-owned, lowest-common-denominator relic, but I'm sure it will happen eventually.

Technical changes were needed on the issuer side to support Apple Pay. It makes sense to start with the biggest banks in the world, and move down the chain from there.

Fruit Smoothies
Mar 28, 2004

The bat with a ZING
To what degree will the technology of Apple Pay be compatible / similar to rival services? IE, is there any "openness" in Apple's standard?

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

Fruit Smoothies posted:

To what degree will the technology of Apple Pay be compatible / similar to rival services? IE, is there any "openness" in Apple's standard?

There is no Apple standard - the only Apple-unique thing about Apple Pay is the Passbook experience (fingerprint reader and application design). Saying that Apple Pay is based on an Apple standard is like saying that iPhone mobile data is based on the Apple GSM standard. Apple is the first to implement the EMVCo tokenization standard (recently developed by Visa, MasterCard, and American Express) and has also implemented the EMVCo contactless standard. As far as the payments industry is concerned, this is the best way forward for mobile payments, and it is expected that other wallet providers will follow suit. The tokenization standard was designed to solve for Apple Pay, but it will not be exclusive to Apple Pay.

Google Wallet currently does not use the EMVCo tokenization standard, but they do use the EMVCo contactless standard. Not using the tokenization standard isn't necessarily the deal-breaker - the problem with Google Wallet's approach is that although it works as an awesome way to enable interoperability, it is terrible from an ecosystem perspective. Effectively, a Google Wallet is actually a prepaid card issued by Bancorp Bank that is enabled for EMVCo contactless and provisioned to the secure element of an Android phone. The prepaid fronting mechanism is an extremely creative workaround to be able to add any issuer's cards to the Google Wallet, because instead of having to work with every issuer to enable EMVCo contactless for their respective cards, they only have to enable it for one issuer: Bancorp Bank. When you tap an Android phone to pay, that prepaid card is "loaded" by whatever card you actually want to pay with. There are many issues with this approach from a customer experience perspective (chargebacks, rewards, potential for cash advance charges being triggered, etc.), and all of the non-Bancorp issuers and non-MasterCard networks hate it because MasterCard and Bancorp gain visibility into "their" transactions. I fully expect that Google Wallet will ditch this and start using the tokenization standard within a year.

edit: The other main competitor is Softcard (previously unfortunately named ISIS). Softcard is basically Apple Pay without tokenization, and where the secure element that card credentials are provisioned to is located on the carrier's SIM card instead of on the phone (as on the iPhone 6/6S). The downside of ISIS is that the carriers (Verizon, AT&T, T-Mobile) try to exact some of the economics from issuers ("renting" provisioning space on the SIM card), and therefore it is hard for them to get more issuers on board.

Pissingintowind fucked around with this message at 11:14 on Oct 23, 2014

No. 6
Jun 30, 2002

If Apple and the issuer are the only parties with access to the actual card number, how does a merchant get paid? Does the tokenized number along with the transaction get sent to Apple who then matches it and sends it off? Are the issuing banks getting the tokenized number from Apple? Basically can you explain each step of a transaction from merchant to acquirer?

Also, what do I tell cashiers to choose when selecting a payment type? Do they need to select a payment type or will the NFC reader engage the phone without intervention? I assume they'd hit credit for my Visa credit card, but I know Subway has a 'mobile' payment option (which doesn't seem to work). They pressed credit last time and Apple Pay was successful.

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

No. 6 posted:

If Apple and the issuer are the only parties with access to the actual card number, how does a merchant get paid? Does the tokenized number along with the transaction get sent to Apple who then matches it and sends it off? Are the issuing banks getting the tokenized number from Apple? Basically can you explain each step of a transaction from merchant to acquirer?

Also, what do I tell cashiers to choose when selecting a payment type? Do they need to select a payment type or will the NFC reader engage the phone without intervention? I assume they'd hit credit for my Visa credit card, but I know Subway has a 'mobile' payment option (which doesn't seem to work). They pressed credit last time and Apple Pay was successful.

Apple does not store the actual card number. In some cases, the issuer may only have the last 4 digits of the token (used for resolving disputes, etc.). The mapping between the two is at the network (V/MA/AXP) level.

There are two distinct activities: when the token is provisioned to the secure element, and when the token is used for a purchase.

Provisioning (note that the token is not "per transaction" as some shoddy news outfits are reporting - for now, the token is actually static per card, but the cryptography generated by the secure element is the dynamic part)
  • Cardholder scans/enters their card number on the iPhone
  • Apple sends this to the network (Visa/MasterCard/American Express) - at no point does Apple save the card number anywhere on their servers
  • The network alerts the issuer that their cardholder is trying to add their card to Apple Pay
  • The issuer sends a one-time password to their cardholder to authenticate (can be email, SMS, phone call, etc.)
  • Once authentication is verified, the network swaps the card number for a token (note that the issuer doesn't necessarily get the token at this point)
  • Apple receives the token from the network, and provisions it onto the secure element on the phone

Purchase
  • Cardholder taps phone on NFC terminal (authenticated through Apple's fingerprint reader, but this is application functionality, not payment network functionality)
  • Merchant's acquirer sends the authorization message with the token information from the iPhone's secure element to the network
  • The network switches the token to the card number, then sends the message with the card number to the issuer to authorize
  • The network keeps track of the credit due to the merchant's acquiring bank, and the debit due from the cardholder's issuer - the merchant's acquirer settles with the merchant as it normally would later, and the network settles between the issuer and acquirer later
  • If authorization is received from the issuer, the approved authorization response is sent back to the merchant's acquirer via the network
  • The acquirer alerts the merchant through their POS system that the transaction is approved
  • Cardholder gets his/her goods

The easiest thing to tell cashiers is "credit" (for both credit and debit cards). "Debit" should theoretically also work for debit cards, but it is made complicated by the fact that in the US (by law), every debit card has multiple debit networks on it. For example, Chase Visa debit cards typically also have Pulse (Discover's debit network) available as a choice for the merchant when the "debit" button is pressed. Merchant POS systems theoretically should be smart enough to not send contactless transactions to Pulse's network for now (since Pulse doesn't support contactless or de-tokenizing), but you never know. Eventually, this will be a non-issue because the other networks will likely build support for contactless and de-tokenization.

NFC readers can vary - some of them do engage without cashier intervention, others need to be activated. For the latter, you can just say you want to use tap and pay or something.

Pissingintowind fucked around with this message at 11:59 on Oct 23, 2014

shodanjr_gr
Nov 20, 2007
Thanks for the awesome thread! My question is, can you use EMVC contactless payments (eg Apple pay) for a supported card from a U.S. Bank on a wireless payment terminal outside the U.S.?

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

shodanjr_gr posted:

Thanks for the awesome thread! My question is, can you use EMVC contactless payments (eg Apple pay) for a supported card from a U.S. Bank on a wireless payment terminal outside the U.S.?

Shortest answer so far: yes :v:

Pissingintowind fucked around with this message at 12:23 on Oct 23, 2014

serebralassazin
Feb 20, 2004
I wish I had something clever to say.
Interesting thread, thanks for doing this. Now my question is how feasible would it be to have banks support using apple pay to withdraw money from a bank account via ATM machines? Basically, in time could I take some money out of my bank account by tapping my phone on an ATM machine.

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

serebralassazin posted:

Interesting thread, thanks for doing this. Now my question is how feasible would it be to have banks support using apple pay to withdraw money from a bank account via ATM machines? Basically, in time could I take some money out of my bank account by tapping my phone on an ATM machine.

Theoretically, as long as the ATMs support the NFC (payWave, PayPass, or ExpressPay) contactless interface, it should already work (about 80% sure on this - will check). However, typically ATMs, AFDs (automated fuel dispensers), and other UATs (unattended terminals) are the very last card acceptance devices to be upgraded with new hardware technology, so I wouldn't expect this to happen any time soon in the US at any scale. Even countries with lots of contactless POS acceptance (Australia and Poland for example) don't have many contactless ATMs.

serebralassazin
Feb 20, 2004
I wish I had something clever to say.
Thanks for the information. My dreams of lazy ATM withdrawals will remain dreams for now it seems.

blugu64
Jul 17, 2006

Do you realize that fluoridation is the most monstrously conceived and dangerous communist plot we have ever had to face?

Pissingintowind posted:

Effectively, a Google Wallet is actually a prepaid card issued by Bancorp Bank that is enabled for EMVCo contactless and provisioned to the secure element of an Android phone. The prepaid fronting mechanism is an extremely creative workaround to be able to add any issuer's cards to the Google Wallet, because instead of having to work with every issuer to enable EMVCo contactless for their respective cards, they only have to enable it for one issuer: Bancorp Bank.

I don't think this is quite right, I know I've seen a citi MasterCard (credit) that works directly with google wallet sans Bancorp.

Edit: the only one issuer part

Agronox
Feb 4, 2005
What are your thoughts on CurrentC, the competing thing that some of the retailers are pushing?

Asymmetric POSTer
Aug 17, 2005

First off, thank you for making this thread. Billions of dollars are zipping across wires everyday and people probably don't spend a microsecond to think about what's going on in the backend. I'm especially fascinated with how long it's going to take the US to move to chipped cards when I see such a large install base of magstripe only equipment out there (parking lot payment terminals, POS systems with built in swipe readers, etc). I've got many questions:

Pissingintowind posted:

Since the US is around 50% debit and 50% credit, your overall effective rate is the average of the two: 1.31% + $0.24. This means that as long as your average ticket is above $20 or so, you're doing better than Square's blended 2.75%.

Pre-durban, were "signature" debit transactions in the US charged the same rate to merchants as credit transactions? as in, a Visa/Mastercard debit card being swiped/signed without a PIN? If so, banks must have been laughing all the way to...well I guess themselves for how much money they were making vs normal/old style EFTPOS PIN based transactions people had been using since the 80s.

Pissingintowind posted:

Apple Pay relies on a new EMVCo tokenization security standard that was assembled from scratch last year. This was an enormous undertaking for Visa, MasterCard, and American Express, and frankly, I'm shocked that it was pulled off in the amount of time that was available. Effectively what happens is that on a network processing level a card number to "token" card number mapping is maintained. Apple Pay uses the "token" card number for transactions, so the merchant never sees the actual card number. The US market has one major thing going for it: uniformity. All MasterCard POS transactions are processed by MasterCard's Banknet network processing system. All Visa POS transactions are processed by VisaNet. In many other countries, local processing systems process Visa, MasterCard, and American Express transactions, sometimes even by law. This fragmentation will make it extremely difficult to scale Apple Pay internationally, especially where the local processing system is a mandated, slow-moving, government-owned, lowest-common-denominator relic, but I'm sure it will happen eventually.

Technical changes were needed on the issuer side to support Apple Pay. It makes sense to start with the biggest banks in the world, and move down the chain from there.

This is fascinating, I didn't realize Apple Pay is just a straight (and yet elegant) implementation of an EVMCo standard. Gives confidence for the longevity of it since it's not really further fragmenting the payment space. Can you go into detail about the US's previous foray into RFID/NFC based payments and the security risks that came up? I've read this article that showed when the cards first came on the market there were multiple implementations, some just atrociously bad from a security standpoint. How exactly do passive RFID chips do any sort of rolling tokenization/sequencing/etc for security? With EMV the chip is powered while in the terminal to do its magic, were these RFID chips using the field broadcast by the reader to give enough power for a chip to change the code/token/etc?

Furthermore, what's the difference between some of the "tokenization" with EMVCo contactless vs the previous implementations that existed/exist in the US? You say the Apple Pay token for now is static, and it's the encryption keys that encrypt transaction. Basically, my Apple Pay/EMVCo token is a "static" credit card number that has its own public/private key?

Pissingintowind posted:

What the hell is up with all of these card number breaches?

Will EMV solve essentially all of this because we'll stop transmitting and storing card numbers in plaintext read off magnetic strips like cavemen?

I'm spergin' about payments :spergin:

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

blugu64 posted:

I don't think this is quite right, I know I've seen a citi MasterCard (credit) that works directly with google wallet sans Bancorp.

Edit: the only one issuer part

You are correct. Several Citi MasterCard products use Google Wallet natively (in the same way that Chase is used on Softcard). No other banks and networks were willing to accept Google's terms, and so they enlisted Bancorp Bank as a workaround, which pissed off the other banks and networks even further.

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

Agronox posted:

What are your thoughts on CurrentC, the competing thing that some of the retailers are pushing?

I think EMVCo tokenization plus EMVCo contactless is a much more standardized approach. CurrenC is planned to (initially, at least) only work at the participating retailers. Today, we have store cards that only work at particular stores (think Target's REDcard or others). CurrenC will be the same - it won't die a violent death, but I don't think it will be as successful as the globally standardized systems, and if I had to predict, I think eventually the members of CurrenC will enable EMVCo contactless as well. Some already have.

CurrenC exists for the sole purpose of cutting out Visa/MasterCard/American Express/Discover. They believe that they can achieve a lower expense solution by hooking directly into your bank account, thereby avoiding paying interchange to card issuers. At the same time, card issuers own those bank accounts that CurrenC plans to hook into. It will be interesting to see how issuers will react to a clear attempt to dodge one of their major revenue streams.

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

mishaq posted:

Pre-durban, were "signature" debit transactions in the US charged the same rate to merchants as credit transactions? as in, a Visa/Mastercard debit card being swiped/signed without a PIN? If so, banks must have been laughing all the way to...well I guess themselves for how much money they were making vs normal/old style EFTPOS PIN based transactions people had been using since the 80s.

Here is Visa's current interchange guide, as an example. When I said that all debit has regulated interchange in the US, I actually oversimplified to avoid going into too much detail. In truth, if a bank is small enough, it can still use the default unregulated interchange rates for debit (specified in the guide on pages 2-6). I believe the limit is under $10B in assets. Signature debit transactions are still cheaper than credit, but more expensive than PIN debit because they offer the issuer a better chance that the transaction can be completed (you and I would probably never forget our PIN, but Joe American Citizen does all the time).

Note that prepaid is considered a debit product and is also subject to interchange caps. Google Wallet's prepaid fronting card is Bancorp, which is small enough to use unregulated interchange rates (and also qualifies as a "General Purpose Reloadable" card, some of which are exempt from interchange regulation. Using an unregulated prepaid card as a fronting mechanism is another reason that Google Wallet does not have issuer support - it operates in a legal grey area. If the unregulated Bankcorp prepaid card is funded with a regulated Chase debit card, Bancorp has effectively collected unregulated interchange from the merchant although the regulators would have liked to have seen that transaction qualify for the cheaper regulated rates.

mishaq posted:

This is fascinating, I didn't realize Apple Pay is just a straight (and yet elegant) implementation of an EVMCo standard. Gives confidence for the longevity of it since it's not really further fragmenting the payment space. Can you go into detail about the US's previous foray into RFID/NFC based payments and the security risks that came up? I've read this article that showed when the cards first came on the market there were multiple implementations, some just atrociously bad from a security standpoint. How exactly do passive RFID chips do any sort of rolling tokenization/sequencing/etc for security? With EMV the chip is powered while in the terminal to do its magic, were these RFID chips using the field broadcast by the reader to give enough power for a chip to change the code/token/etc?

First of all, yes, all contactless technologies are powered up inductively by the acceptance terminals. This is one of the reasons why it's annoying to make a Square-type contactless dongle for phones - it would be constantly draining battery power while "polling" for nearby contactless cards to enable.

So, without being a dick, that study is bullshit and is a perfect example of engineering-types that kind of understand the technology, but don't understand the business logic and operations that work together with the technology. Yes, they were able to pull data off of a contactless card - BUT if they had actually tried to use that data to make a real, non-simulated purchase, they would not have been able to in almost all situations. Any situations in which a purchase would have gone through would have been because of an issuer's improperly configured anti-fraud system - not because of a problem inherent with contactless technology. Most of the media coverage around contactless in the early days was completely inaccurate clickbait garbage (the original clickbait!).

This is going to be a detailed reply, so bear with me. In order to understand why data "skimmed" from a contactless transaction is useless, it's necessary to understand Cardholder Verification Values (called different things for different brands, but all are effectively the same in function).

A mag stripe card without a contactless interface has two different CVV values: CVV1 and CVV2. CVV1 is a static number embedded on the actual mag stripe. As a cardholder, you won't know what the CVV1 is, but it is read in plain text from the mag stripe at the time of a mag stripe transaction. It is basically a basis of comparison for other CVVs. CVV2 is the (obviously static) number printed on the card. It is there to authenticate eCommerce transactions - eCommerce merchants should prompt for CVV2. If they don't, and an issuer still approves the authorization request, that transaction becomes the issuer's problem because it's their decision on whether or not they want to take the risk of fraud. You will not be liable. Most transactions without a CVV2 are declined by the issuer. If your mag stripe is skimmed, the skimmed data will not contain the CVV2. Therefore, in order for someone to make a fraudulent eCommerce transaction, they typically need to have your CVV2 (usually obtaining by physically having possession of your card). At the same time, someone can easily skim your card mag stripe and use those credentials to create a counterfeit mag stripe card for use in mag stripe or chip readers.

In the US, the first flavor of contactless was called MSD (Mag Stripe Data). Effectively, all of the data from the mag stripe was passed to the card reader over an air interface in plain text, with one small difference. Instead of the static CVV1, the contactless chip would generate a one-time dCVV (dynamic CVV). Think of this in the same way that RSA tokens work - it is not possible to guess what the next dCVV will be for the next transaction without the keys to the dynamic number generator. People lost their poo poo over this, but again, it doesn't matter that the data was passed in plain text. The CVV1 was not passed, so if someone skimmed your MSD contactless card, they wouldn't be able to make a fake mag stripe card. The CVV2 was not passed, so no fraudulent eCommerce transactions. The dCVV was dynamic, so no possibility to make a fake contactless card. Finally, no fraudster with a merchant account would be able to "initiate real purchases" by tapping an actual terminal to your pocket, because there's an approval process for merchant accounts.

Next come contact EMV cards. These are the chip cards that everyone thinks about. Contact EMV is the same as mag stripe, except for three differences. First is that the mag stripe is coded to let the card reader know that the card has an EMV contact chip. If an EMV card attempts a mag stripe transaction at an EMV reader, the reader will not allow the transaction and will ask that the contact EMV interface is used instead. If a fraudster skims the mag stripe and uses the card at an EMV reader using the mag stripe, it will therefore fail. If the fraudster changes the coding of the mag stripe (not hard) to say that the card doesn't have an EMV chip, the issuer will know something is up because they know that the card DOES have an EMV chip; subsequently, the issuer will decline the transaction. Now on the contact chip interface side... Contact chips still pass credentials like the card number in plain text, but as with MSD contactless above, those credentials are worthless to fraudsters. Instead of a CVV1, the contact chip passes an iCVV. The iCVV is a static value that basically says "hey, this is a chip card." This means that if credentials are skimmed from a contact chip to make a mag stripe card, the iCVV will be where the CVV1 is expected, and it will not work. No CVV2 is passed, so no eCommerce transactions can be made. A fake MSD contactless card can't be made, because the iCVV will not match the expected dCVV. In order to prevent the skimmed credentials from working on a fake chip card, there is also a dynamic element: the chip cryptogram. This basically works the same way as a dCVV and is passed in a separate field. If a fraudster tries to take chip credentials to make a fake chip card, the cryptogram will be out of date and it will fail.

Finally, there is contactless EMV. This is basically the same as contact EMV, and employs an iCVV and a cryptogram, except over an air interface. The same protections apply.

mishaq posted:

Furthermore, what's the difference between some of the "tokenization" with EMVCo contactless vs the previous implementations that existed/exist in the US? You say the Apple Pay token for now is static, and it's the encryption keys that encrypt transaction. Basically, my Apple Pay/EMVCo token is a "static" credit card number that has its own public/private key?

The EMVCo tokenization standard can be used to initiate transactions without disturbing the status quo acceptance environment (extremely important) because the tokens look and act exactly like a card number. Except for a few instances, all other previous tokenization efforts have been either proprietary interfaces (LevelUp, for example), or card-on-file card number storage solutions (many, many examples). Interestingly, the only transaction initiation tokens that I can think of were the one-time-use card numbers that some banks would allow their cardholders to create. At the same time, these were on an issuer-by-issuer basis - network-level tokenization is vastly preferable because it opens tokenization to all interested parties.

I've covered the encryption piece elsewhere, but remember that tokenization is not encryption. The token is still passed in plain text, but it is not useful for fraud purposes at all and, on a consistent basis, only the network (sometimes the issuer) knows the card number that maps to the token. The cryptogram is the part that requires keys and is dynamic, per-transaction.

mishaq posted:

Will EMV solve essentially all of this because we'll stop transmitting and storing card numbers in plain text read off magnetic strips like cavemen?

Not 100%, but to a large degree, yes. There is still the small chance that your issuer may decide to approve an eCommerce transaction without a CVV2. Of course, if it's fraud, they will be liable. Remember, EMV still transmits the card number in a way that is readable, it's just a question of what can be done with that card number. What EMV will fix (when terminals and cards become widespread) is the usage of compromised card credentials for fake mag stripe cards, which is the major danger today. There are two technologies that will help: one is point-to-point encryption, which finally closes the plain text transmission "vulnerability" (not that big of a deal) and the other is 3D-Secure, which is effectively a one-time password system for eCommerce. P2P encryption is not yet live, while 3D-Secure is huge in non-US markets, but the US is dragging on adoption because the cost of eating eCommerce fraud is lower than the cost of implementation.

Also worth mentioning is that any "card-on-file" breaches (not POS sniffing at point of entry like at the time of the mag stripe swipe) can be solved through tokenization, since any data stolen will be easily-disabled tokens.

Finally, PIN (or one-time passwords a la 3D-Secure except non-eCommerce, or fingerprint reads, etc.) is the last missing piece of the puzzle. PIN incrementally solves for lost/stolen card fraud in a brick-and-mortar environment. This situation is similar to 3D-Secure - the cost of eating this type of fraud is still cheaper than the cost of implementing PIN in the US.

mishaq posted:

I'm spergin' about payments :spergin:

Same, but at least it's my job :v:

Also, this post took me almost an hour, so I hope it's helpful!

Pissingintowind fucked around with this message at 10:51 on Oct 24, 2014

nickutz
Feb 3, 2004

Put blue and red chicken in mouth plz
Used Apple Pay for the first time today. The charge immediately appeared in the recent transactions with the merchant and amount, and a few seconds later another push from AMEX for using my enrolled card because I had a statement credit offer for that specific merchant. Really couldn't have been more seamless.

Agronox
Feb 4, 2005
Thanks for writing all of this up, PIW. I don't have any more questions but it's been interesting reading. :)

Pappyland
Jun 17, 2004

There's no limit to your imagination!
College Slice

Pissingintowind posted:



In the US, the first flavor of contactless was called MSD (Mag Stripe Data). Effectively, all of the data from the mag stripe was passed to the card reader over an air interface in plain text, with one small difference. Instead of the static CVV1, the contactless chip would generate a one-time dCVV (dynamic CVV). Think of this in the same way that RSA tokens work - it is not possible to guess what the next dCVV will be for the next transaction without the keys to the dynamic number generator. People lost their poo poo over this, but again, it doesn't matter that the data was passed in plain text. The CVV1 was not passed, so if someone skimmed your MSD contactless card, they wouldn't be able to make a fake mag stripe card. The CVV2 was not passed, so no fraudulent eCommerce transactions. The dCVV was dynamic, so no possibility to make a fake contactless card. Finally, no fraudster with a merchant account would be able to "initiate real purchases" by tapping an actual terminal to your pocket, because there's an approval process for merchant accounts.


Perhaps I missed it, but what security benefits does Apple Pay's EMV Tokenization implementation have over MSD?

SimplyCosmic
May 18, 2004

It could be worse.

Not sure how, but it could be.
I am likely completely misunderstanding the process, but do transactions via ApplePay allow a retailer to track transactions of an individual card holder? Working in retail support, I'll be curious to see how retailers handle any of these systems if they can't automatically know John Smith is making the purchase like they do currently. A good number of customers lose their receipts, and often customer service can retrieve the receipt using the credit card used to make the purchase. Will ApplePay allow that in any way? If not, I have to imagine retailers are going to start pushing clients to give a phone number or use a loyalty card at the time of purchase more often.

Lolcano Eruption
Oct 29, 2007
Volcano of LOL.
How viable will Coin be when it finally releases in Spring 2015?

I was thinking of canceling my preorder due to:
1) Apple pay is already out
2) all of my cards already have EMV chips
3) plenty of merchants are already requiring me to use the chip rather than swiping

If this was to release Spring 2014 as scheduled, it would've been pretty useful. But now with the dalay, I fear it's going to become a useless gadget.

SHISHKABOB
Nov 30, 2012

Fun Shoe
My dad works in the credit card part of jp Morgan and chase, is that a part of the "payments industry".

Snuffman
May 21, 2004

Forgive me, I don't have an iPhone 6 but I do live in Canada where chip+pin and tap n pay have been a "thing" for quite some time.

What's stopping Applepay from working in Canada, outside of the passbook support? As I understand it, US iPhone 6 users can happily ApplePay up here with no issues.

serebralassazin
Feb 20, 2004
I wish I had something clever to say.
Probably agreements with Canada's major banks and credit card banks.

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

Pappyland posted:

Perhaps I missed it, but what security benefits does Apple Pay's EMV Tokenization implementation have over MSD?

EMV tokenization can be stacked on top of contactless MSD or contactless EMV (it also works in a slightly different way for in-app purchase eCommerce and card-on-file eCommerce, but you didn't ask about that). It replaces the card number that is transmitted by the contactless chip with a surrogate card number (the "token"). This way, on the off chance that someone does skim the number, and then finds an eCommerce merchant that doesn't ask for CVV2, the issuer will know that the token was assigned to Apple Pay for use in a contactless environment and will decline the transaction 100% of the time (instead of leaving their approve/deny decision up to historical transaction information as is normal for eCommerce transactions without CVV2).

Additionally, if you lose your phone, but not your actual card, it's much less painful to deactivate the token that was on the phone than the card number.

SimplyCosmic posted:

I am likely completely misunderstanding the process, but do transactions via ApplePay allow a retailer to track transactions of an individual card holder? Working in retail support, I'll be curious to see how retailers handle any of these systems if they can't automatically know John Smith is making the purchase like they do currently. A good number of customers lose their receipts, and often customer service can retrieve the receipt using the credit card used to make the purchase. Will ApplePay allow that in any way? If not, I have to imagine retailers are going to start pushing clients to give a phone number or use a loyalty card at the time of purchase more often.

Tracking an individual with their actual card number is a problem. This is not desired behavior, and leads to those card numbers getting compromised. Since the Apple Pay token is static per card right now, theoretically it should allow the retailer to look up the transactions as long as their POS can do that with a contactless input method. At the same time, there will eventually be a new message field in a tokenized transaction separate from the token number that you can think of as a "customer identifier." This will become the "correct" field to store for keeping track of customers. The initial priority for launching tokenization was to not force any changes to the acquiring side, so the customer identifier was not included from the get-go as far as I am aware.

Lolcano Eruption posted:

How viable will Coin be when it finally releases in Spring 2015?

I was thinking of canceling my preorder due to:
1) Apple pay is already out
2) all of my cards already have EMV chips
3) plenty of merchants are already requiring me to use the chip rather than swiping

If this was to release Spring 2014 as scheduled, it would've been pretty useful. But now with the dalay, I fear it's going to become a useless gadget.

Coin has nothing to do with Apple Pay. It is a different product and uses a contact mag stripe interface, so I'm not sure why Apple Pay influences your decision to cancel it. With that said, Coin, in it's current iteration, will work poorly in EMV readers. Your chip cards also have a mag stripe, but their mag stripes tell EMV capable terminals to try the chip interface. Therefore, Coin will not work for your chip cards in chip-capable readers. It will work for mag stripe only cards in chip-capable readers. Chip cards and readers will only become more popular as both parties will try to avoid liability for being the weakest link in the transaction chain with the upcoming liability shift.

Theoretically, Coin (and its smart card competitors like Plastc and Wallaby) could make use of a secure element and contact or contactless EMV interface in addition to mag stripe cloning. If the card has a secure element, it could provision EMV card credentials onto the secure element via the link it has with your phone. However, in order to do this, it would have to make use of the V/MA/AXP provisioning services. V/MA/AXP will likely not allow this to happen, because products like Coin hide all of the hard work that issuers do to make their cards stand out. It's a business question of branding - do you think Chase wants to see the Coin brand in front of the Sapphire brand or American Express wants to see Coin in front of Platinum? I don't think so. Plastc does a little bit more here (shows the various issuers on the card), but still not quite enough. Wallaby is the worst off of the group, since their promise is to route transactions to the card that maximizes your rewards for a given situation. Issuers hate this, because the entire goal of a card that gives 6% cash back on groceries is for you to use that card to buy not only groceries.

I would cancel your preorder. It's worth noting that most of these things are vaporware. Wallaby was announced in 2012 with no real product in sight even now.

SHISHKABOB posted:

My dad works in the credit card part of jp Morgan and chase, is that a part of the "payments industry".

Yes...?

Snuffman posted:

Forgive me, I don't have an iPhone 6 but I do live in Canada where chip+pin and tap n pay have been a "thing" for quite some time.

What's stopping Applepay from working in Canada, outside of the passbook support? As I understand it, US iPhone 6 users can happily ApplePay up here with no issues.

Issuers need to build some capabilities to support tokenization - it will take some time to get them on board. Additionally, Interac is huge in Canada. Typically, when Apple builds a product, they try to make its features work for as many people as possible (this is why they waited so long for 3G, LTE, NFC, etc.). It will be interesting to see if they try to get Interac on board with tokenization as well, which would be a serious undertaking.

Pissingintowind fucked around with this message at 09:02 on Oct 26, 2014

EugeneJ
Feb 5, 2012

by FactsAreUseless
If the U.S. adopts Chip and Signature on a widespread scale, isn't the signature requirement pointless since you can just scribble "Cockballs B. Esquire" on the pad and the transaction will still go through?

nougatmachine
May 19, 2011
In the last episode of https://atp.fm, one of the hosts (can't remember which) mentioned in an early experience using Apple Pay, he still had to sign his name after paying with the phone. Is that supposed to be an option as part of the process, or was this a case of a rogue (or improperly set up) merchant? If it is an acceptable option, is it temporary, or will it go away with time?

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

EugeneJ posted:

If the U.S. adopts Chip and Signature on a widespread scale, isn't the signature requirement pointless since you can just scribble "Cockballs B. Esquire" on the pad and the transaction will still go through?

Signature isn't so much about preventing fraud. It's an option because it offers less friction than a PIN and it doesn't have a requirement for a PIN-pad (was a bigger deal before PIN-pads became widespread). Lots of issuers and merchants prefer signature over PIN because, although it clearly not as secure, it prevents cart abandonment when someone cannot remember their PIN. Seems silly to you and me, but lost/stolen fraud (what PIN protects against) hasn't reached a level where it makes more sense to invest in the upgrade to PIN over just eating the fraud. It likely will make more sense when counterfeit card fraud (what chip protects against) goes away, and fraudsters change their focus to lost/stolen.

nougatmachine posted:

In the last episode of https://atp.fm, one of the hosts (can't remember which) mentioned in an early experience using Apple Pay, he still had to sign his name after paying with the phone. Is that supposed to be an option as part of the process, or was this a case of a rogue (or improperly set up) merchant? If it is an acceptable option, is it temporary, or will it go away with time?

Signature is typically required for transactions over $50 or if the merchant has not opted into the signature-free options available from the various networks (who all have different rules). All of the standard CVMs (PIN, Signature, and no CVM for small ticket transactions) can be used with Apple Pay.

PT6A
Jan 5, 2006

Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane
Why is there so much resistance to chip/pin technology in the States? At first in Canada, people were whiny about it and kept forgetting PINs, but the banks eventually said "tough titty" and now it's completely normal, to the point where it's jarring when I have to actually sign a receipt in the States (it's like seeing one of those old slide machine that works with the pre-printed credit slips).

Diabolik900
Mar 28, 2007

PT6A posted:

Why is there so much resistance to chip/pin technology in the States?

Out of curiosity, do you mean resistance from the general public or from the payment industry? Your statement about people whining about remembering PINs makes it sound to me like you mean the general public, in which case I'd say there isn't resistance to chip and pin because I don't think the average consumer in the US has even heard of chip and pin.

PT6A
Jan 5, 2006

Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Diabolik900 posted:

Out of curiosity, do you mean resistance from the general public or from the payment industry? Your statement about people whining about remembering PINs makes it sound to me like you mean the general public, in which case I'd say there isn't resistance to chip and pin because I don't think the average consumer in the US has even heard of chip and pin.

Well, there was also complaining about the cost of new PIN pads (especially wireless ones for restaurants and bars), but mainly I'm just curious why MasterCard, VISA and Amex haven't just said, "gently caress it, everyone's getting Chip+Pin now, and if you don't like it, go piss up a rope." It's available everywhere else I've been in the world except Cuba (where you're just lucky if a credit card works at all in any way).

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

PT6A posted:

Why is there so much resistance to chip/pin technology in the States? At first in Canada, people were whiny about it and kept forgetting PINs, but the banks eventually said "tough titty" and now it's completely normal, to the point where it's jarring when I have to actually sign a receipt in the States (it's like seeing one of those old slide machine that works with the pre-printed credit slips).

First of all, there are plenty of other non-PIN markets, especially in Latin America and Asia. Also, the US was never a high-fraud market in the past. The way that these type of improvements work is that it has to make financial sense to implement the upgrade. No smart for-profit companies are going to upgrade something out of the goodness of their hearts. Until recently, the cost of upgrading to chip (and signature) outweighed the benefits gained (getting rid of counterfeit card fraud). This is still the case for PIN, but will likely change in the near future as more fraud moves to the weakest link in the chain (away from counterfeit card fraud and towards lost/stolen fraud).

Below are things that have been complained about related to PIN adoption that have prevented implementation in the US:

Issuers:
Cost of back-end technology
Cost of support for cardholders that have forgotten their PINs
Forgone revenue due to cart abandonment (cardholders forgetting their PIN)

Networks:
Cost of back-end technology
Forgone revenue due to cart abandonment (cardholders forgetting their PIN)
Forgone revenue from predictive anti-fraud technology used without PINs

Acquirers:
Cost of back-end technology
Forgone revenue due to cart abandonment (cardholders forgetting their PIN)

Merchants:
Cost of new acceptance devices
Forgone revenue due to cart abandonment (cardholders forgetting their PIN)
Speed of transaction

Cardholders:
Forgetting PIN
Speed of transaction

Basically, since the default liability for card present fraud is with the issuer, issuers have to start complaining about the cost of handling lost/stolen fraud to initiate a change. This has not yet been the case, likely because it is cheaper for them to just eat the fraud than to upgrade all of their legacy systems. As soon as the balance tips the other way, things will change.

Worth noting is that in the US, we have far better legal protection against fraud than in other markets. If fraud occurs, you are not liable. Period. It can be a minor hassle to deal with, but I would personally rather have the legal protection than the technical protection. In some markets, if fraud occurs with a chip and PIN transaction, the cardholder is liable because the assumption is that they have been careless. Note that I am not saying that this will necessarily happen in the US, but just an interesting fact.

nougatmachine
May 19, 2011

Pissingintowind posted:

Signature is typically required for transactions over $50 or if the merchant has not opted into the signature-free options available from the various networks (who all have different rules). All of the standard CVMs (PIN, Signature, and no CVM for small ticket transactions) can be used with Apple Pay.

Is there at minimum a way for the terminals to have some kind of logic programmed that "hey, this purchase was authorized by Touch ID" and turn the signature requirement off for just that >$50 purchase? I guess I can understand the signature if you're paying with an Apple Watch (which has no Touch ID) or if you pay on a phone with your passcode (I'm not actually sure if this is an option as I don't have an iPhone 6, but I assume it's possible). But if you need to sign for all purchases over $50, no matter what, at a largish number of merchants, that negatively impacts the gee-whiz nature of Apple Pay quite a bit. I mean, if you're buying thousands of dollars of something, I don't think transaction speed is very important, but I regularly clear $50 when getting groceries. And if I'm going to need to authorize the purchase in a medium outside the phone anyway, I'd almost prefer to just be able to wave the phone at the NFC reader.

Pissingintowind
Jul 27, 2006
Better than shitting into a fan.

nougatmachine posted:

Is there at minimum a way for the terminals to have some kind of logic programmed that "hey, this purchase was authorized by Touch ID" and turn the signature requirement off for just that >$50 purchase? I guess I can understand the signature if you're paying with an Apple Watch (which has no Touch ID) or if you pay on a phone with your passcode (I'm not actually sure if this is an option as I don't have an iPhone 6, but I assume it's possible). But if you need to sign for all purchases over $50, no matter what, at a largish number of merchants, that negatively impacts the gee-whiz nature of Apple Pay quite a bit. I mean, if you're buying thousands of dollars of something, I don't think transaction speed is very important, but I regularly clear $50 when getting groceries. And if I'm going to need to authorize the purchase in a medium outside the phone anyway, I'd almost prefer to just be able to wave the phone at the NFC reader.

No, there isn't (for now). This is because nothing about Apple Pay's Touch ID is passed to the merchant, acquirer, network, or issuer. Touch ID functionality is not part of the payments ecosystem, it is just part of the Passbook application that Apple made. An Apple Pay transaction looks just like any other contactless transaction to the terminal.

The limit for no CVM is increased as predictive anti-fraud technology within the payments ecosystem is improved. It went from $25 to $50 for a few merchant categories most recently.

Lolcano Eruption
Oct 29, 2007
Volcano of LOL.
This is a more subjective question, but where do you see the payments industry heading in the next three to five years? Will we (the US) be far enough along so that we would not have to carry individual credit cards everywhere? Everyone is pretty tired of having to carry around multiple cards.

Right now, things are looking pretty bleak; with different stuff like CurrentC, Apple Pay, Google Wallet, each incompatible with one another. Do you think retailers and issuers will be able to cooperate enough to have a single unified solution?

Many small businesses use Square when they're just starting out. I'm sure they are concerned that chip & signature will be mandatory soon. Will Square and it's competitors be updated to allow small-time vendors to continue to accept credit cards once mag stripes get phased out?

Adbot
ADBOT LOVES YOU

EugeneJ
Feb 5, 2012

by FactsAreUseless
If I have 2 credit cards with chips, and they're both in my wallet, and I hold my wallet up to the reader...does the reader let me choose what card I want to use?

Wondering if the readers freak out when encountered with 2 chips at the same time, basically.

  • Locked thread