payments: I’ve a phone and a credit card. why? 2
Here’s part 2 of our look at payments that I began in my previous post. Let’s look at specific situations…
Imagine that moment we all dread. That tap of the pocket, or reach into the handbag and you realise that something’s missing. Your heart sinks. Which is worse, losing your cards or your phone?
I’m guessing that most people would say their cards. A phone can be bought anywhere. You may have a spare at home. But credit cards. Lose them, its a nightmare. Phone your bank or provider. Stop the cards. Order new ones. Change all your web retailer details. The list is endless. Ugh!
But a phone. Well, you just order a new SIM. That comes next day usually. So I guess the phone is less hastle, down the line. Pardon the pun… OK. That’s it for this episode!
on February 3rd, 2010 at 12:53 pm
Ahh, I have spotted a flaw in your logic lanZen. If you are talking about contaless systems like Oyster then the phone cannot simply be replaced with any other handset because of the chip it has inside. Getting that sorted out would be a hassle. Have I blown your argument?
on February 3rd, 2010 at 1:15 pm
Hi, Dave,
Nice try, but no. I’m not talking about Oyster or any embedded technology. That’s just too much trouble. And for “trouble” in this context, read added cost and inertia to adopt, corporate heal dragging, etc. Think Cloud…
on February 3rd, 2010 at 7:14 pm
How come you’re worried about losing this before you’ve even worked out the details of if its worth doing. Bit premature are we?
on February 3rd, 2010 at 7:34 pm
No, Geoff, I don’t feel this is premature. But thanks for throwing this in, because its a valid question.
One of the real dangers of producing or supporting an idea is in falling in love with the technology or the philosophy behind it, without considering its place in the scheme of things. So what do I mean by that?
Well, here I’d have to put a marketers hat on and say “choose an existing market, don’t try to invent a new one”. In other words, address a need, don’t try to build a requirement.
That means work out what’s being replaced, what the downside of the old technology is and whether what you’re proposing offers a significant improvement. If it is and you can defend it on all fronts, go ahead and pitch it. Embrace every negative and address everything. Don’t be caught out. People have a longer memory for screw-ups than they do for success stories!
At some stage, some exec sponsor or investor is going to have to fight your corner. Don’t embarrass them by not covering all the bases.
Also, its good to have a great story to tell so they can visualise the advantages!
Does that make sense?
on February 4th, 2010 at 12:47 pm
I was just wondering what the authentication / transaction protocol sequence might be e.g. x.509 style, and also how this might work in terms of say buying something off the Internet or even paying by phone?
on February 4th, 2010 at 9:15 pm
As an addendum (I hate the lack of editing capability in Blogs)
I am positive about your idea and it could be implemented in many ways and operate at a number of levels.
A next step might be for someone to develop a series of ‘Use-Cases’.
What I am getting at is, is this an ‘integration’ to an existing mechanism or a replacement?
Surprised people like MBNA, VISA or the phone companies are not already thinking about things like this, I do not really know, I am just a user in this context.
Depending on how it is done technically, there could be an opportunity to improve security over existing mechanisms?
Just some thoughts.
on February 4th, 2010 at 10:45 pm
Hi, Stephen, thanks for contributing to this post, your views are really helpful and take the discussion down an interesting path.
The idea as I unfold it further will hopefully start to make more sense. Your question about one-way certified encryption (x.509) is a good one, but if I can get this right, might not be applicable.
You see, the problem the existing card providers face is one of their own making and common to most of the security industry. Its their obsession with endpoints.
Pre-Internet, they got away with it because endpoints were limited and therefore (fairly) manageable. But as we discover new ways of accessing systems, I feel trying to protect an ever expanding array of endpoints is fruitless and ultimately a self defeating exercise.
This view formed the basis of two posts I did a while ago. Back in 2007 in fact. The Porous Castle and The Shapeless Perimeter.
So I’m talking about assuming all endpoints are insecure and securely the data core itself – which is the ultimate destination for any attack in the first place!
I’m in danger of making this longer than a post, so I’ll close by saying this.
The idea is not to bolt onto an existing infrastructure already so expensive that card interest rates place huge debt burdens on users. The idea is to move to a central payment portal to manage the flow of funds between provider and retailer, leaving the user (the endpoint) to just ask for a payment to be made.
Because that’s fairly trivial and therefore much cheaper and easier to design!