Hacker News Reader

> possession of credit card data amounts to permission to charge any arbitrary amount to it

The word you're looking for is "capability", not permission. Permission requires consent, which is something you give separately from the actual card number.

A minor point, but I think it changes the tone of that statement.

> possession of credit card data amounts to the capability to charge any arbitrary amount to it

I'm not sure anyone is ignorant of this fact though, and yet everyone seems OK with it.

> Not only should future payment systems be based on cryptography, but they should also require an affirmative step on the part of the payer to initiate a given transaction of a given amount. In other words, it shouldn't be a matter of handing over your card number, or even a one-use cryptographic token, and letting the merchant fill in the details. You should have to explicitly send an amount of money that you specify. Then, of course, a smart merchant would verify that the amount is correct before fulfilling her end of the bargain.

Ugh, no thanks. The system you describe is more like cash. I have to actively dole out the necessary amount, and then receive change that is counted at each transition. I abhor these types of transactions.

Convenience is a significant motivator in the adoption of credit cards. Any competing system will have to compete on simplicity. The fact that consumers and merchants haven't fled from credit card use as fraud rates (and costs) have increased is evidence that the market is willing to bear them.

The legislative changes that allow merchants to charge a CC-use surcharge will resolve the significant matter of ignorance. I do agree that consumers are largely ignorant of the hidden costs of fraud associated with the current CC model. The question is whether they'll pay these costs once they're brought to light. I believe they will continue to pay them in exchange for convenience.

Ugh, no thanks. The system you describe is more like cash. I have to actively dole out the necessary amount, and then receive change that is counted at each transition. I abhor these types of transactions.

Not in this case. There's no reason the merchant can't send a request for a specific amount, encrypted using your credit account's public key and signed by their private key. Your credit authorizing device (smartphone, desktop app, phone call, whatever) then asks you to confirm the amount, and that amount is sent back to the merchant. I'm sure there's some way of cryptographically tying the request for funds to the transmission of funds so that it's clear what transaction the funds are for, that the amount sent matches the amount requested, etc.

Aren't you basically describing the "Request Money" feature of PayPal?

No, because that only works through PayPal. This is more about a system that can be automated independently of the bank or service provider and provides independent cryptographic verification of transactions.

Yes, but imagine you can use it at the grocery store or a restaurant. Also, PayPal has a questionable reputation, so I wouldn't want to rely on them for all my day-to-day transactions.

Yes, capability is a fine word for this. I'd say the practical consequences are still exactly the same, regardless of the label.

Ugh, no thanks. The system you describe is more like cash. I have to actively dole out the necessary amount, and then receive change that is counted at each transition. I abhor these types of transactions.

Not as I imagine it. I think the merchant would be able to set up a transaction, and the consumer would have to take a minimal step to approve it.

Also, if this system would annoy you, I'd be fine with allowing individual consumers to opt out of it. Personally, I would absolutely opt in.

The fact that consumers and merchants haven't fled from credit card use as fraud rates (and costs) have increased is evidence that the market is willing to bear them.

Partially. But this fact can also be attributed in large part to the major barriers to entry.

Heck, why not let users create a whitelist of trusted businesses? Best of both worlds.

That would be great.

I used to work in the credit card space, and what I witnessed is that the industry is adamantly opposed to anything they perceive as inconveniencing customers, at least at point of sale where they are competing with cash. In fact, Visa and Mastercard explicitly don't allow stores to ask for an ID with card purchases. This is why anything that requires effort from the cardholder won't happen soon.

Fortunately the anti-fraud solutions out there are pretty effective, which helps control the damage a stolen card can do.

Fortunately the anti-fraud solutions out there are pretty effective, which helps control the damage a stolen card can do.

In my experience, not reliably. For example, I've known people who gave their credit card info to a seemingly legit company, which then proceeded to make monthly debits without authorization, and this went on indefinitely. The credit card company was unwilling to intervene, and said it had to be worked out with the merchant.

That may sound surprising to you, because you're aware of chargebacks and other checks and balances. However, for some reason or another, none of that helped the victims in these cases. It's little consolation to them to say that "in theory, there are mechanisms in place to prevent this kind of abuse."

But "pushing" has proven to be problematic for US consumers. They've basically traded the 5 or 10 basis points of fraud losses for a substantially better user experience (although they didn't really get to make that tradeoff decision).

If I could save .5% a transactin by looking at thr transaction cost on the card and then physically clicking ok I would probably do so. The problem is I have no choice one way or another.

If the true costs of fraud are 5-10 basis points, suggesting that we eliminate fraud by replacing that with a 50 basis point drain on the system seems unlikely to succeed.

Most likely that was a mental arithmetic error or he thought that 1 bp = 0.1%, but changing it from 0.5% back to 0.05% back really changes the utility. If your average CC transaction is $100, you're breaking even compared to picking up a nickel. I'd rather get on with my day then stand there waiting for the authorization or picking up a nickel.

http://www.nasdaq.com/article/skimming-threatens-debit-card-... says fraud "in 1% of transactions".

I don't know whether those transactions tend to be larger or smaller than average. I'd assume the detection systems are quite good, and crooks start with small charges (gas stations and shoes are what I hear are test spots they use). So they may be pretty close to average sized transactions.

You wouldn't save that money.

The kind of work that would require would be on the order of hundreds of millions of dollars of work, an entirely new infrastructure, and massive retraining. The return on investment is a very long term issue.

I currently work in the sector, so can't say too much about it, but the problem is that it's a hard problem at scale.

I don't think that consumers are aware of what they traded to get that convenience, though. Card companies have gone to great lengths to keep the costs hidden. They've even lobbied (so far, unsucessfully) to prevent merchants from charging extra for card transactions, which would make those costs all but invisible.

Anecdotally, I know that I'm much more hesitant to whip out my card for that burrito when they added a $.45 convenience charge. I still use the card sometimes, but that one charge is enough to make me keep cash on hand. I wonder whether people would pay for the convenience if the true cost of it were more visible.

I agree with your solution of an affirmative step. I can see internet credit/debit card transactions moving towards a "request for funds" model where the consumer(via smartphone) has to explicitly ok the transfer of funds:

Merchant - (RFF) -> Bank - (prompts for auth) -> Consumer - (grants auth) -> Bank - (RFF granted) -> Merchant

Of course, smartphones are still potentially insecure, another more cumbersome model could revolve around challenge-response codes - where the customer has an offline digital code card:

[Merchant - (RFF) -> Bank - ($challenge) -> Merchant -($challenge) -> Consumer(punches in challenge code) - ($response) -> Merchant - ($challenge$response) -> Bank - (auth) -> Merchant

You've just described ARQC EMV card payments.

After having a cursory glance through the ARQC EMV wiki entry, it seems that EMV corresponds to what we currently have in Europe -> the same (consumer) PIN is still going to be re-entered in every transaction i.e. it's re-useable and can be easily captured(camera/eyeball) for later use at POS/ATM

Correct, it also describes your first flow; the only thing different is that the authentication is done through the merchant's PIN pad rather than a code sent through the cell network. In other words, providing the PIN unlocks the card, which serves as your authorization to dispense funds.

IIRC the card signs the merchant's request for funds once the PIN has been validated by the chip on the card, then sends it to the bank. I don't think there's anything in the standard that would preclude having one time PIN codes(the PIN validation is done by the chip, so you could just have a different app that does more than check a single PIN code), but the chip in the card itself doesn't have network access.

If you really wanted to have online authorization through the cell network, you could hold the processing of the AQRC message until it is verified through SMS (which can take several minutes for delivery and is best effort). However, that would hold the card reader unusable until the authorization is granted, as the card needs to stay in the terminal until the transaction is complete.

This obviously disregards offline processing (ie. card terminals that are not always connected to the network) and CNP transactions. For those, verification through another channel would be much more realistic.

The system that I think you are describing is already out there. I can’t speak for other countries but here in the Netherlands, the banks have standardised on “iDEAL”.

When you’re on a website and want to make a payment, the site makes a request to the bank, which then presents you with whatever method of authentication your bank uses. Generally this is some two-factor system. After giving the OK, you’re redirect back to the merchant.

Actually, it would seem to me that PayPal is very similar.

For retail POS transactions, EMV (chip+pin) cards and terminal are an attempt to shift this balance. Unfortunately, the rollout isn't due for another couple of years yet in the USA, and there has been significant resistance to the change already (as demonstrated by the 10 year lag when compared to the EU rollout).

There are many use cases when pulling money is more convenient for the consumer. This is how most people pay their bills for example - they let providers deduct a different sum every month based on usage. There's a lot of value in being able to simply "set it and forget it"

Agreed. I think consumers should be allowed to explicitly enable that for certain merchants, and perhaps set some kind of limit on how much can be debited.

So you do this for a handful of companies (the electric company, the gas company, etc), and for everything else, you use the push model.

Dwolla's entire network is based on pushing the transaction rather than pulling. You can send request, but ultimately the money doesn't move until send it with your pin.