This is the second text in the series explaining how payment cards and wallets interact. The purpose of this text is to shed more light on a merchant’s role in card processing, maybe even to give some pointers to those who are planning to start accepting cards online or otherwise.
Card acceptor is a company or an individual that is accepting cards as a means of payment for a service or a product. We are going to use the term “card acceptor” rather than merchant, because not all card acceptors are merchants (for example bank ATMs are not merchants). This service can be something very common (like getting a haircut), or it can also be something a bit different (such as withdrawing cash).
No matter what service or product card acceptor provides, it has to have a way to accept payment by a card. “Accepting payment by card” actually means “submitting a card transaction into the interchange network and decoding the card issuer’s reply”. To be able to submit anything into the interchange network the card acceptor first needs to register with it (to get merchant account).
Getting a merchant account
Prospective card acceptors get merchant accounts from institutions which are already members of the interchange network – from acquirers. Each acquirer (usually a bank) is a member of the appropriate card association, and it has an assigned ID. Once the acquirer accepts some company as a merchant, that company gets an assigned ID of their own– merchant ID (MID). Each place where merchant wants to accept cards, also gets different ID of its own – terminal ID (TID). Subsequently, the origin of each transaction is determined by triple of identifiers: acquiring institution ID, merchant ID, terminal ID.
Payment Gateways, Banks and PSPs
It is important to clarify things a little bit. Besides banks, there are other companies offering card acquiring services. Sometimes these companies are called payment gateways, sometimes PSPs (payment service providers). These companies usually have contracts with banks to use their payment gateways.
PSPs collect card data from merchants and forward them to bank payment gateway, and similarly they decode response from bank payment gateway and forward it back to merchant. PSPs usually do more than just forwarding data – their systems offer additional services which the bank’s payment gateway doesn’t offer. For example, PSP might offer a test environment that the bank is lacking, or it might have automated subscription billing engine and similar. In general, using PSP is a good idea to save time and to start accepting cards quickly. If later turns out that money volume is big enough to consider working directly with bank, later you can remove PSP from equation.
In further text I will be using term “bank” to refer to both PSP and acquiring bank (some PSPs can finish contracts with bank for you, some can’t so you still need to deal with bank as well, to avoid confusion I will be writing “bank” when I mean company who is doing acquiring for you).
Applying for Merchant Account
When a company wants to start accepting card payments, it generally needs to provide specific details about its business model to the bank. The bank might ask for information about the ownership structure of the company and the anticipated number of card transactions. This includes details such as the average expected value of transactions and the number of transactions expected each month.
Additionally, the company must meet certain requirements set by the card networks. For example, the price for products or services when paying with a card must be the same as the price when paying with cash. The company also needs to display the logos of the card schemes to indicate accepted payment methods.
Once the company has completed all these requirements or is to fulfil them, the bank will send their offer, which will usually include a fixed fee for each transaction processed and a percentage fee. The percentage fee is usually somewhere between 2% and 4%, while the fixed fee depends on the bank, or the country. Following this, the company will proceed to sign a contract with the bank. Once the contract is in place, the company will be assigned a Merchant ID (MID) and a Terminal ID (TID), and it will gain access to the bank’s payment gateway.
After successfully completing a few test transactions, the company will be able to start accepting card payments and it will be able to submit card transactions to the interchange network (via bank’s payment gateway).
To submit a card transaction, an acceptor first needs to get access to the card data. The most important of all the card data, is the one that identifies the card itself – that is the card number, which is also known as PAN (short for “Primary Account Number”). This number is most often 16 digits long and it is printed on the card. In addition to the Primary Account Number (PAN), the acceptor is required to provide additional data. This data is necessary to prove to the issuer that the acceptor genuinely has access to the physical card or that the cardholder personally provided the card details. This helps verify that the cardholder has also authorized the transaction.
Getting card data
Depending on the nature of its interaction with customers, a card acceptor can obtain card data directly from the card itself (in cases where both the cardholder and the card are physically present, known as CP transactions). Alternatively, the acceptor might receive card data from the cardholder (hopefully real), without having physical access to the card (this is referred to as CNP transactions, where the card or cardholder is not present).
CP – Card Present
For card present transactions, card data is mostly read by special device (POS terminal) either from the card’s chip or using a contactless interface (which is similar to chip, but slightly more limited in capabilities). There is also a way to read card data from the magnetic stripe on the card, however, due to security concerns, many issuers are discontinuing this method of reading card data. Another method, which is largely no longer in use today, is known as manual PAN entry. This involves either the cardholder or the merchant directly typing the card number into a point-of-sale (POS) machine.
An important aspect to consider regarding card present transactions and the data retrieved from the card is that it’s not just the PAN that gets read. There are additional cryptographic data points generated by the card’s chip (or stored on the magnetic stripe) that are also read. These cryptographic elements play a crucial role in verifying the authenticity of the card data.
CNP – Card Not Present
For card not present transactions, the card acceptor relies on the cardholder to provide card data. There are two types of card not present transactions:
- Mail and telephone orders (MOTO), and
- Internet commerce (e-commerce, E-COMM).
These two types of transactions are quite different. For mail and telephone orders, the cardholder will usually just communicate the card number and card’s expiry date to the card acceptor. In certain phone orders, if specialized software is used, the cardholder might input the card number, expiration date, and CVC code directly on their phone. However, for other orders, they may only need to communicate the card number and expiration date verbally.
In online commerce, the cardholder needs to provide their card details. In some regions, an additional layer of authentication is required, called 3-D security. This is protocol that evolved from earlier, independent methods of authentication, such as Verified by Visa, SecureCode by MasterCard, or similar schemes. This extra step helps enhance security during online transactions. The purpose of this authentication is to verify that the person making the transaction is the legitimate owner of the registered card. Once the cardholder authenticates themselves, they cannot later dispute the transaction with the bank by claiming that someone else used their card.
Submitting a transaction for processing
When it comes to submitting a transaction, the process is slightly different depending on how the card was accepted: if the card was accepted via a POS machine, the POS machine sends the card number, all security related parameters and the value of transaction (transaction amount) to the payment gateway of the bank that provided the POS machine. This payment gateway sends message through interchange network and waits for a reply from the issuer. Once the reply has been received the payment gateway decodes it, and it sends a reply to the POS machine using its proprietary protocol, which shows appropriate message to the merchant and the cardholder.
For e-commerce transactions, the card acceptor’s system (website application) needs to submit the card details obtained from the cardholder, optionally with additional crypto parameters obtained through the 3-D authorization process. This information is then sent to the acquirer’s payment gateway, usually using some proprietary protocol which might be based on SOAP, JSON, POX or any other of many formats. The payment gateway accepts this message, converts it into a format expected by the card scheme, and sends it for execution. After that it waits to receive the issuer’s reply, decodes it and sends the reply back to the website application.
The next step in transaction execution is the acquiring payment gateway, and that will be the theme of the next article.
Leave a Reply
You must be logged in to post a comment.