It's a step in the right direction, but (please correct me if I'm wrong) your system still seems to be merchant-initiated. I'm using my phone as a glorified piece of paper; the merchant scans my barcode and processes the transaction on their hardware, the same way they would with plastic.
That still seems ridiculous when my phone itself is a device capable of handling the transaction, yes? I should be scanning the register's barcode. I should be able to see what I'm paying for on my phone as it rings up. I should be able to authorize the payment using whatever securities I want on hardware that I own. I should be able to complete the entire transaction and walk out of the store without ever giving the merchant any information besides what bank I use.
All of that is completely possible with today's tech. Who decided that the future of electronic payment is a debit card in a different form factor?
1. Not everyone has, or wants, a smartphone. My phone doesn't even have a camera. People who work in certain high-security environments aren't even allowed to own phones with cameras.
2. Supposing hypothetically that I'm gonna have to "upgrade" to a smartphone at some stage, do I want to carry it around all the time? I always take my wallet, but I don't always take my phone. A phone is a much larger, heavier thing to carry around than a credit card.
3. When I do have my phone with me, it always seems to run out of batteries at an inconvenient time. I'd hate for the "completely uncontactable" problem to be compounded by the "you don't have any money" problem.
4. What happens when my phone (which I am now forced to carry around all the time and religiously keep charged) gets stolen? What authentication system proves that the person holding the phone and scanning the register is actually me? There's always "Enter your pin..." but that brings me to the next problem:
5. People paying with credit cards is slow enough already... I think your system would probably slow transactions down even more.
Anyway, to me it seems you're trading in a small, light system that works adequately for a heavy, bulky one that may be less secure.
Assuming for the moment that by some bizarre turn of events my system were implemented...
1. Why is this a problem? Obviously legacy systems will have to stay in place until smartphone adoption is as ubiquitous as credit cards are today, and the only person you're inconveniencing by using them instead is yourself.
2. My iPhone is smaller than my wallet, and is more indispensable for travel (and would be vastly moreso if I could use it for even a small portion of payments.) I guess this one is just a culture difference, but it looks like the world is moving my way.
3. In keeping with the above, you could still carry around your debit card if you want the backup. (Your phone could even act as a passive RFID backup, so you don't have to carry around the card.) But since it wouldn't be your primary method of payment, you would be able to up the security on it such that every payment must be signed for, and signatures actually validated. A bit kludgy, but that's how it is supporting legacy technologies.
4. What happens right now if your debit card is stolen? Except without the "Enter PIN" part.
But seriously, since this technology is customer-initiated, the security of it will continue to improve as security features on phones improve. Whatever my new phone supports — fingerprint, face recognition, geolocation — I can use to authorize payments, and the merchant never has to worry about it.
5. There's a tradeoff between security and speed, here as in all things. Maybe this system would wind up being a little slower than our current one, which provides almost no security... I guess that's a fair tradeoff for me. After spending 20 minutes finding my groceries, whether it takes me five seconds or 45 to authorize the payment isn't a big deal. And as smartphones improve, it will get faster and faster.
Anyway, if you think what I'm proposing is the heavier, bulkier, or less secure option, I'm not sure if you've thought about what a debit card transaction actually entails.
Cimbal has all of the same downsides you describe here (and more--it's only on iPhone and no merchants accept it). FaceCash, which uses a consumer-side 1D barcode rather than a merchant-side 2D barcode, solves all of them.
1. We let you print your barcode (like a boarding pass) on a piece of paper that you can cut to business-card size so you can carry it with you in your wallet. No phone required, which also means no cameraphone required.
2. See 1.
3. See 1.
4. Your account is linked to an image of your face that shows up on the register whenever it's used, and it's pretty unlikely that a random phone thief will be mistaken for you.
This is the first I've heard of your product, but I agree it does solve all the problems I mentioned.
I'm actually curious as to what the point of the phone-based side of your product is, then... surely pulling a barcode out of my wallet is quicker than loading up the facecash app on my phone?
Your idea sounds great from a consumer perspective, and it's an absolute nightmare from the merchant's perspective. Merchants have a lot more money sitting in their bank accounts (on average) than consumers. The last thing they want is everyone knowing their account numbers.
Besides, the issue of who scans whose barcode is a red herring. Either way, the barcode (or RFID signal, or bluetooth signal, or whatever) establishes a bi-directional transaction, and at some point your account number will be transmitted to the merchant. How else would they know whose account to debit?
If you are simply suggesting using your bank as a proxy to hide that number, then you should look at NACHA's SVP:
No one uses it because the general problem of security isn't totally solved by introducing the bank as a proxy, and may actually just put more accounts at risk depending on the implementation because the bank has to be that much more open with the API.
You can see what you've paid for on your phone after it rings up with our system, which no other system lets you do. As it rings up, why not just look at the register?
Until consumers foot the bill for merchants' IT projects, I'm afraid what you're talking about just won't happen.
"How else would they know whose account to debit?"
I hate to pull a single sentence out of context like that, but this misunderstanding is exactly the problem with the current system. Why should the merchant be debiting my account?
When you write someone a check, do you sign it blank, hand it to them, and then make sure they wrote in the right thing when it shows up on your statement? When you pay in cash, do you hand over your wallet, let the cashier remove the appropriate number of bills, and then look to see how much they took? That's what you're doing every time you use your debit card.
The reason we do it that way is because it's attached to this legacy system of what used to be literally credit cards. I* would purchase something "on credit", handing over my card so that the merchant knew I was vouched for by a reliable creditor. They would copy down the number and bill my creditor for the money later.
It almost makes sense for that kind of relationship. Debit cards were the first misstep, but at the time it was necessary to get around the logistical nightmare of checking my exact balance and debiting my account on every transaction. But now we're moving on to personal computers, and for some reason if I want to pay someone I still need to give them my bank account details. That's dumb and broken, and I can not believe that telling my bank to deposit an amount of money into someone else's account instead is a massive logistical hassle for retailers.
*I was born long after it stopped working this way, of course.
>But now we're moving on to personal computers, and for some reason if I want to pay someone I still need to give them my bank account details.
For what it's worth, paying bills in Europe works with the Giro system (http://en.wikipedia.org/wiki/Giro) which is the opposite of the US system. When a company wants me to pay a bill, they give me their giro number and an invoice number, and I deposit money in their giro account. They never get to know my bank account number, and I never get to know theirs.
I just came home from eating out, and the restaurant had a portable chip&pin reader, which is increasingly common. The waiter enters the amount in the reader, gives it to me, I insert my card, enter additional tip, enter my pin code, press ok, take my card, and hand the thing back to the waiter. We both get a receipt, and the restaurant gets my money without ever knowing my card details. It sort of solves the underlying problem.
the restaurant gets my money without ever knowing my card details
It's still their hardware.
I think what Cushman wants is for the merchant to present the customer with a QR Code, the customer scans this with their device and registers a transaction with their bank (possibly adding tip, etc). There are at several ways for the merchant to confirm the payment including notification from their bank, notification from the customer's bank, and notification from the customer's bank returned to the customer's phone (which the merchant could trivially scan and authenticate).
But yes, there is still an attack vector there, and I agree that the best solution is one where the business owner gives me payment details, I complete the transaction using my own hardware, and they verify it using theirs.
I have a hard time seeing a solution built on smartphones gaining widespread adoption though.
That's true, but I think that's the smaller problem. Owning and using hardware built for fraud (presumably banks ordinarily provide merchants with the real ones) would be a serious crime that only outright criminals commit. With credit cards you need to worry about the marginal criminals.
If you credit the merchant's account, then your account will be debited by someone, by definition, whether it's your own bank on behalf of the merchant or the merchant itself. Whether or not you authorize one side or the other first is pretty much irrelevant because the other will happen very soon (usually milliseconds) after. Either way, someone will need to keep track of the numbers. I think you're making a big deal out of what to me seems to be the least broken part of the payment system.
Really? You can't see the practical difference between these two flows?
The Way It Obviously Should Work:
Me -> my bank: I want to pay this store $10. Here's my password.
My bank -> the store: Here's $10 from Cushman.
The store -> me: We've got the money. Here's your stuff.
The Way It Does Work:
Me -> the store: I want to pay you $10. Here's my password.
The store -> my bank: Cushman wants to pay me $10. Here's his password.
My bank -> the store: Sounds good to me, here's $10.
The store -> me: We've got the money. Here's your stuff. And I promise I didn't save your password or anything.
I'm obviously not an expert in this stuff at all, so I don't know how broken that is in economic terms, but it's obviously broken.
There are no passwords transmitted in the banking system at the level you're talking about. Your PIN is never transmitted whether you're using credit card fund capture, ACH for debit purposes across banks, or on-us transfers within banks. Your web password is entirely irrelevant to all of this.
If things worked the way you think they do, I'd agree they're broken--but they don't work that way!
I'm not talking about a web password. (And I obviously know more about what I'm talking about than that— come on.)
When I pay with a credit card, every piece of information used for the transaction (Name, card number, whatever else) is stored on the magnetic stripe of the card. That set of information — the information needed to convince my bank to send you money — is what I'm referring to as my "password", and that password is given by me to the merchant for every single credit card transaction.
I'll admit I don't know how the debit infrastructure works, but I do know that I must enter my PIN on a pad owned by the merchant. That is transmission, and it's completely out of my control.
Aside from naming, how does the system not work the way I think it does?
It's not out of your control. Just don't use it if you don't like it.
I really don't see the problem that you're talking about. When you pay with a credit card, nothing happens with your bank at all. You pay your bill by check or on-line 20 to 30 days later, and only then does your bank get involved because you told it to. When you pay with a debit card, your bank is informed that you have authorized a fixed amount to be withdrawn. You could also do that through a bank web site or by writing a check, which has your account number on it. Not that much different, really.
"When you pay with a debit card, your bank is informed that you have authorized a fixed amount to be withdrawn."
See that passive voice hiding the problem: The bank is informed by the payee that I've authorized the transaction. I think it would make more sense for me (as the owner of the money) to do that.
It is a huge problem hidden by the fact that we have been getting around it for so long. These are the worst sort of problems to recognize because their cost doesn't manifest directly (merchants steal money) but in various costs incurred to prevent it.
- Consumers are picky about who they give their cc to online. They sometimes buy from second best sources due to these concerns. This also favours the established players at the expense of innovation.
- Banks/CC companies always favour consumers and always chargeback merchants for alleged fraud. This means merchants are careful who they sell to. They spend resources vetting clients (I had a client that sold phones who called every client to confirm orders - this is not abnormal). They don't sell to marginal customers (the margin is often 'outside the country'). This hurts merchants and consumers.
- Banks/CC companies spend lots of resources dealing with & preventing fraud. This manifests in higher processing fees & higher interest rates. This hurts consumers and merchants.
"Merchants have a lot more money sitting in their bank accounts (on average) than consumers. The last thing they want is everyone knowing their account numbers."
Why would they? The only thing anybody could use that information for is for sending them money. Here in the Netherlands, those account numbers normally are on the company letterheads. Is that different elsewhere?
That still seems ridiculous when my phone itself is a device capable of handling the transaction, yes? I should be scanning the register's barcode. I should be able to see what I'm paying for on my phone as it rings up. I should be able to authorize the payment using whatever securities I want on hardware that I own. I should be able to complete the entire transaction and walk out of the store without ever giving the merchant any information besides what bank I use.
All of that is completely possible with today's tech. Who decided that the future of electronic payment is a debit card in a different form factor?