4 ms·
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 t
by thinkcomp 16y ago
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:
http://securevaultpayments.com http://securevaultpayments.com
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.
- Cushman 16y ago"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.
- thinkcomp 16y agoIf 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.
- Cushman 16y agoReally? 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.
- thinkcomp 16y agoThere 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!
- Cushman 16y agoI'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?
- Someone 16y ago"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?