Comment by zaroth | Hacker News Reader

Comment by zaroth | Hacker News Reader

Walmart's Mike Cook asks an interesting question;

At a physical store, if you use any other mobile app, like LevelUp, then the merchant pays the higher 'card-not-present' rate. The same transaction with Apple Pay pays the lower 'card-present' rate. But an in-app purchase on an iPhone still charges the 'card-not-present' rate.

Visa's Jim McCarty's response is, "Fundamentally because the payload is different. One is a full EMV track read transaction and the other is not."

"Because it's a rule that y'all made?"

"No, because the data doesn't flow. It's why the standard was written like that." ... and then later Jim quips... "That's the first time Mike's complained about getting the card-present rate." which the moderator replies "OK, that gets the best answer beer."

The format of the packet is irrelevant. The security properties are derived from the user interaction points. Specifically, Alice loads her card into Apple Pay by taking a picture of it. A week later Alice uses her phone to pay with Apple Pay and the merchant would get a card-present rate. Can any other app do the same thing? Is there an open standard which allows LevelUp (who currently is forced to pay card-not-present) to use the same exact steps and get the same favorable rate? If not, I think Cook has a very valid point.

Apple Pay wins by default if they are the only mobile app in town which can get a card-present rate. I assume Google Wallet is card-not-present, for example. Merchants won't pay a higher rate so you can use some app. Jim McCarty specifically mentions the scale problem with changing brick & mortar merchants card-not-present rates.

According to this: http://www.quora.com/Is-Google-Wallet-considered-a-card-pres...

Google Wallet is card-present for the merchant, but card-not-present between Google and the consumer. I guess that means Google is eating the difference between the two rates (and/or has other tricks up their sleeve).

Apple Pay is like iBook to me. Apple making these grandiose claims about how much they are doing this for us. Yet there is this issue of Apple taking a cut while binding us the very credit card companies many of us find repugnant. I know, but its Apple!!! Well Apple condom or not, its still the same in the end, they sell us to the CC companies and we are supposed to be happy.

Check with my credit union, no plans though a CC I do have elsewhere does offer it.

As far as stores, I can see the issue with being bound to the higher payment structure CC require (in or out) compared to options they are developing as a group. I am not too pleased with privacy issues of their idea but its not like I appreciate my CC's privacy issues either

It's been some decades since the only option for a payment card was a line of revolving credit. You can get one that's tied to a deposit account, no chattel-slavery strings attached, and they sure are handy things to have.

(I don't love revolving credit any more than the next guy -- less, in fact; I've worked in the industry and seen its unloveliness firsthand. But you can get the benefit of a payment card without it.)

I would imagine that it is because brick and mortar merchants are a lower fraud risk than an online property. Don't forget that visa and MasterCard suck up fraud on both sides of the transaction.

Which is not to say that there aren't shenanigans going on, but there's a reason that consumers really like MasterCard and visa, they both look after customer interests, sometimes at the expense of merchants.

What kind of fraud is there to suck up at the merchant part of the transaction? Isn't it so that if the merchant doesn't deliver, they don't get paid?

In the EU, merchants have to pay for swipe card fraud. Let's say you buy something with a swipe card, scribble a signature on the receipt, then ring your bank few hours later saying that there is a transaction you don't recognize. Then your bank requests the receipt from the merchant, the signatures don't match = you get reimbursed full amount, the merchant has no money and no goods - because in EU it is the merchant's responsibility to check if the signatures match. If they don't, they didn't do their job properly, therefore they have to pay.

This is the reason why pretty much nobody accepts swipe cards in EU anymore - there's very few places which even have swipe terminals, it's all chip and pin. The couple times when my chip didn't work, the cashier had to key in the number of the card manually, because she didn't have a swipe terminal at the till.

MasterCard and Visa have the ability to put the full cost of fraud (including a fee for dealing with it) onto merchants in many/most cases. This includes "friendly fraud" of the false chargeback variety (customer falsely claims they did not receive a product) taking advantage of consumer protection guarantees offered by MasterCard and Visa to their customers as a value add.

IE, CC companies offer their customers consumer protection to encourage use of their product. They charge merchants when a consumer uses the product. Then, they unload the risks, costs and other burdens inherent in offering this add on service onto merchants as well. This is why they put little effort into investigating claims, making it feasible for merchants to dispute them or otherwise preventing fraudulent claims. It's has a distinct odor of oligopoly.

Oligopoly also allows for price setting. IE, the forces pushing the cost of a good or service closer to the (marginal) cost of producing it are weak. It could also be that "card present" is cheaper because in-store purchases have to compete with cash purchases. IE, they might be charging the higher fees because they can, not because they have to.

> One is a full EMV track read transaction and the other is not.

I don't see how that can be true; loading a card into Apple Pay is done via photo or manually, neither of which entails a swipe of the card through something like a Square reader, which is what would be necessary for Apple Pay to provide "full EMV track read" data. The information available via Apple Pay is therefore necessarily a proper subset of that encoded into the magstripe, which, according to the Visa rep's statement, should require that Apple Pay transactions be billed under the same card-not-present fee scheme as in-app purchases and online transactions.

Your argument from packet format is irrelevant; "user interaction points" don't enter into it, under the rules defined and promulgated by the card associations. Those rules include a distinction between card-present and card-not-present transactions, made on the basis of whether or not the transaction data includes a full and valid magstripe read. Apple Pay transactions cannot include such a read, because, based on the methods by which a card can be enrolled in Apple Pay by its user, the information available at transaction time cannot be other than a proper subset of what a magstripe read would provide.

It's understandable that WalMart's Cook should be cross over this; his irritation stems from the perception that "the fix is in" between Apple and the card associations, such that they're breaking their own rules to give preferential treatment to Apple Pay.

On the other hand, these are their rules; the conditions under which various transaction fee schemes apply are defined entirely by the card associations (Visa and MasterCard, et al.), and if they want to extend preferential treatment in this fashion, then it's entirely within their scope to do so.

In effect, the rule for a card-present transaction has been extended with a clause "...or if it's done by Apple Pay". This is a special case of a more general rule under which effectively all card association operations occur, and whose most concise formulation is "Because we say so."

>On the other hand, these are their rules; the conditions under which various transaction fee schemes apply are defined entirely by the card associations (Visa and MasterCard, et al.), and if they want to extend preferential treatment in this fashion, then it's entirely within their scope to do so.

And how is what Walmart accepts for payment in their own stores is not under Walmart's own scope?

Well, sure it is. But if Wal-Mart wants to use the card associations' infrastructure, then Wal-Mart has to play by the card associations' rules.

The whole point of "CurrentC", as I understand it, is to launch and build out a competing infrastructure which bypasses the card associations entirely, most especially their transaction fee schedules.

I can understand why merchants would want to do that; from the association perspective, there is absolutely no reason to do anything other than putting the entire cost of the transaction on the merchant, because asking the customer to pay into the scheme is a disincentive for using plastic at all -- which means that, from the merchant perspective, accepting plastic entails taking a bath on the transaction fees in exchange for not losing all the customers who won't do business at a cash-only till. Which, these days, is most of them, exclusive of special cases like a farmer's market or a flea market, where everybody expects to pay cash -- though, thanks to Square, Stripe, and friends, even that's changing.

(This, were you wondering, is the genesis both of the "credit card minimum $10" signs you see at shoestring gas stations, and the rule in the associations' merchant agreements which prohibits merchants from setting such minima. The sign comes about because transaction fees often mean a merchant loses money on very small credit card transactions, and the rule follows because merchants setting such minima costs the associations part of the fee income which they consider their due.)

It makes good sense, then, for merchants, especially big merchants like Wal-Mart who pay the associations more than anyone, to band together and try to launch a competitor to the existing scheme. Of course, it would help if they could show signs of being able to mount a serious challenge, and so far such signs are sorely lacking, which might explain some of the bitterness evident in Cook's mien on the subject.

Like it or not, though, the card associations are the 800-pound gorilla in the field; counting their predecessor organizations, they've spent over half a century establishing themselves, and to expect them to be anything other than fiercely protective of such investment would be foolish.

I'm not sure whether the people making decisions under the "MCX" banner have failed to recognize the scope of what they're trying to do, or whether they've simply failed to execute on a level sufficient to mount a credible challenge -- but, either way, they haven't done anything worth taking seriously, and I doubt they ever will. This leaves them with the same choice they've had for decades now: whether to go on paying a vig to the card associations, or instead to stop taking plastic and lose all the customers such a decision will entail. Sucks, sure, but, as ever, mere pissing and moaning changes nothing.

When you provision a card to Apple Pay by taking a photo of your card or entering the info manually, what happens next is that the iPhone makes a call to the card network (Visa/MC/Amex) to verify the card data (the card network will also make a call to the issuing bank of the card for a validity check), and if all is well, the network will return the same information that is effectively provisioned to physical ICC chips that you see in newer credit/debit cards. These parameters are stored in the iPhone 6's secure element, and allow the iPhone to perform full EMV transactions (as apposed to simply just EMV Legacy MSD transactions).

So it's sort of chip-and-PIN, with the secure element standing in for the former and the iPhone's existing authentication methods for the latter?

Yes - that's right.

Reply on news.ycombinator.com