The importance of m-commerce is rising – every third mobile user has already purchased something through the phone.

Do not miss the opportunity to add mobile as an additional revenue channel and easily accept in-app payments through PAYMILL’s Mobile SDK now.

We are at Droidcon in Paris today and tomorrow and MLOVE in the south of Berlin later this week. Come say hi – happy to catch up!

If you are interested in how we developed the PAYMILL Mobile SDK from the technical side, read here: 

When it comes to payment, the first thing that comes to mind is security. As it turns out, the biggest challenges in developing our Android SDK were not in terms of security, but integration ease and reliability.

One of the key features of PAYMILL is simplicity. Thanks to the pre-defined payment form, many shop modules and API libraries, it often takes only a few lines of configuration and code to get you started in the otherwise complicated field of payment processing. When we designed the Mobile SDK we wanted to follow the same philosophy and make the integration of payment processing into your apps as painless as possible.

Creating a transaction (issuing of payment) is one or a series of network calls to the PAYMILL servers. So in the SDK interface, we could have simply exposed some synchronous static methods, which do just that. For me, as a developer, this would mean that I have to find my own way of dealing with multithreading. This brings some questions like: Do I simply use a Thread, or an AsyncTask, maybe a Loader? How do I deal with synchronization? What to do, if the original UI element is no longer there, when the method returns (e.g. Activity is restarted because of screen rotation)? To relieve the developers of having to deal with these kinds of problems we created asynchronous calls that return almost immediately. For each method we created a listener interface. We call these listeners “Foreground Listeners”. When a certain method is finished, we post the result to the registered listener(s) directly on the UI Thread, so that  UI elements can be modified without having to deal with concurrency at all.

Having found the best possible way for apps to communicate with the Mobile SDK (in our opinion), we had to deal with reliability. After all, you don’t want your customer’s payments to get lost. The first case we handle is that the operating system decides to kill your apps process, while the SDK issues a payment. To ensure this does not happen, we start a service in foreground mode for the time a method is executing. This way, even if your customer gets a phone call and the system is running low on resources, it will (hopefully) not kill your app. The problem with this approach is that we need to stop the service when all methods are finished, to ensure your app doesn’t drain the battery. So, if you are unlucky, the system might decide to kill your app after the SDK has done its thing, but before you are done processing the result. This processing might be really short, like saving the result in a local database, but might take longer, like sending the result to your backend on slow network connection. So we extended our listener interface and added a “Background Listener”. This listener will receive callbacks on a separate thread, so you can do long running background operations, again without having to deal with concurrency. In addition, while the callback method is been executed, the service still runs in foreground mode, which “protects” your app from being killed before the method finishes. If you like this approach to multithreading and want to integrate something similar into your app, you can check out Robospice, a great Android framework from which we drew inspiration.

The above method helps your app be reliable in situations where the operating system might decide to kill it, while in the background. However, there are other “bad things” that can happen, while you process a payment: the app or even the operating system may crash, the device may lose network connectivity or run out of battery. We use a simple, yet powerful concept for dealing with such “extreme” situations. Each transaction can be marked with a simple Boolean flag, we call “consumed”. When a request reaches our servers, we mark it “not-consumed”. When your app processes the result, it signals the SDK, and thus our servers, that you are ready and the transaction is marked “consumed”. In addition, you can also request a list of “not-consumed” transactions.

Using these functions your app can recover from every error rather easily. When your app is started or the device reconnects to the network, it can request the list of not-consumed transactions and run a recovery routine similar to the pseudo-code below:

for (transaction in not-consumed-transactions) {
if (!isDoneProcessing(transaction)  {

There are three time spans to consider. First: The initial transaction request never reaches our servers. This case is not critical, as the app neither has processed the transaction, nor charged the user. The second time span is when the transaction reaches our servers, the user is charged, but the result doesn’t reach the app or it is interrupted while processing it. In that case the recovery routine will start or resume the processing and in the end – mark the transaction consumed. The third time span is when the transaction has been successfully processed, but the “consumption” request never reaches our servers and the transaction is thus still marked not consumed. This case is also important, as you don’t want your app to process the transaction more than once. To prevent that, the recovery routine should first check if the given transaction is already processed, and if so just proceed with marking it consumed.

These are only some of the features of the PAYMILL Android SDK. If you want to easily integrate payment processing into your apps, style and place your own payment screens as you wish, enable recurring payments and subscriptions: Check out the PAYMILL Mobile SDKs.

Guest Blogger

This is a guest post written by one of our contributors.