How credit card payment works

Working for the payment industry, I am often asked how credit card payment works. Although a credit card is involved with many aspects, such as card making, card security and purchase processing, understanding the five key players in the business would provide a clear idea of the credit card business.

1. The consumer: a credit card holder who’s responsible for any payments of his credit card.

2. The merchant: a shop or service provider who accepts the customer’s credit card payment. For every credit card transaction they accept, they must pay a fee called the “merchant discount”.

3. The issuer: a bank that issues credit cards to consumers.

4. The acquirer: a bank that serves the merchant. This includes crediting the merchant's account for the value charged to a credit card less all the fees.

5. The payment network: a credit card service provider that processes card payments and links the acquirer and the issuer involving this payment. Visa and MasterCard are the largest payment networks in the world. Other worldwide payment networks are American Express, Discover and JCB.

The issuer, acquirer, and payment network support the credit card payment at the background, unseen by consumers.

This “five-player” setup allows the acquirer and the issuer only to deal with the payment network instead of having direct contact with each other during a transaction of credit card payment. In this way, a card issued by a bank in UK can be used at a shop in US without requiring the banks (the acquirer and the issuer) to have a direct contact. The consumer deals with the merchant, the merchant with the acquirer, and the acquirer with the payment network. At this point, the merchant gets paid the price less the “merchant discount” and the consumer served. The payment network then continues the process to contact the issuer who will send the credit card bill to the consumer.

The “merchant discount” is shared between the acquirer, the issuer and the network. Typically in US, the average "merchant discount" is about 2.0%. Of this, 1.7% goes to the issuer (known as the “interchange fee”), 0.15 ~ 0.17% to the payment network (known as the “processing fee”), and the rest to the acquirer. It can be 2.5% or 3% in some European countries. In addition to the “merchant discount”, depending on the payment scheme, some other fees may apply, such as a fixed service charge. This explains why some shops are reluctant to accept credit card payments.

Many “Prime” or “Superprime” card issuers use the majority of their interchange revenue to fund their loyalty programs, such as “Amazon points”, “Nectar points” and “cash back”. It is usually worth 0.5% and hence the issuer’s profit from card purchasing is relatively small.

However, they recover the loss by charging high interest rates of card lending and other fees, such as the late payment fee and call charges. So, to take advantage of credit cards and save money, it’s better to pay the credit card bill in full on time.

RSA and me – 30 years after my first implementation

My first implementation of RSA was in 1988, 30 years ago. Time flies! I write a small essay here for the record.

In early 1985, less than one year after my graduation with a degree of Computer Science, I happened to get involved with a cryptography project to implement a block cipher for a satellite communication system.

At that time, the DES had been published for nearly 10 years but, by the hardware availability in China, it was impossible to write a piece of software, in 8086 assembly, to achieve a performance to encrypt a 32kbps voice channel. A block cipher with a large block size and a large key space was proposed and implemented. The cipher was assessed as a fit-for-purpose cipher for “battle fields”.

I and my very good friend, Tian Chang, implemented the cipher in an Intel 8086 Single Board Computer, SDK-86 as follows:

and built an interface board to connect this “cipher machine” to the communication channel. He did the board design and layout, and I developed the communication software between the SBC and an IBM PC XT.

We didn’t have any proper tools for the code development and had to use the printer interface of the IBM PC XT to communicate with the Intel 8086 SBC. So we could write and debug code on the IBM PC XT and then loaded the code to the Intel 8086 SBC. Worse, we didn’t have any EEPROM writer nor any spare EEPROM at the beginning. The communication software on the SBC had to be keyed in manually through its key pad (the bottom-right of the picture) in hexadecimals.

Later, we bought a piece of EEPROM and “burnt” the communication code in. It was a very primitive bootloader through IBM PC XT’s printer port. We no longer needed to manually type hexadecimals in. Tian Chang and I later published paper, titled 

    A simple communication method between a microcomputer and a single board computer” in “J. of Military Communication Technology, Jan 1, 1987

This paper was actually a by-product of the project, which was to solve the problem in Intel SDK-86 development. Neither design nor assessment was discussed about the block cipher in the paper.

Two challenges were posed to the deployment of the block cipher: the deterioration of channel quality and the key distribution.

One drawback of applying block ciphers to communication systems is error propagation when CBC mode is used. For a block cipher with long block size, a 10^–6 error rate will be amplified to 10^–4. To mitigate this issue, we designed and implemented a BCH error correction code. This experience definitely benefited my later career in mobile networks (US 8560920 B2/NC10090ES).

The challenge on key distribution wasn’t that easy. The key management for conventional cipher based systems was studied but with the hardware availability and manufacture capability in the 1980’s China, it wasn’t reasonable to expect any “cryptographic facility” to protect any master key. Public-key based systems had to be considered.

There was another commercial need - We were approached by the Ministry of Oil Industry, who were seeking a solution for securing their satellite communications. Hardly to believe, in 1980s ,China was an oil export country and their main buyer was Japan. In the price negotiation, they found their Japanese counterpart appeared having known their annual output and domestic consumption. The Japanese had their advantages in the negotiation. It was a very much closed China then and there were not many contacts to the outside world. Some of the officials were suspecting their satellite links were eavesdropped.

The main oil fields were scattered in the Gobi desert. Each oil field reported their daily output via satellite links by plain text. The need of an encryption system was well received but its key distribution was a headache – a courier needed to take nearly a week to get to an oil field by car, driving in desert. It was infeasible to work with a manual key distribution scheme. A full-automatic system, with minimum hardware security, was much needed.

A public key based key distribution system appeared prefect – a board with a public key of the Ministry burnt in EEPROM. There was no need to consider authenticity, as long as the message was encrypted on the satellite links.

There were three well-known public key cryptosystems available that time: The Merkle–Hellman knapsack cryptosystem, the RSA cryptosystem, and the McEliece cryptosystem. McEliece cryptosystem was ruled out because there was not enough memory in the Intel 8086 SBC. We weighed Knapsack scheme and RSA scheme, and decide to implement the Knapsack scheme.

We knew that the basic Knapsack scheme had been broken by Adi Shamir, but there had been many variants with some fixes. Comparing to RSA, a fast implementation of Knapsack scheme could be achieved while the RSA scheme was formidable due to its big-number modular exponentiation.

We made our own fix and coded the Knapsack scheme. The project was completed but the Knapsack scheme died out very soon. All attention turned to RSA implementation.

The experience in implementing Knapsack scheme was invaluable. I not only had a concrete example of public-key cryptosystem, but also I mastered big-number arithmetic.

Around 1987, ISO was considering to standardise RSA and a fast implementation would be needed.  I thought implementing RSA could be a good project for my MSc degree. A full RSA implementation, consisting encryption, generation of strong primes, and a full big-number library, should be good enough.

To make this project more interesting, or to find a potential customer, I went to a remote village, code named Unit 854 in County Pengxian, near Chengdu, the capital of Sichuan, in spring of 1988. From my school in Nanjing, it was a train journey over 40 hours. Upon arriving Chengdu, I took a long-distance bus to Pengxian and then caught a local bus to Unit 854. It was a long journey – tiring but interesting.

Unit 854 was located at the foot of Sichuan North-West plateau, about 800 metres above sea level. However, not far away, there are many beautiful mountains above 4,000 metres.

I arrived there in a day of April 1988 and was stunned by the countryside scenery – endless rape flowers blanketing the vast slopes of hills nearby, bright white clouds winding round the mountainside far away, and light blue smokes ascending slowly from villager’s kitchen chimneys here and there – it must be the lunch time.

Unit 854 was a research institute for secure telecommunication networks. Some of their cryptographic experts were educated in Westfield College, London University. It was very rare in the 1980s China.

I really enjoyed my stay in Unit 854 and implemented a 384-bit (100-digit) RSA with an impressive performance 2.7 seconds per encryption-decryption at a 6MHZ 80286 PC. A full big-number arithmetic library was written in 8086 assembly language. The RSA was implemented with CRT with “strong primes”.

My study in Unit 854 was fruitful. So was my climbing and traveling.

Not too far away from Unit 854, there a mountain called Jiufeng (literally, Nine Peaks) 3,800 metres high. I spent whole day on climbing it from its 800 metre foot to its top. I started in the morning and reached the top in later afternoon. After finishing canned food, I tried to cook some rice and the rice was only half-cooked – the water was boiling at 80 degrees Celsius!

In summer, I visited Jiuzhaigou National Park and Huanglong  National Park Huanglong National Park, and travelled Tibetan area in the Sichuan Northwest plateau, 4,500 metre high. It was a beautiful region, not much population.

By retrospection, if the academic environment were not that closed, I would have used Montgomery arithmetic to do the RSA. I heard this method from a friend, Jun Fang, who just finished his PhD from Paris (Telecom Paris Tech) and was visiting Unit 854. I managed to get a copy of Montgomery’s paper, studied it, and made some notes, but I didn’t have any chance to implement it.

I won a contract to make a C version, length variable RSA. The client was Unit 854 who was using Sun SPARCstations to build a secure network. That time I heard PKCS (Public Key Cryptography Standards) and hoped to get a copy of this standard. I was planning to make my RSA implementation to comply with PKCS.

Although China had started the “Open Door Policy” for several years, my connections to the outside world was still very limited. There was no email then, never mind the Internet in China.

I wrote a letter to Ron Rivest and asked if I could have a copy of PKCS. Surprisingly, I received a letter from Ron telling me that Dr Burton Kaliski would send me a copy soon Not long, a big envelope arrived to my office, sent by Burt.

I was very much moved by their helpfulness and warm-hearts. I had never met them and I had not been sure if they would help. I wondered it would be nice if I could say thank-you to them in person.

The work with Unit 854 completed in early 1994 and then I went to University of Bradford, England as an academic visitor, sponsored the British Council. I didn’t have chance to work on PKCS. Later, I won the ORS award and started my PhD study.

Although my research was in the security of high-speed networks, but almost the same time, I was offered a job by Motorola as a Senior Cryptographer, developing crypto engines for their smartcard products – they were developing an RSA engine with Montgomery arithmetic!

To complete my PhD degree, I needed to publish some papers. One of my papers was accepted by the PKC 1997 and I was very happy to know that both Ron and Burt would attend the conference.

The PKC 1997 was held in Four Seasons Hotel Toronto. With great pleasure, I met both of them and thanked them in person for their help. The chat with Ron was short. I recall he wore jeans and a pair of trainers, easy-going and agreeable. The chat with Burton was a bit longer. We talked about work, life and family. It was a very nice trip.

My smartcard experience was short. After two years of my joining Motorola Smartcard Division, they sold the business to ATMEL. Later the same business was sold to INSIDE SECURE.

I stayed Motorola, joined their NCSG (Network and Communications Systems Group) and continued my work on high-speed networks and cryptography, including ECC, AES, Kasumi, parallel RSA, SNOW and so on.