Community
Among others, the credit card value chain comprises the following entities:
The way it works in the credit card industry, the acquirer owns the POS terminal and rents it to the merchant, who places it in its physical premise. Ergo, even though the common man sees a "POS machine" at a store, the POS is not owned by the storeowner.
Information gathered by merchant
There are three types of credit card acceptance practices followed by merchants:
The information gathered by the merchant differs in each case.
Normal practice
When a credit card is dipped into / tapped on a POS terminal, a lot of information like Card Number (aka PAN or Primary Account Number), Expiry Date, Cardholder Name, Merchant ID, and Transaction Amount are captured. It goes via Leased Line / Internet directly to the acquirer. In theory, the merchant gets none of it.
However, in practice, one or more of the following things happen at the checkout during a credit card payment:
As a result, the merchant does get access to at least a part of the credit card info in a normal credit card transaction.
On a side note, contrary to popular narrative, the SMS alert sent by the issuer bank to the cardholder is NOT proof of payment, only the printout of the chargeslip is.
Not-so-normal practice
It's not widely known that, according to card network rules, credit card number and expiry date are the only two pieces of information required to process a credit card payment. It's entirely up to the merchant agreement between the acquirer bank and merchant whether to use cardholder name, CVV, in the payment workflow. Contrary to what the average credit card holder thinks, CVV, PIN and OTP are there to protect the interest of merchant and issuer bank, not cardholder. That being said, in two factor authentication jurisdictions like India, most credit card payments in practice do involve CVV and PIN / OTP.
With one major exception: MOTO mode. (More on tokenization in a bit.)
Card networks introduced the Mail Order Telephone Order mode of credit card payment to enable people to place orders off of shopping catalogs by mail (i.e. snail mail) or telephone. In the MOTO mode, the customer writes / speaks out the credit card number and expiry date on the order form or telephone respectively and the merchant enters them into their POS terminal (or computer system). The payment goes through without PIN, CVV, OTP or any other form of two factor authentication.
Even as recently as four years ago, MOTO accounted for 7.3% of US retail sales (as against 9.7% for ecommerce).
https://twitter.com/s_ketharaman/status/1172427263779803136
Surprisingly, even though Catalog Shopping never took off in India, the enabling MOTO mode works on Indian POS terminals - despite the fact that India is a 2FA jurisdiction. I've used it to pay monthly fees for my coworking office when I was traveling on the due date. It's also used by magazines for subscriptions e.g. FORTUNE magazine, as you can see from the following exhibit.
In a Mail Order Telephone Order (MOTO) transaction, the merchant gets to know the credit card number, expiry date and cardholder name.
Sharp practice
Then there are sharp practices followed by some merchant establishments viz.:
In these cases, the merchant gets to know the entire credit card info.
Information gathered by bank
The issuer bank receives credit card number and expiry date from the merchant's POS, which it uses to authorize (or decline) the payment.
As we saw earlier, the POS also collects cardholder name, merchant ID, purchase value, and other information, all of which is available to the issuer bank.
If the store is an outlet of a chain, banks get to know the address of the chain's HQ that signed the merchant agreement (but not the address of the specific store at which the credit card was used).
Banks don't know what items (i.e. SKUs) were purchased. While they know the total bill value, they do not get to know the the SKU-wise rate or quantity. Exception: Some banks offer customized merchant agreements where merchants get a disount on MDR if they share such info with the bank. (For the uninitiated, Merchant Discount Rate (MDR) aka Merchant Service Charge (MSC) is the fee incurred by merchants to have their credit card transactions processed by the credit card company. It's typically 2-3% of the transaction value.)
Tokenized credit card
Increasingly, credit cards are used in their tokenized form e.g. ApplePay, merchant websites that are "ready" for RBI Reg CofT.
It's not clear what information reaches the issuer bank if the credit card is used in this form.
Some industry players say token obfuscates the credit card number, thereby rendering it impossible for the issuer bank to carry out CVV, volume and velocity checks, three key fraud detection and prevention algorithms.
https://twitter.com/s_ketharaman/status/1695768417142296755
However, when asked how the issuer bank is able to carry out basic authorization check without knowing the credit card number, they don't seem to have an answer. For the uninitiated, authorization is the answer to the question "Is there enough credit limit in the credit card account to honor the transaction?"
As I highlighted in Credit Card Versus Debit Card / UPI / A2A (hyperlink to post on my company website removed to comply with Finextra Community Rules but this post should appear on top of Google Search results when searched by its title + "GTM360"), credit card and debit card differ from each other in many significant ways. But, in the context of this post, whatever I’ve said about credit card above is equally applicable to debit card.
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Eimear Oconnor COO at Form3 Financial Cloud
07 November
Karla Booe Chief Compliance Officer at Zeta Services Inc.
Kyrylo Reitor Chief Marketing Officer at International Fintech Business
06 November
Konstantin Rabin Head of Marketing at Kontomatik
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.