There comes a time in your professional career when you need a change in order to progress and push yourself to a new limit. In my case, it was a move from an established position of a Senior Project Manager in a hardware manufacturing company to Payair – an IT provider of digital payment services in the fast paced fintech industry.
It sounded like a good opportunity in a fascinating and rapidly growing fintech market that a good friend of mine told me so much about. The problem was that my fintech knowledge was limited to paying for grocery shopping using my mobile, occasional online shopping using my debit card and registering my debit card at a few merchants via apps. I needed to get up to speed on the basics of mobile banking really fast to support my team as a Project Manager. Questions started to pile up: How does a transaction process work? What is the difference between an issuer and an acquirer? Are contactless payments safe? What is tokenization?
There were more and more unknowns everywhere I looked but, with time, support of a great, knowledgeable Payair team and the right attitude, it all became crystal clear to me. If you are interested in card payments the information presented below can be very useful so without further ado let me share my findings with you!
Players in the payment ecosystem
Let us begin by introducing the main parties of the card payment ecosystem.
A payment transaction is a transfer of money from a person wanting to buy goods (a consumer) to a person selling them (a merchant). There are four parties involved in this process, hence the name Four-Party Model as per the picture below:
- Consumer – a person wanting to buy goods, typically paying using a credit or a debit card.
- Merchant – an entity selling goods, using a payment system like a terminal to send the relevant card and transaction data for a transaction payment.
- Issuer – typically a bank issuing the card to the consumer. The main role of the issuer in the transaction process is to check if the transaction is not fraudulent and if there are sufficient funds available to cover the amount due. Once all checks are completed, the issuer sends an approval for the transaction back to the merchant.
- Acquirer – a bank that the merchant has an account with. The acquirer receives all the necessary information about the payment to send to the Issuer for authorisation and releases the funds to pay the merchant once the goods have been released to the consumer.
It is also worth mentioning that there is a Three-Party Model where an issuing bank and an acquiring bank is the same entity. This model is used by such companies as AMEX, Diners Club and Discovery Card. However, it is not popular in Europe so it is outside of the scope of this article.
In reality, there are more parties involved in the payment process. The additional entities provide necessary services for the transaction process. The main one is the Card Schemes or Card Brands (Visa, Mastercard, JCB). They establish communication between acquirers and issuers and ensure relevant information is linked to authorise the transaction payment.
Let me give you an example of how it all fits in everyday life. When I refill my car at a petrol station I usually pay using my Mastercard debit card. The petrol station is the merchant in this model and I am the consumer. When I tap my debit card at the terminal a payment request is sent to the merchant’s bank (the Acquirer). This bank sends the transaction details to Mastercard (Card Scheme) who contacts my bank (the Issuer) to confirm if they recognise my details and if I have enough money in my account to pay for petrol. Once it is all confirmed a message is sent through the same chain back to the merchant’s terminal and I can see payment approved text on the display. It all happens in a matter of seconds without me even thinking about the number of parties involved and connections made and I am back on the road again.
That is all when it comes to card payments but how does it differ for online payments? It is basically the same but often the merchant delegates the difficult technical tasks like accepting electronic payments and managing technical connections to a Payment Service Provider (PSP). PSP is an entity that sits between the merchant’s portal and the acquirer.
You might wonder how this applies to my everyday e-shopping experience. When I go to the website of my chosen retailer, I put all the necessary items in the basket, click pay and a payment interface appears (sometimes as a pop up window) to insert my credit card credentials. Once I confirm all the required information, it is sent to the acquirer and the payment flow is the same as when paying for petrol in the previous example. The PSP is the party who supplied the payment interface element of the website that I could easily complete.
Mobile payment’s breakthrough
We know what the ecosystem looks like and which parties are involved in the card payment. But how does the card data required for a payment transaction and safely stored on the card’s chip end up on the mobile phone?
First mobile payment implementations involved so called Secure Element (since 1997). Payment card credentials were stored on a chip embedded in your device. However, this solution had a complex business model and in 2011 an alternative technology was born – Host Card Emulation (HCE).
With HCE the card number is emulated in software and the need for Secure Element disappears. Instead of the cumbersome process of placing a card number on a hardware there is now an option to keep the virtual representation of the card in the cloud. The user can download the virtual card number to their phone at on-boarding and voila! Phone payments by tapping the terminal are unlocked.
Google started supporting HCE in Android version 4.4 (in 2013) and the path to the mobile payment adoption was opened. As a side note: Apple never opened NFC technology and uses a hybrid HCE and Secure Element approach in its Apple Pay solution.
HCE technology opened the mobile payments world but there was still one little problem. Your precious card data is suddenly stored on multiple devices and exchanged with not-always-trustworthy merchants. The chance of it being stolen suddenly has risen. The answer to that was tokenization.
Wikipedia explains tokenization as follows: when applied to data security, tokenization is the process of substituting a sensitive data element with a non-sensitive equivalent, referred to as a token, that has no extrinsic or exploitable meaning or value.
In other words during the tokenization process the card number (PAN) that is printed on the card is replaced by a different set of numbers. This new set of numbers, a token, is then stored on an electronic device or the merchant’s database to use for payments instead of the actual card number. From this point, the card number is no longer used in the transaction flow. The token is passed between parties until it reaches the Issuer where it has to be referenced back to the PAN.
Tokenization increases payments security. Even if there was a successful attempt to steal data from the merchant, the real card number remains unknown, only a token would be invalidated. Additionally, tokens can be limited to certain merchants and restrained to specific devices so potential security breaches are easier to flag and invalidate only a specific merchant’s token in case of a fraud.
The graphic below shows the tokenization process and a payment transaction using a token:
Payair’s role in the ecosystem
Card schemes typically develop card-based digital payment technology for retail banks and PSPs in house. Implementation and maintenance of these solutions are ideal for outsourcing to entities who can deliver better results faster. Payair fits right in with our products portfolio, experience and knowledge.
Our mission is to simplify implementation of digital payment solutions. We provide a digital payment platform that helps card schemes, banks and PSPs roll out card-based payment solutions to merchants and consumers. Additionally, there are substantial benefits to the end user by providing management of their digital payment footprint by controlling their tokens, visualising to whom a token has been given out, and the possibility to delete/withdraw tokens from merchants. All this directly from the Issuer banking app, without having to contact the user’s bank or the merchant.
The main focus is on delivering token based card solutions efficiently and offering integration of Contactless SDKs (HCE), OEM Pays, Token Connect & Control and client specific solutions. In addition, Payair provides e-commerce solutions for Card on File, PayLater functionality and soon Secure Remote Commerce “SRC” both for Issuers and PSPs.
In short, Payair connects Banks and PSPs to digital payments technologies faster, better and at a lower cost.
Becoming an expert
As you can imagine this is just the tip of the iceberg and every day I learn more about mobile payments. The information covered in this article is kinder-garden knowledge for my Payair colleagues but it’s a must-have for anyone that is interested in card payments topic. Here at Payair, we all know that fintech is a very rapid and challenging environment and the learning curve might be steep at the beginning. However, the basics I presented should make you feel at ease with the subject and maybe even convince you to consider a move to this wonderful world of mobile payments.
Developing cloud-ready solutions has become an industry standard, especially in the enterprise world. Sooner or later your application has to face the problem of poor horizontal scalability or high memory usage and we all know it is better to be prepared.
We understand this at Payair as well. When we faced the challenge of preparing the backend to our mobile payment app, we decided to use frameworks supporting a serverless approach as much as possible. One of these was Quarkus.
Supersonic Subatomic Java
As creators of the framework are describing it, Quarkus is:
A Kubernetes native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.
On the Quarkus website you can find information that it has been designed around “container first” philosophy, meaning that it is optimized for fast boot times and low memory usage. As a result, we should gain near instant scale-up and high-density memory utilization in container orchestration platforms.
The way this has been achieved can be summarized as follows:
- Build time metadata processing. As much processing as possible is moved into the build process e.g. all of the classes required to perform initial application deployment are used and dropped while building. They are not loaded into final JARs (and JVMs) or native executables. You can say that the framework is tailor-made for you every time you press a build button, without compromising the effectiveness of a declarative approach.
- Reduction in reflection usage. Considering the point above, the resulting application contains only direct invocations. All of the fields, methods and classes that are not being called directly are purposefully removed. The same applies to dependencies as well. There is a way to include such calls (register them for reflection), but Quarkus will gently warn you that you may be deflecting from the real purpose of the framework.
- Native image pre-boot. Quarkus supports native executables that can be run with GraalVM. Actually, the creators of Quarkus state that the framework was designed to be run as a native image. The ahead-of-time compilation reduces the need of dynamic scanning and loading classes into a JVM.
- GraalVM. GraalVM is a native code generator which will compile your project into an executable that can be run without the JVM. You can read more about this superb project here: https://www.graalvm.org.
Below you can see a comparison of memory usage and boot time of sample applications:
Evolution, not revolution
What is interesting about this framework is that it is not revolutionary. Since some of Payair’s developers had mainly Spring experience, we were concerned that it would be difficult for them to “switch sides”. It turned out that our fear of the unknown was completely unfounded. Quarkus leverages some good old Jakarta EE standards that all Java developers are familiar with. We did not have to learn a bunch of new APIs that are advertised as “the best way to create REST endpoint” or “reinvented database access”. Instead, Quarkus uses Context Dependency Injection for beans, JAX-RS for RESTful web services, JPA for database access and many others.
On top of that, Quarkus extends available Jakarta EE functionalities responding to modern world developers’ demands. These are called Quarkus extensions and, to name a few, they contain support for reactive programming (but using the declarative approach), event messaging, etc.
Apart from a wide variety of available extensions, there is also a way to create your own, based on the library of your choice. Keep in mind though, that if you want to preserve those drastic optimizations that Quarkus offers, you will have to apply them manually to your extension as well.
Shout-out to MicroProfile
I would like to stop here for a second and give a big shout-out to the Eclipse MicroProfile initiative. It specifies a collection of APIs and technologies to form a baseline for quick and effective enterprise Java microservices creation. The goal of MicroProfile is to define a specification for building microservices and deliver portable applications across multiple runtime implementations.
Optimizing enterprise Java for a microservice architecture is a challenging task and, in my opinion, MicroProfile handles it pretty well. As a long term Spring developer I realized that Spring is slowly becoming the very thing it swore to destroy. The initial premises of Spring (which basically can be summed up as a lightweight alternative to Jakarta EE) are way past the expiry date now. Spring is the undisputed heavyweight champion that can handle everything you imagine but is not your best option for fast and light services. And that applies to Spring Boot as well.
It is worth mentioning how the development process of Quarkus application looks. First of all, you are not forced to use native images from day one. Normal JVM builds are still available. Resulting JARs are not as fast as native images, but still faster than your normal enterprise applications.
This leads us to the most important thing: dev mode. The special Maven plugin allows you to quickly reload classes while you are editing them, leaving an impression of hot deployment. Changing the functionality and testing it right away without further ado is a real joy. No more distracting builds and endless context switching. Pure development mode, hence the name of the plugin.
There is one more benefit of a quick startup time. Writing RESTful applications requires significant amount of integration tests on the API level. With Quarkus on board, running them gives a unit-test-smoothness feeling and if you are even a slight fan of TDD, you will appreciate the difference.
One of my personal concerns when switching from Spring to something based on Jakarta EE was lack of Spring Data JPA. I really like the mix of simplicity and functionality this module provides. But it turned out that Quarkus has my back on this one as well. There is an extension called Hibernate ORM with Panache. It is a layer on top of Hibernate ORM which focuses on simplifying ORM to the maximum without compromising the actual power that ORM gives. Panache has managed to find a sweet spot of making it trivial to work with simple entities without giving up possibilities for handling complicated use case scenarios. Bravo to Panache and adios to Spring Data!
We are yet to implement the first release of Payair’s Quarkus application into our production environment. Based on our experiences from lower level environments, we just cannot wait for it! CI/CD is no more complex than with any other framework. We only needed vigilance while setting up native build scripts. The differences between JVM and GraalVM runtimes are negligible. Moreover, our initial performance tests are looking very promising.
On the other hand Payair has many demanding customers who happen to be financial institutions. Throughout the years we have learned that they expect global reach, high performance and high availability from our products. Our solutions must be thoroughly tested, reliable and bulletproof. We are in an industry that is very risk averse and although we are aware that others are already using Quarkus in production (https://quarkus.io/blog/tag/user-story), we need to verify this for ourselves since the framework is still considered a new player on the market.
The next step is to push our Quarkus implementation to the limits to see how it behaves under a real and heavy load. For now we believe that everything will work even better than we could have anticipated. We will let you know how it went.
For more information on Quarkus:
- Quarkus website: http://quarkus.io
- Quarkus GitHub project: https://github.com/quarkusio/quarkus
- Quarkus Twitter: https://twitter.com/QuarkusIO
- Quarkus chat: https://quarkusio.zulipchat.com/
- Quarkus mailing list: https://groups.google.com/forum/#!forum/quarkus-dev
- Quarkus YouTube Channel
- Four reasons to use Quarkus