Mobile Payments

hubba_bubba

Hello all,

With the rise of the Smartphone over the past few years a number of opportunities for entrepreneurial innovation have emerged.

M-Commerce and mobile payments is something that has begun to be talked about a lot recently. I had an idea about a year ago to create an app that would allow consumers order products in advance and pay for them on their smartphone and then simply walk in to a store and collect it without the hassle of waiting in line. I thought to myself that a company like Square would just come along and do something like that very soon and the idea just filtered to the back of my mind.

A year on though and in taking Dublin city as an example I am not aware of any stores where I can use my phone to pay for goods/services.

I now have an idea I want to pursue. I'd love to set up a coffee shop somewhere in the city that would be coupled with a smartphone app. Consumers could order and pay in advance using their smartphone and pick up their order in the store in a matter of seconds.

Obviously a good location would be key especially for morning foot traffic.

What do people think? Would this be something you would find useful/convenient/time saving?

Any comments, advice and constructive criticism welcome.

minibear

I would imagine that it might impact on the impulse purchase of the extras, like muffins that people didn't know they wanted until they get their coffee!

Axwell

Starbucks already do this in the states as far as I know, dont know about here. You top up your account, swipe at the counter and off you go. You can also preorder as far as I know and just go in and collect. Id say check online as someone was only telling me about it last week.

Gloomtastic!

Article about an app called Little Deli in today's SBP Money section. It's for pre-ordering lunch but you might get some useful info from it.....

hubba_bubba

Thanks for all the responses so far, all info and opinions are much appreciated.

minibear wrote: »

I would imagine that it might impact on the impulse purchase of the extras, like muffins that people didn't know they wanted until they get their coffee!

Hi minibear, yes I agree and I should have mentioned that the app would include such items like muffins, pasteries, herbal teas and the majority of items being sold so that the consumer could order what they want and have it all ready for them when they arrive

Axwell wrote: »

Starbucks already do this in the states as far as I know, dont know about here. You top up your account, swipe at the counter and off you go. You can also preorder as far as I know and just go in and collect. Id say check online as someone was only telling me about it last week.

Hi Axwell, Yes Starbucks are doing this and have in fact recently announced that 14% of ALL US sales comes from mobile purchases. However from my research to date I believe that they do not have an option to Pre order their coffee and pay for it before they arrive in store. You can as you said top up your account using coupon codes but when actually collecting your coffee you pay on the spot by scanning your phone.

With my idea I want the consumer to be able to have their order paid for before they walk into the store

Gloomtastic! wrote: »

Article about an app called Little Deli in today's SBP Money section. It's for pre-ordering lunch but you might get some useful info from it.....

Hi Gloomtastic, I actually saw the article just before I read your response . It is quite interesting and she seems to be solving a fair problem. She currently operates in Belfast and I feel that there is a great opportunity for something like this in Dublin.

Thank you all again for the replies they are much appreciated

Graham

For a couple of reasons I'm not convinced an app like this would work for purchasing coffee.

The bottleneck in a coffee shop is rarely at the till, it's usually with the Baristas while you wait for your drink to be prepared.

If the coffee is being made in advance for you (unless you can estimate your arrival at the coffee shop to an accuracy of a couple of minutes) you're likely to arrive to either find your coffee hasn't been made yet or it's even less tepid than usual.

This idea may work better for other products that wouldn't be so temperature sensitive. E.g. sandwiches for lunch. You could incentivise customers to place their orders earlier in the morning (perhaps reminding them while they're collecting their early coffee) and have them ready for collection at lunch time. That's a win-win for the establishment as it spreads out the peak lunch workloads as well as streamlining the lunch run for you average customer.

The Corinthian

OK, so, I've been intermittently involved in the development of so-called m-commerce for the last 15 years, so it might help if you first understand some of the background there.

Around 1999 - 2000, a few WAP based solutions appeared, typically wallet applications. None took off - too complicated and, let's face it, they used WAP.

In 2002, we got premium SMS and suddenly the industry was heralding the arrival of mobile micro-payments. Then the operators released the revenue shares, not to mention running costs and conditions, for the short codes and this knocked this option on the head, unless you were overcharging desperately or just scamming the consumer.

Smartphones came in and eventually in-app purchases were introduced. Problem is that while the operators have lost control of the market, the app-stores have simply replaced them and while far more viable than the PSMS revenue shares, at 30%, that's a cut that's way above anything available in e-commerce and there are few products or services that won't be priced out of the market trying to cover that overhead.

So m-commerce, has yet to take off partially because of technological reasons, but much of the reason is political - everyone, the operators, banks, phone manufacturers and now the app stores have at some stage tried to control this market, resulting in no solution ever getting wide acceptance.

Your options at present are probably limited to the following:

NFC Solution. Users can buy credit, which is then updated using an 'admin' app running on an Internet connected and NFC enabled smartphone or tablet. They can purchase by swiping said 'admin' device (with their Internet connected and NFC enabled smartphone), running a publicly available app, which then checks their account and if they've enough credit, deducts the amount accordingly.

The advantage of this is that you don't pay anyone anything. Disadvantage is that unless you can find a suitable third-party solution, you'll have to build it and will be responsible (i.e. legally liable) for anything going wrong.

Additionally, such an app is strictly speaking against the T&S of iTunes/Play (you're not allowed to circumvent their payment systems, which this would be doing), so you could find yourself banned from them - although this has never happened to date AFAIK, so consider this more a caveat than a dealbreaker.

This is the approach taken, more or less, by Starbucks, as well as a number of other companies/organizations (e.g. Dubai Roads and Transport Authority).

Payment Gateways. Some, such as Paypal, are already allowing people to pay via phone with their apps. Only disadvantage is that they're only allowing people in certain countries (i.e. North America) to do so. Google also offer API's to allow something similar through their Wallet platform.

If available, you're still paying the payment provider, which could be as high as 30% (I'm not current with rates, I'm afraid).

Graham wrote: »

For a couple of reasons I'm not convinced an app like this would work for purchasing coffee.

The bottleneck in a coffee shop is rarely at the till, it's usually with the Baristas while you wait for your drink to be prepared.

If you limit it to being a payment system, I'd agree with you, but - in the case of Starbucks - it also acts as a loyalty card.

hubba_bubba

Graham wrote: »

For a couple of reasons I'm not convinced an app like this would work for purchasing coffee.

The bottleneck in a coffee shop is rarely at the till, it's usually with the Baristas while you wait for your drink to be prepared.

If the coffee is being made in advance for you (unless you can estimate your arrival at the coffee shop to an accuracy of a couple of minutes) you're likely to arrive to either find your coffee hasn't been made yet or it's even less tepid than usual.

This idea may work better for other products that wouldn't be so temperature sensitive. E.g. sandwiches for lunch. You could incentivise customers to place their orders earlier in the morning (perhaps reminding them while they're collecting their early coffee) and have them ready for collection at lunch time. That's a win-win for the establishment as it spreads out the peak lunch workloads as well as streamlining the lunch run for you average customer.

Hi Graham, thanks for the reply. Yes you are correct about the element of timing and getting it correct. I think however, that I have a way in which this could be refined and work very well and is at the discretion of the consumer. You are right though, getting this element right is key to the success of this whole model of purchasing.

The little deli app mentioned above is focusing on sandwiches and lunches like you suggested. However it currently only operates in the Belfast area and it's arrival date to Dublin is still as of yet unknown.

I'm starting to think that the technology part of this idea might be worth focusing on more and then licence it out to other businesses to use such as cafe's, deli's and so on.

The Corinthian wrote: »

OK, so, I've been intermittently involved in the development of so-called m-commerce for the last 15 years, so it might help if you first understand some of the background there.

Around 1999 - 2000, a few WAP based solutions appeared, typically wallet applications. None took off - too complicated and, let's face it, they used WAP.

In 2002, we got premium SMS and suddenly the industry was heralding the arrival of mobile micro-payments. Then the operators released the revenue shares, not to mention running costs and conditions, for the short codes and this knocked this option on the head, unless you were overcharging desperately or just scamming the consumer.

Smartphones came in and eventually in-app purchases were introduced. Problem is that while the operators have lost control of the market, the app-stores have simply replaced them and while far more viable than the PSMS revenue shares, at 30%, that's a cut that's way above anything available in e-commerce and there are few products or services that won't be priced out of the market trying to cover that overhead.

So m-commerce, has yet to take off partially because of technological reasons, but much of the reason is political - everyone, the operators, banks, phone manufacturers and now the app stores have at some stage tried to control this market, resulting in no solution ever getting wide acceptance.

Your options at present are probably limited to the following:

NFC Solution. Users can buy credit, which is then updated using an 'admin' app running on an Internet connected and NFC enabled smartphone or tablet. They can purchase by swiping said 'admin' device (with their Internet connected and NFC enabled smartphone), running a publicly available app, which then checks their account and if they've enough credit, deducts the amount accordingly.

The advantage of this is that you don't pay anyone anything. Disadvantage is that unless you can find a suitable third-party solution, you'll have to build it and will be responsible (i.e. legally liable) for anything going wrong.

Additionally, such an app is strictly speaking against the T&S of iTunes/Play (you're not allowed to circumvent their payment systems, which this would be doing), so you could find yourself banned from them - although this has never happened to date AFAIK, so consider this more a caveat than a dealbreaker.

This is the approach taken, more or less, by Starbucks, as well as a number of other companies/organizations (e.g. Dubai Roads and Transport Authority).

Payment Gateways. Some, such as Paypal, are already allowing people to pay via phone with their apps. Only disadvantage is that they're only allowing people in certain countries (i.e. North America) to do so. Google also offer API's to allow something similar through their Wallet platform.

If available, you're still paying the payment provider, which could be as high as 30% (I'm not current with rates, I'm afraid).

If you limit it to being a payment system, I'd agree with you, but - in the case of Starbucks - it also acts as a loyalty card.

Hi Corinthian, thanks for the great response. You have pointed out a huge amount of useful information.

In relation to the 30% share (give or take a few % as I'm aware you are "not with the current rates") the payment provider takes, does this only occur if using a payment processor like paypal or say, realex?... or is it a fee imposed by the app store? Sorry if I'm causing any confusion.

Let's say the app I want to create, would in effect, work similar to the Uber app... User opens the app via smartphone (where they have stored their debit/credit card information) selects products to purchase, makes the purchase, and is then issued an e-receipt before the user even arrives to the store. The user then simply has to scan the e-receipt upon collection and walk away with purchased products. Are you saying that if for example I was using realex to process all payments that this is where the 30% fee would come in?

Please excuse my naivety or if I have made anything unclear.

All the info and help is much appreciated. Cheers

The Corinthian

hubba_bubba wrote: »

In relation to the 30% share (give or take a few % as I'm aware you are "not with the current rates") the payment provider takes, does this only occur if using a payment processor like paypal or say, realex?... or is it a fee imposed by the app store? Sorry if I'm causing any confusion.

Both Apple iTunes and Google Play charge 30% on app purchases or for any in-app purchases of subscriptions. Paypal charges about 4.75% for low volumes, but rates vary. What I am not current on is if purchases via Google Wallet or Paypal have differing rates.

Let's say the app I want to create, would in effect, work similar to the Uber app... User opens the app via smartphone (where they have stored their debit/credit card information) selects products to purchase, makes the purchase, and is then issued an e-receipt before the user even arrives to the store.

I don't even know where to begin on the financial liability you're taking on storing that information on a phone.

The user then simply has to scan the e-receipt upon collection and walk away with purchased products. Are you saying that if for example I was using realex to process all payments that this is where the 30% fee would come in?

No. See above who who is charging 30%. I would check how popular Realex's solution is though, before adopting it, were I you.

hubba_bubba

The Corinthian wrote: »

Both Apple iTunes and Google Play charge 30% on app purchases or for any in-app purchases of subscriptions.

So does this mean if i create a payment processing app that no matter what itunes or google play is automatically going to charge 30% commission on every purchase made using the app? Surely that is too high to be right?

[QUOTE=I don't even know where to begin on the financial liability you're taking on storing that information on a phone.[/QUOTE]

Haha ok it that point is duly noted

Graham

Paraphrased from Apple's "App Store guidelines":

Physical goods: you CAN'T use Apple's In App Purchase, you need to use a website or any other method, e.g. PayPal/Stripe etc. (Apple doesn't take a 30% cut of physical goods sales).

more here: http://stackoverflow.com/questions/2084729/iphone-application-and-paypal

The Corinthian

hubba_bubba wrote: »

So does this mean if i create a payment processing app that no matter what itunes or google play is automatically going to charge 30% commission on every purchase made using the app? Surely that is too high to be right?

As Graham pointed out there are restrictions (simelar for both Google Play and Apple iTunes) on the use of in-app payments and trying to circumvent them will result in your account being suspended or terminated. Even if you could use in-app payments (and there are ways of doing this), you'd still end up being charged 30% of the transaction.

Why is this important? Because both Apple's and Google's in-app payments systems have high market adoption and come with the devices. Otherwise a user would need to install another app and set up an account with them, and this will have knock on effects on sales.

Paypay would seem to be one possibility, because many already have Paypal accounts, as it has wide acceptance, but last I heard, they only support transactions in north America.

Personally, I think your best bet is to view such an app as a wallet / loyalty app, like Starbucks. People can top up at the counter (paying in cash) and over time, you can add digital payment options, to top up, such as Paypal, as they become available. Once topped up they can spend their credit, as they see fit and earn free coffees, or the like, like any other loyalty programme; thus incentivising take up.

pedronomix

Sounds like a very complex way of trying to replicate the by now standard credit/debit card RFID low value payments "non -contact wave" facility ( Proximity Chip) . Merchant just needs to capture one unique customer identifier and hey presto you have a smart loyalty card that could give discounts, one free offers etc. Customer just needs to register once! Simples!

The Corinthian

pedronomix wrote: »

Sounds like a very complex way of trying to replicate the by now standard credit/debit card RFID low value payments "non -contact wave" facility ( Proximity Chip) . Merchant just needs to capture one unique customer identifier and hey presto you have a smart loyalty card that could give discounts, one free offers etc. Customer just needs to register once! Simples!

It should be, but it's not. As I said in my first post, the development of m-commerce has been plagued by corporate politics, with everyone at some stage or other seeking to monopolies what would become the payment gateway standard. This is probably the single biggest reason that it's been so slow to take off.

Secondly, there are security concerns with mobile translations you don't get with the Web, particularly surrounding stolen devices.

Finally, but more as an aside, unless you're either Google or Apple, there is no reliable unique customer identifier in existence from a device. All identifiers have known issues, that can lead to false negatives, or worse still, false positives.

pedroeibar1

The Corinthian wrote: »

As Graham pointed out there are restrictions (simelar for both Google Play and Apple iTunes) on the use of in-app payments ............... you'd still end up being charged 30% of the transaction.

That cannot last as it is a failed model - in the early days of ecommerce some transaction sites tried to charge a handling fee of a fraction to 1% for business transacted on-site. All failed unless they brought considerable sophistication to the party. Imagine Eircom charging a commission on a business deal conducted over its phone system. Same thing.

pedronomix

The Corinthian wrote: »

It should be, but it's not. As I said in my first post, the development of m-commerce has been plagued by corporate politics, with everyone at some stage or other seeking to monopolies what would become the payment gateway standard. This is probably the single biggest reason that it's been so slow to take off.

Secondly, there are security concerns with mobile translations you don't get with the Web, particularly surrounding stolen devices.

Finally, but more as an aside, unless you're either Google or Apple, there is no reliable unique customer identifier in existence from a device. All identifiers have known issues, that can lead to false negatives, or worse still, false positives.

we may be at cross purposes here.
I am not talking about devices but rather the proximity payment facility that is on nearly all credit/debit cards and the existing ability of merchant card machines to process them... a customer loyalty add on is what would make them much more user useful!

The Corinthian

pedroeibar1 wrote: »

That cannot last as it is a failed model - in the early days of ecommerce some transaction sites tried to charge a handling fee of a fraction to 1% for business transacted on-site. All failed unless they brought considerable sophistication to the party. Imagine Eircom charging a commission on a business deal conducted over its phone system. Same thing.

All have tried to exploit some form of monopoly or other, rather than bring anything of value to the party; the operators that you had to go over their network, the credit card companies that you had to have their agreement to be have the transaction recognized and now the app-stores as you are using their pre-installed in-app system or that you have to use them to get the app in the first place (Apple).

Having observed all this since around 1999, and even present in meetings where such attempts were actively planned, I can attest to how frustrating it is.

pedronomix wrote: »

we may be at cross purposes here.
I am not talking about devices but rather the proximity payment facility that is on nearly all credit/debit cards and the existing ability of merchant card machines to process them... a customer loyalty add on is what would make them much more user useful!

Then I suspect you're essentially describing the Starbucks model.

Either way, while there is a way to implement what the OP wants, development is unlikely to be as straightforward as standard app development as analysis and risk assessment will have to be carried out due to the financial implications involved.

pedroeibar1

The Corinthian wrote: »

All have tried to exploit some form of monopoly or other, rather than bring anything of value to the party; the operators that you had to go over their network, the credit card companies that you had to have their agreement to be have the transaction recognized and now the app-stores as you are using their pre-installed in-app system or that you have to use them to get the app in the first place (Apple).

Having observed all this since around 1999, and even present in meetings where such attempts were actively planned, I can attest to how frustrating it is.

Then I suspect you're essentially describing the Starbucks model.

Either way, while there is a way to implement what the OP wants, development is unlikely to be as straightforward as standard app development as analysis and risk assessment will have to be carried out due to the financial implications involved.

Maybe he should consider Bitcoin (hat, coat....)

pedronomix

pedroeibar1 wrote: »

Maybe he should consider Bitcoin (hat, coat....)

More up your street than mine, I would suggest!!