Cards and Banks Training: Understanding the Core of Payment Processing

Feb 11, 2019 13 min read 69,628 views
Cards and Banks Training: Understanding the Core of Payment Processing

Cards and Banks Training: Understanding the Core of Payment Processing

 

Electronic payments rely on a complex, rapid, and highly regulated ecosystem where every transaction follows a defined choreography. This article provides essential training on the roles of modern bank cards (debit and credit), their usage across various channels, the crucial stages of authorization, and the implications for the key parties involved. Finally, we'll demonstrate how NeaPay's tools are used to test these critical components.

 

Cards and Banks Training: Understanding the Core of Payment Processing

 

Electronic payments rely on a complex, rapid, and highly regulated ecosystem where every transaction follows a defined choreography. This article provides essential training on the roles of modern bank cards (debit and credit), their usage across various channels, the crucial stages of authorization, and the implications for the key parties involved. Finally, we'll demonstrate how NeaPay's tools are used to test these critical components.


 

1. The Roles of Debit and Credit Cards in Commerce

 

While both debit and credit cards use the same card scheme networks (Visa, Mastercard, etc.) and similar underlying message formats (like ISO 8583), their fundamental function and implications are distinct:

Feature Debit Card Credit Card
Funding Source Cardholder's existing bank account funds. A line of credit extended by the issuer.
Authorization Check Real-time balance check is mandatory. Real-time credit limit check is mandatory.
Risk to Issuer Lower risk, as funds are pre-existing.

Higher risk, as the issuer is extending funds.

 

 

Usage Across Different Situations:

 

Channel Debit Card Process Credit Card Process
Point-of-Sale (POS) Transaction is PIN-verified (online debit) or Signature-verified (offline debit). Funds are immediately reserved or deducted. Transaction is PIN/Signature/Contactless verified. Available credit is immediately reserved (Authorization Hold).
E-commerce/Online Verified by OTP (One-Time Password) or a 3D Secure password/biometric challenge. Funds are instantly reserved. Verified by CVV/CVC and 3D Secure. Credit is instantly reserved.
ATM Primarily used for cash withdrawal, balance inquiry, or fund transfer. Requires PIN authentication. Used for cash advance (borrowing against the credit limit), which often incurs immediate fees/interest. Requires PIN authentication.
Telephone Orders (MOTO) Handled as a Card-Not-Present (CNP) transaction, relying on card details and sometimes AVS (Address Verification Service). Handled as a Card-Not-Present (CNP) transaction, with high risk. Relies on CVV and AVS.

 

 

2. The Four Stages of Card Authorization

 

Every electronic payment follows a standard four-step lifecycle from initiation to funding:

 

A. Authorization

 

This is the real-time check for transaction approval.

  1. Cardholder initiates purchase (e.g., taps card at POS terminal).

  2. Merchant sends the Authorization Request to their Acquirer.

  3. Acquirer routes the request to the Card Network (e.g., Visa/Mastercard).

  4. Card Network routes the request to the Card Issuer (the cardholder's bank).

  5. Card Issuer validates the card, checks the account balance/credit limit, applies fraud rules, and generates an ISO 8583 Response Code (e.g., 00 for Approved).

  6. The response travels back through the network to the terminal.

 

B. Batching

 

After an approval, the merchant's terminal or system temporarily stores all authorized transactions in a "batch file." This file is securely submitted to the acquirer, usually at the end of the business day.

 

C. Clearing

 

The Acquirer sends the batch file to the Card Network. The Network performs the interchange process, calculating the interchange fee (paid by the acquirer to the issuer) and passing the transaction data to the respective Issuers for actual funds movement.

 

D. Settlement (Funding)

 

This is the final stage where the money changes hands:

  1. The Issuer debits the cardholder's account (or reduces their credit line) and pays the Acquirer (via the Network).

  2. The Acquirer deposits the funds, minus the merchant discount rate (fees), into the Merchant's bank account.

 

3. Implications and Roles of Payment Parties

 

The payment ecosystem is a four-corner model, each with unique risks and responsibilities:

Party Role & Implication NeaPay Relevance
Merchant Sells goods/services. Bears risk of chargebacks (disputed transactions) and pays fees (MDR) to the Acquirer. Must ensure compliance (e.g., PCI DSS). Tests integration of their POS/e-commerce system with an Acquirer simulator.
Acquirer (Acquiring Bank) Provides the merchant account and manages transactions for the merchant. Bears the risk of a merchant defaulting. Uses NeaPay Switch Router to intelligently route incoming merchant transactions to the correct Card Network or Processor.
Card Issuer (Issuing Bank) Issues the card to the customer and holds their funds/credit line. Bears fraud risk and credit risk (for credit cards). Earns interchange fees. Uses NeaPay Card Issuing Host or Simulator to test its authorization logic, ensuring correct response codes are returned for various scenarios.
Card Networks (Visa/Mastercard) Act as the central clearing hub and set the rules for the entire system. Systems integrate using industry-standard protocols like ISO 8583, which is the core competence of NeaPay tools.

 

 

4. Testing the Stages with NeaPay's Tools

 

NeaPay products are crucial for developing and testing payment systems by simulating every party in the transaction chain.

 

Example Test Scenario: Testing Insufficient Funds

 

A developer at an Acquiring Bank needs to ensure their system correctly handles a decline from the Issuer.

Authorization Stage NeaPay Tool Used Test Configuration/Action
Simulate Issuer NeaPay ISO 8583 Simulator (acting as Issuer Host) 1. Card Data Generator creates a test card with a low balance. 2. Authorization Logic is configured via a script (e.g., in an Excel test case or JavaScript rule) to check: IF Amount (DE 4) > Available Balance THEN Return Code '51' (Not Sufficient Funds).
Initiate Transaction NeaPay POS Device Simulator (acting as Merchant Terminal) A user initiates a transaction for an amount higher than the configured balance. This creates an ISO 8583 Authorization Request (MTI 1100).
Test Acquirer Routing NeaPay Card Switch Router The Switch ensures the 1100 request is correctly routed to the designated NeaPay Simulator based on the card's BIN/Prefix.
Verify Response NeaPay ISO 8583 Simulator The simulator receives the 1100, applies the '51' rule, and sends back an ISO 8583 Authorization Response (MTI 1110) with DE 39 = '51'. The Acquirer system's logs are checked to confirm it processed the '51' correctly and sent the right message to the terminal.

 

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.

From the Bank to the Merchant

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.

 

Transaction from card to your bank

path from card to the bank

From the card to the Bank

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 in the ATM (Automatic Teller Machine)

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.

The Card in the POS (point of Sale)

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.

 

Bank Clearing system diagram

The bank clearing system

From the Bank to the Merchant

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 Brand of the Card: Visa, MasterCard, Amex, Diners, JCB, UnionPay

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.

The Card Brand in action: withdraw money at a foreign ATM

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 

 

Tags:
cards training payments bank tutorial
  Related

Recent Articles on Tutorial

Choose the product you need

ISO8583 Converter REST-api

Convert ISO8583 to rest-api JSON XML SQL &more

ISO8583 Interface Connector

Integrate ISO8583 card schemes and hosts

ISO20022 SWIFT MT MX Converter

Convert and integrate ISO20022 SWIFT MX with MT , ISO8583

ISO8583 Builder Parser Connector

Most simple solution to build and parse ISO8583 messages

ISO8583 Switch Router

ISO8583 or REST-api Switch Router Bin Amount

Card Payments Authorization

Pre-screen, pre-authorize and Authorize cards and ledger

POS Card Acquirer & Aggregator

Acquiring and Aggregating from POS and other devices

Cards Generator Issuing Host

Generate and export card data for cards issuing and test

ISO8583 Simulator

ISO8583 HISO98 HISO87 simulator

ISO20022 Simulator

ISO20022 & SWIFT simulator

POS Simulator

POS protocols simulator

Mobile Banking Simulator

Mobile Banking Testing Simulator

QR Payments Connector

EMV QR Payments Interface Connector

Micropayments Connector

Micropayments Acquiring Connector & Router

ISO8583 Alerts Notifications

Detect Anomalies, Alerts & Notifications

Clearing & Settlement

Generate Convert Import

Request a Quote

Get a free quote, Ask for details
Get help

Documentation

Read Documentation and Start guides

Online Tools

Online Tools Overview