Posted on 11th Feb 2019 13329 views
From the Card to the Bank
From BINs to brands, from POS terminals to the Bank, cards and card data is traveling from one place to another and everything is working in connection. This connected way of working is vital for your experience in the world of transaction processing.
We can show you the way card information travels from the terminal to the Bank that issued it, how your balance works and how you find out how much money you have available to spend.
The way back is just as exciting, because it is not the same. It is just as connected and interesting, and just as important for your knowledge.
When you pay for shopping, the Bank takes money from your card, but how does the money get to the store? Find out about the interesting way the money travels back to the accounts of the stores, who are the parties involved, and who pays for what.
Whenever we use our bank card, we make a call to the bank so the bank can give its approval for our purchase. This is the general flow, sometimes there are variations, but this is the general way for a card to be authorised.
Let us take an example of a simple flow: I am going to an ATM to withdraw money from my card. Well, we all know that the card does not really have money to withdraw, but it has one important thing: it identifies me, uniquely, at the bank, so the bank can give me money. The card has a unique number called a PAN , usually printed on the front of the cards, and the bank knows to associate that to my account, which is usually a IBAN number, also unique.
The card that I am going to insert into the ATM has some data printed on the front and back. The PAN number on the front, the expiry date, the name of the owner, and the CVC number on the back. This visible information is enough for using it in an online payment transaction.
For the ATM though, this is not enough. So there are 2 more places with data, on the card. There is a magnetic stripe, which works like an old video player with magnetic tape. This data can be read by performing a magnetic swipe. The ATM prefers another location to read data from: the CHIP. It is the most secure location for data, and, unless there is a terrible mechanical failure, the ATM will read the CHIP, by placing some physical contacts on the CHIP pins.
From the CHIP, the ATM reads the card number (PAN), reads the card expiry date(also printed on the card), the card sequence number (used to identify the card in case there are more cards with the same number, for example when they are replaced), some specific EMV tags (like PIN data) and then, using this information, the ATM makes a request to the bank to ask if it can give you the amount you have requested.
For the simplification of the example, we will assume that I am using a card that belongs to bank MegaBank and the ATM belongs to the same bank, which means it is connected by wire to that bank. So The ATM can talk freely to the bank, the bank will check my balance on my account and will then respond to the ATM whether to give me the money or not.
When the bank approves, it saves the transaction to my account and debits my account with that amount. So the money is "taken" from my account.
For the simplicity of the example, let us assume that I am using the same card above, issued by bank MegaBank and I want to purchase some bread at the local market, where there is a POS device that is also connected (and branded) to MegaBank.
The POS device also has a preference to read the CHIP data (if possible), or contactless (will explain in the next paragraph) or, if not, the magnetic stripe, or even an emboss reader, which reads the embossed letters from my card (not in use anymore).
When the POS device is capable of reading the contactless (NFC) data from the card, and the card is capable of contactless reading, they both have the mark/sign for contactless, like the image below. The contactless data also comes from the CHIP, but the CHIP does not tell as much as it would if you used the contacts of the CHIP, which are more secure.
So, the POS device reads my card and also asks the bank to approve the purchase of the goods. If the banks approves, the bank saves the transaction on my account and from that moment, I cannot use that money. Unlike the case of the ATM, where I have received my own money and the transaction is complete, in the case of the POS, the merchant, the owner of the shop, has not yet received any money. My bank just approved that I am "good for the money". That is only half of the story.
The POS device is at the shop as a result of a contract between the POS acquiring system (which in this case is the same bank that made the card). So the shop owner, called merchant, made a contract with the bank to be able to accept cards payments, and the bank gave him a POS device, a contract and of course, an account number where money is going to arrive. However, the bank does not make the money transfer from my account to the shop owner's account right away when I buy something, but they wait for a convenient time to perform this sort of operations, like midnight, maybe once every few days. The reason they wait is complex and is a sum a of many aspects. First, they want to wait to make sure you do not change you mind and "reverse" the transaction, also they want to wait for a moment with less traffic so they can perform some accounting. This accounting consists of taking fees for services, like the fee for the transaction, the fee for using the POS, and other fees for other parties which are usually involved in a transaction.
So the key takeaway is that the first part of of a transaction with a card happens in real-time and is called an Authorization. The second part is when the shop owner gets the money from your account and the bank gets the fees, and it is called Clearing.
The scenario above, where the ATM and the POS device are connected directly to the bank is quite common, but the true power of a Debit or Credit card is the fact that it can be used anywhere, at other bank's ATMs or POs devices, in another city, in another country on another continent. You want it to work in Hawaii and you want it to work in Bali, no matter if it was issued in Nairobi or Sankt Petersburg. You can imagine this is not an easy task to accomplish, and that is where the Card Brands , or Switches, step in.
Let us take the example of Visa, which is the biggest card Brand in the industry. In order for my Visa card to be created, my bank, MegaBank, has a partnership with Visa , so they can use the logo on the front of the card. They also buy the BIN: the first 4 digits of the card number. Each of the card brands have a dedicated range, and they all know which range belongs to which brand. That is how the brand is identified.
My Visa card is only as powerful as it is known by all the banks and the merchants around the world. In order for this to happen, Visa must connect all the banks and all the merchants in one network.
So in order to test how good my Visa Card is, I go to an ATM that belongs to a bank where I do not have an account: MiniBank. This ATM is connected to MiniBank just like the ATM above is connected to my bank, MegaBank. So I go to the ATM, stick my card in, and I want to withdraw some cash. What happens next is the same as a domestic ATM, the ATM reads the card details from the CHIP and asks its own bank, MiniBank, for money. But MiniBank does not have any account records for such my card, because
ISO8583 Message Types for Transaction Processing
Run the neaPay ISO8583 simulator
Cards and Banks Training
Log Files in BASE24 classic
BASE24 classic vs BASE24-eps
BASE24 documentation to read
BASE24 classic interview questions
EMV explained for programmers
Enabling traces in the payments simulator
BASE24 classic screens examples explained
BASE24-eps interview questions
PCI compliant with neapay switch
First steps with BASE24 Classic
Convert ISO8583 to JSON XML SQL
ISO8583 Interface Handler
Convert ISO20022 to ISO8583 ...
Build ISO8583 from scratch
ISO8583 Router by criteria
Authorize cards and ledger
Acquiring host from devices
Generate and issue cards
ISO8583 generic simulator
ISO20022 generic simulator
POS protocols simulator
Web API tester Performance