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.