7 ms·

I agree. I'm biased, but I think phone-based technology is clearly better. (I run http://www.facecash.com http://www.facecash.com)

Cushman 16y ago
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?
- hugh3 16y ago
  Downsides of your idea: 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.
  - thinkcomp 16y ago
    As much as I hate to link to a competitor, Cushman's idea is similar to what Cimbal is doing: http://www.cimbal.com http://www.cimbal.com 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. 5. It's the same speed as credit cards or faster.
    - hugh3 16y ago
      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?
      - thinkcomp 16y ago
        The phone lets you do a lot of things paper (but mostly plastic) can't. Some we've released... - Standardized electronic receipts with line item data available in real-time - Instant and free peer-to-peer money transfers (you can use Bump) - Set the tip on the phone when you're at a restaurant - Storing multiple account numbers for frequent flier programs, insurance companies, school IDs, etc. ...and some we're still working on... - Bill splitting - Location based offers (coupons), automatically-applied when you pay So there are a bunch of advantages to using the phone.
      - mkramlich 16y ago
        > This is the first I've heard of your product, but I agree it does solve all the problems I mentioned. That is what every startup founder wants to hear. :)
- 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.

Cushman 16y ago

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?

hugh3 16y ago
Downsides of your idea: 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.
- thinkcomp 16y ago
  As much as I hate to link to a competitor, Cushman's idea is similar to what Cimbal is doing: http://www.cimbal.com http://www.cimbal.com 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. 5. It's the same speed as credit cards or faster.
  - hugh3 16y ago
    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?
    - thinkcomp 16y ago
      The phone lets you do a lot of things paper (but mostly plastic) can't. Some we've released... - Standardized electronic receipts with line item data available in real-time - Instant and free peer-to-peer money transfers (you can use Bump) - Set the tip on the phone when you're at a restaurant - Storing multiple account numbers for frequent flier programs, insurance companies, school IDs, etc. ...and some we're still working on... - Bill splitting - Location based offers (coupons), automatically-applied when you pay So there are a bunch of advantages to using the phone.
    - mkramlich 16y ago
      > This is the first I've heard of your product, but I agree it does solve all the problems I mentioned. That is what every startup founder wants to hear. :)
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.