Payments 101 — A beginner’s guide to payments terminology
Indian fintech space has seen tremendous growth in the past few years, with more than $4.5 billion raised by startups from this sector in the first eight months of 2021 alone. The solutions in Indian digital payments are one of the most advanced in the world, and this is a great place to be in, given the kind of impact one can bring in.
This was the reason I made a career switch early this year. I wanted to be a part of an industry where we are building solutions that would be first in the world and hence I decided to join Pinelabs (leading fintech player) in their Online product team.
When you join a payments company or interact with someone from the payments domain, you will quickly notice that this space is filled with Jargons. You may get headaches trying to decipher the terminologies thrown at you. Luckily I have a fantastic team full of payment industry experts here at Pine Labs, who know in and out of payments and can explain any topic in straightforward terms with a full historical depth around it.
This blog is a compilation of the most used terms in the payment industry. It will be useful for anyone uninitiated with a term used in payments who want to revise what an acronym stands for or want to amp up their vocabulary and sound smart in a meeting.
The list keeps on growing and will be updated as and when I come across a new jargon.
Payment Processing
Four Party Model
Four Party Model
This would be the most popular payment processing framework used to describe how a card transaction takes place, as in what happens when you swipe your card at a merchant store. It explains how information is passed on through different entities in the model during a payment transaction
First, let’s understand the different entities in the model
- Cardholder — The one who owns the card and swipes the card at the merchant
- Merchant — The entity which is selling the good to the customer and accepting the payment from the customer
- Acquiring bank — The bank for the merchant processes the digital payment transaction for the merchant by connecting to the issuer during the transaction. The bank which processes the transactions for the Merchant. In a four/three-party model, the acquirer is the entity that has a relationship with the merchant. Example HDFC, Axis, ICICI, RBL, SBI
- Issuing Bank — The bank for the customer, which performs verification whether the cardholder is the owner of the card (authentication), checks whether the customer has enough balance (for debit) or enough credit limit (for credit card) and responds whether it is good to go with the transaction or not. The issuer is the bank that issues credit or debit cards to the end customer. In a four/three-party model, the issuer is the entity that has a relationship with the end customer. Issuers bear the maximum risk and get the highest cut in the MDR. Example HDFC, Axis, ICICI, SBI, Canara Bank etc.
- Network/Card scheme — It connects the issuer and acquirer during a payment transaction. It helps transaction card details securely from the acquiring bank to the issuing bank and back, facilitating the payment transaction. When a card is s, it maintains a directory server mapping BIN to issuer banks so that the transaction can be routed to the right issuing bank. Example: Visa, MasterCard, RuPay (Indian card payment network), Amex
- Payment Gateway/PoS — The technical solution provider for the merchant to accept the payment by connecting to the acquirer during the payment transaction
To summarise, the following steps happen in a four-party model
- Customer swipes the card at the PoS terminal for an offline merchant or Payment gateway for an online merchant
- PoS terminal/Payment gateway connects with the acquiring bank to process the transaction
- Acquiring bank connects with the Directory server of the network. The network then checks the issuing bank for this card using the first 6–9 digits present in the Card Number.
- Issuing Bank does the necessary checks and balances on account of the customer to verify card holder’s identity and account balance
- Acquiring bank returns success to the PoS/Payment gateway after the money is successfully debited from the customer account
Three party model
The same model as above, the difference is that acquiring bank and issuing bank is same. Transaction does not have to be routed to the network to get which issuing bank it is.
ON-US transaction
A transaction where the acquiring bank and issuing bank are the same. Transaction does not have to be routed to the network to understand the issuing bank for this card.
OFF-US transaction
A transaction where the acquiring bank and issuing bank is different. The transaction has to be routed to the network to understand who is the issuing bank for this card
3DS Secure
3DS or 3D secure is a protocol defined by Visa (Verified by Visa) and Mastercard (SecureCode). The issuing bank must maintain an Access control server, which authenticates the cardholder by an additional factor of authentication like a PIN. This was created to reduce fraud, specifically with online payments.
ACS (Access Control Server)
Issuer bank server which handles authentication needed to follow 3DS
MPI (Merchant Plug-In)
It is acquiring bank server, which facilitates the calls for 3DS to the issuer bank for authentication. It sends card details packed in a Verifying Enrollment request (VEReq) to the directory server of the network. The DS connects with ACS to determine whether the card is enrolled with 3DS or not and responds with a Verifying Enrollment response (VERes). If the card is enrolled, VERes will consist of the URL of the issuer ACS, where the customer is redirected to authenticate themselves.
BIN (Bank Identification Number)
The bank identification number is the first 4/6/9 digits of a card number used to identify the card’s issuing bank.
Directory Server
This is the server hosted by the payment network, which stores the mapping of card BINs to issuers
Payment Switch
This server sits with the Payment gateway and helps dynamically routing (switching) the transaction based on merchant rules. Rules like routing by low cost, by success rates or BIN.
Payment Gateway
The payment gateway connects the online merchant with the acquirer to process the payment transaction. These are provided by banks or networks like HDFC (HDFC FSS), ICICI, Visa (Cybersource) etc.
Payment Aggregator
Payment aggregator connects with multiple payment gateways and provides multiple payment options to the online merchant. The advantage for the merchant here is that with a single integration, they can get multiple payment options. Example: Plural Gateway, PayU, Razorpay
VEReq (Verifying Enrollment Request)
The request from MPI to ACS to check whether the card is enrolled for 3DS or not
VERes (Verifying Enrollment Response)
The response back from ACS to MPI stating whether the card is enrolled for 3DS or not. If the card is enrolled for 3DS, then this consists of the ACS URL where the customer is redirected to authenticate
PAReq (Payer Authentication Request)
If the card is enrolled for 3DS, MPI redirects the browser to ACS and makes a Payer authentication request.
PARes
After a customer authenticates, ACS responds with a payer authentication response which denotes whether the authentication is successful or not. The PARes are sent to the MPI, which includes the transaction status whether the payment is successfully authenticated.
Authentication
Authentication in a digital payment transaction is done to verify whether the cardholder is the card owner. 3DS is a way of verifying a card holder’s identity.
Authorisation
This is a confirmation from the issuing bank on the cardholder’s ability to pay. This will debit the money from the cardholder’s account and put it on hold.
Capture
Capture is a process after authorisation and transfers the money from the customer account to the merchant account. For businesses where the order fulfilment takes a long time or chances of refunds are high (like travel, e-commerce), businesses delay the capture to a later point in time.
Pre Auth
Generally, auth and capture happen consequently, here only auth happens and capture happens at a later point in time. This is used by businesses where the order fulfilment takes a long time or chances of high refunds (like travel, e-commerce).
CSC/CVV (Card Security Code/Card Verification Value)
Three digit/4 digit Security code is present on the card (usually at the back of the card). This was used as a secure code to be entered for the card, not present transactions.
AVS (Address verification system)
AVS is an address verification system, another security layer where the card holder’s address is matched with what is present on file with the issuing bank. The numbers existing on the address is matched only, not the complete address
Bps/bips (Basis Points)
Bips, also termed Bps, means basis points that denote 0.01 of a percentage (0.001 of a value). This is commonly used to refer to financial fees, interest rates etc.
ARN (Acquirer reference number)
ARN stands for Acquirer reference number. This is a trace ID to identify where the money is at a given point of time when it is transferred from the issuing bank to the merchant account.
UTR (Unique Transaction Reference)
UTR stands for unique transaction reference. It is similar to ARN but for UPI/NEFT/RTGS transactions.
PAN (Primary Account Number)
PAN stands for Primary account number, which is the 16 digit card number found on credit/debit cards.
PIN (Personal Identification Number)
PIN stands for a personal identification number, which is used to authenticate payment transactions.
API (Application Programming Interface)
Application programming interface through which different services on the internet talk to each other.
Void transaction
The transaction is cancelled before it is settled. A Refund Transaction is done where the money has already been settled.
Message formats/Protocols
ISO 8583
This is a messaging standard through which systems interact with one another for card payments.
The structure of an ISO message is as follows
- Message Type Indicator (MTI) — Denotes the version of ISO 8583 being used, the purpose of the message, communication flow and origin
- Bitmaps — Signifies where data elements are present in the message
- Data elements — Consists of the actual financial transaction information like card number, amount etc.
TCP/IP (Transmission Control Protocol)
Internet protocol defines how data, when transferred across the internet from Point A to Point B, is broken down into packets and verified at the destination to see if all packets have arrived or not.
HTTP (HyperText Transfer Protocol)
Internet protocol defines how the data should be read and processed when it reaches the destination node.
JSON (JavaScript Object Notation)
A language-independent data interchange format. This is a popular way of serialising data for communication with APIs.
{
“card_data”:{
“card_number”:”4012001037141112",
“cvv”:”123",
“card_holder_name”:”User Name”,
“card_expiry_year”:”2023",
“card_expiry_month”:”03",
“is_card_to_be_saved”:true
}
}Example of JSON data
XML (Extensible Markup Language)
It uses tag language like HTML to represent data items. This is harder to read than JSON but considered more secure and provides multiple encoding options
<card_data>
<card_number>4012001037141112</card_number>
<cvv>123</cvv>
<card_holder_name>User Name</card_holder_name>
<card_expiry_year>2023</card_expiry_year>
<card_expiry_month>03</card_expiry_month>
<is_card_to_be_saved>true</is_card_to_be_saved>
</card_data>Example of XML data
Security/Compliance
AFA (Additional factor of authentication)
This is used to denote that the given transaction needs another way of identifying the cardholder’s identity. For example, when the cardholder enters the CVV during a card, not a present transaction that is a single factor of authentication, if now the cardholder is asked to enter an OTP which has been sent on the registered mobile number of the cardholder, that becomes an additional way to identify that the cardholder is the owner of the card. In India, AFA is needed for the card, not present transactions.
EMV (Europay Mastercard Visa)
These are the specifications that led to the design of the chip-based cards. These are more secure than Magnetic stripe based cards given once Magnetic stripes can be copied and used to make payments again and again.
Encryption
It’s a process through which plaintext is converted into a non-readable ciphertext with the help of a public key and an encryption algorithm. This can then be decrypted back to plain text by using a private key. Whenever we save our card on an e-commerce website, card numbers in plain text are never saved, but they are saved in an encrypted format (known as tokens). This is then decrypted by the entity which encrypted this in the first place and sent during the payment flow. Types of encryption algorithms are AES encryption, RSA encryption etc.
Encoding
It’s a process through which data is transformed into one format from another. The idea here is not to make it secure but make it easily readable by other systems. This can be easily decoded back by publicly available algorithms. Types of encoding are Unicode, base64, ASCII
Hashing
It’s a process through which data is converted to a fixed-size sequence of alphanumeric numbers. The unique thing about hashing (compared to encoding or encryption) is that you cannot figure out the original data from the hash data in any way possible. Passwords for login are stored in servers using Hashing. Types of hashing algorithms are MD5, SHA256, SHA512 etc.
PCIDSS (Payment Card Industry Data Security Standard)
This is a security standard formalised by Networks that must be followed by entities (Payment Aggregators, Merchants etc.) that handle card details for payment processing. Any entity which is accepting card information from consumers needs to be PCI compliant. There are around 12 requirements around data storage, encryption, access control of systems, monitoring of network etc. for an entity to be PCI compliant
PADSS (Payment Applications Data Security Standard)
This is similar to PCI DSS but specific to entities creating and selling Payment Applications.
Transaction Types
Card Present Transaction
A transaction where a cardholder can physically show the card to the merchant during the payment is called a Card Present Transaction — for example — Payment at any offline store.
Card Not Present Transaction
A transaction where a cardholder cannot physically show the card to the merchant during the payment is called a Card Not Present Transaction: example — Payment at any e-commerce merchant.
Payment Links
Payment links are a good way to accept payments for use cases where the merchant doesn’t have a website or the scenario does not permit the user to go to a website and make a payment. In such scenarios, the merchant can trigger a payment link to the phone number/email of the customer for the services availed, and the customer can click on the payment link and make the payment.
To Be Continued — — — — -
Thanks for reading. I hope this helped you understand the payments space better and increased your curiosity for good. Next time you swipe a card, I am sure you will admire the tech behind the payment processing that lets you make the payment in a very secure and seamless way, doing multiple interactions in the backend within milliseconds.
(The author of this article is Vipul Nair, AVP — Product Management at Pine Labs. Views expressed in this article are that of the author.)
