Whenever you are trying to scale, it is often a good idea to provide the necessary tools for your users to help you in the task. It is also important to find ways of making them stick to your solution and not go shopping for alternatives.
In the case of iZettle vs. Square vs. Payleven vs. Sumup, there is an all-out battle for ground. Whether that is geographical, technological or commercial. First there was the issue of accepting all the major credit cards, then they were all trying to go after chip & pin cards, finally it is the battle for the mobile app market.
Namely, allowing developers to use their payment platforms natively within the apps. iZettle announced today that they have released the SDK for iOS, allowing you to take in-app purchases using iZettle. The SDK also allows to return post-payment information to the app, in order to update inventory, accounting, print receipts, enter data into CRM, etc.
So basically if you are looking to build a brand new restaurant point-of-sales app, then you could simply use the SDK in order to handle all the payments. This might be an additional selling point for you as you can convince restaurant owners to not purchase often expensive POS solutions and everything would be managed within your app. As iZettle’s co-founder and CEO Jacob de Geer commented: “Whether you have developed an app with a totally new take on point-of-sale systems for cafés, or a Craigslist-like app matching buyers and sellers in the physical world, iZettle’s SDK can easily be implemented to ensure the payment process runs like clockwork for both customers and businesses.”
This is actually an important piece of development for iZettle in order to stay in the game. iZettle,Payleven and Sumup have launched their own API’s already in 2012, and Square is rumored to be making theirs. However iZettle is the first one to launch an SDK which is taking the integration possibilities a little further.
For those less technical in nature, basically an API is an interface. What that means is that as long as you have the exact ways of how to interface, then you can use it. Think of it as of the electric system in your house, if you live in Europe and buy European devices, they will all interface easily with your plugs at home. An SDK, on the other hand is a tool kit, which can allow you to build something completely custom. If you want, you can build an American adapter yourself and then use American devices with it. Similarly with an SDK, the developers can make everything look and feel much more native and in-line with their apps and achieve a lot more functionality than they otherwise would with an API.
Making this possible, allows the companies to try and lock-in app developers within their system early on. It may be easy to change the code and start accepting a different payment provider, but if you integrate with iZettle and your clients start using it actively, then changing the provider would mean getting all new credit card readers for all of your existing customers and that can definitely be a hassle.
So this is yet another “must-have” feature in the mobile payment provider’s fight for supremacy. From the looks of it they are all very similar, despite some differences, so I can’t wait to see what will really set them apart.
