If you want to accept card payments with a mobile device, you’ll probably end up with Square or one of similar solutions (mPowa, iZettle etc.) – that’s what the search results will give you. But ask yourself, do you really need and want to set up a new account and attach a piece of hardware every time someone pays you?

Is this really the only solution?

Well, it depends.

There are alternatives, but whether you should use them or not – this mostly depends on your business type, its model and needs. It’s quite different if you want to accept payments in a single restaurant, a chain of restaurants, if you deliver goods to your customers or sell both online and offline.

But first things first, what’s Square’s alternative? The simplest solution, if you don’t want to attach anything to your phone/tablet, is to write a mobile app. Now I know this may sound scary and you probably thought only about services that already exist, but give me a chance here. Besides nobody says you will have to create the app by yourself.

The difference

You don’t have to swipe the card, but enter its data or scan it using the device’s camera. This should be as quick as swiping, but before we list the pros and cons, let’s explain how it works.

You know very well how to pay with a card online, right? You get a form, enter the card data and submit. Now we’re talking about the very same thing, but the form is not on the website, but in the mobile app. So this way you actually accept an online payment.

What about the said scanning? It’s just OCR, you can even use a library meant for such purposes (check out card.io).

So what are the main features of such solution?

Pros

• No additional providers, no hardware
  You don’t have to buy or attach anything. And if you already have a merchant account (assuming that you sell online), you can probably stick to the payment provider you already cooperate with. Fewer elements mean fewer chances one of them will experience discontinuance. Of course you still have the scanning library, but still – if there’s something wrong with it, you can enter the card information manually and submit the payment.
• It’s fast
  Scan, confirm and… that’s it. While scanning may be as fast as swiping, there’s no need to place signatures or anything like that. As we already said, it’s technically an online payment.
• Flexibility
  There’s no need to have a separate app just for payments. What we’re talking about is just a solution that may be implemented in any app. If you want your app to do anything else (present products, opinions etc.), it’s not a problem – payments may be just one of the functions.

Possible cons

There may also be some disadvantages of such a solution that you should be aware of.

• Trust
  Not everyone will trust you enough to allow scanning a card. They may think you take a photo to do something evil later. Of course swiping a card doesn’t have to be secure as well (theoretically you can use skimmers), but it’s all about what people think, not how it actually is.
• Card limits
  While most people have reasonable limits for card present transactions, some may have set 0 for online payments. And it probably won’t be that easy to explain to a person who holds a credit card that it’s a card-not-present transaction.

Examples, give me examples

All above may sound both promising or discouraging – this probably depends on your needs. If you happen to be the second case, let me tell you about an example. We recently met a young startup (tagberry.in*) that created their own payment module and are implementing their solution in several restaurants. But it’s not the startup itself that we want to tell you about, but the restaurants that work like this:

You sit down by the table to find a tablet lying on top of it! What for? To order your food, of course.
You can go through the whole menu, check out the photos to learn what a dish looks like, talk to your friends. You can even check out other people’s opinions about a specific dish or share your location with your friends. And of course you can place an order and make a payment – the waiter’s only job is to bring you the meal and ask whether you like it or not. You can even play a game or surf the web while waiting for the food to arrive. How great is that?

The restaurant must obviously have an app, at least for the menu/ordering thing. So why not add a payment section as well? A customer places an order and scans the card (or scans it after the meal).

As you see, there are no good or bad solutions. It all depends on a specific case, but surely if you plan to create your very own app for your purposes, adding a payments module should be quite reasonable.

(*) – Tagberry.in already has working prototypes of their payment devices and we’re looking forward to seeing the official launch.

photo source: SXC.hu

Maciej

Maciej is a PHP-freak, interested in everything that's related to new technologies and photography. He writes about being a young developer working in a company like PayLane and shares his experience in web development. As an IT technician, he loves to solve problems, especially if we are talking about debugging SQL queries or solving Rubik's Cubes He doesn't like to be bored, so his free time is full of activities such as being a professional dance photographer.