At our Tech Hub in Berlin, we build best-in-class shared services that are used by OLX apps and websites around the globe. One of the more recent services is our Global Payments Service aka Plutus.

Payments is tricky business. OLX does operate in many countries, in which credit cards are not a very common payment instrument. Instead we are looking at SMS payments, cash deposits at the nearest gas station or some very niche online payment methods, that most people have never heard of.

But even beyond enabling our customers to pay, there are many more obstacles to overcome when you want to accept payments as a business. You have to be able to offer refunds, need to know when exactly the generated revenue should be written into the books, should have risk checks in place, to reduce losses and fraud. And wherever you are offering card payments, you have to do a lot of effort on your infrastructue, processes and application security side to be compliant with the so called PCI Data Security Standard.

Given that huge complexity, we wanted to relieve every of our apps and websites from the burdens of implementing payments themselves, and rather encapsulate all of that inside an easy-to-use service.

Enter Plutus

When we started thinking about the technology stack for Plutus, one thing we were certain about from the beginning was that we need a robust and battle-proven foundation. After all, no one likes to lose money and our customers trust us that we handle their financial data according to the highest standards. This quickly led us to the Java Virtual Machine — a platform that we felt was very mature, offered tons of enterprise tools and frameworks and we already had very good experiences with in Berlin.

The Plutus Architecture

At the same time, looking at Java, we felt that it just has not aged very well. Even with the latest features of version 8 and now the upcoming 9, it can’t be considered a modern language. It is still clunky to use, very verbose, functional programming concepts are concealed behind an inconvenient Stream API and the famous NullPointerException hides behind every corner…

We though it is about time for something new, something fresh. But we still wanted to build on top of the JVM.

Enter Kotlin

Call us insane, or maybe brave. In the end it was probably something in between, but we decided to give Kotlin a try. For those of you who have not heard of Kotlin yet — and they are getting fewer by the minute — Kotlin is a rather new programming language by JetBrains, the creators of IntelliJ IDEA and other awesome products.

We made this decision before Google announced to offically support Kotlin as an Android programming language, so we did not have quite the confidence we got today back then. But what was convincing was the language itself. It offers some very well thought-through features, like built-in null-safety or immutable collections. Or the type inference, that makes you write way less code which in turn enables Kotlin to be as expressive as Java can never be. Functional programming is a breeze, you can call map() or filter() directly on a collection, without going through the Stream API. Lambdas are very well integrated and Kotlin comes with a fantastic set of standard library functions that makes every-day programming tasks so enjoyable!

Interestingly, even experienced Java engineers who came into our team and spent a bit of time with Kotlin, stated after just a couple of weeks that they prefer Kotlin over Java and are likely to stick with Kotlin, if they so can. What better approval could we have been asking for when we started this great experiment?

In the end — besides the language — we don’t do much different to how other JVM applications work. We don’t use that many Kotlin specific libraries but instead use proven Java frameworks, and Kotlin enables us to seamlessly call their APIs without any additional effort.

Kotlin even made us better programmers. Remember how I mentioned earlier that all types in Kotlin are non-nullable by default? That means if you see a String type in your code, you can be sure that it will never be null . In fact, you will get a compiler error if you ever try to put null in there. If you really want a nullable type, you have to append a ? to the type, so String becomes String? and is now nullable. Likewise the compiler will give you an error if you try to dereference a String? without explicitly verifying that it is not null . Now whenever we see ? s in our code, we treat it as a code smell, we realise that we should be refactoring those bits to not rely on nullables at all (unless in some very special cases, where we consider it to be a valid scenario).

Summary

In the end, Kotlin has proven itself to be a really good choice for us. We really do enjoy programming with it and we firmly believe that happy coders generate better code. After all, we spend 8+ hours every day in front of our computer screens, why not having a bit of fun while we are at it?

We’d strongly recommend every JVM developer to check out Kotlin. Play a bit around with it, you don’t need to go as far as we have and using it in production right away. But even if you choose to, Kotlin interoperates so well with Java, you can just start with one class or maybe a unit test, and then gradually move on in your own speed.

And after all, we — the Plutus team — hope to be able to build on that foundation and deliver great and secure payment experiences to you!