CVV-less Transactions



Card networks aim to enhance domestic card-not-present (CNP) (ecomm) tokenized transactions by making them faster, safer, and more secure. With tokenization, merchants processing transactions on credit cards no longer need to collect CVV for domestic online transactions initiated with tokenized credentials. CVV is only required during initial token provisioning. Once it is Tokenized, the Token along with the Cryptogram serves the purpose.

1/ Tokenized transactions use two factor authentication and encrypted tokens, replacing actual card details.

2/ They are secured with a Token Authentication Verification Value (TAVV) cryptogram for cardholder initiated payments.

3/ Since card networks (e.g., Visa, MasterCard, RuPay) do not transmit CVV to the issuing bank, it cannot be verified, and transactions proceed even if an incorrect CVV is entered.

4/ This approach reduces user friction and increases convenience, as CVV verification is deemed unnecessary for tokenized cards, given the enhanced security measures already in place.

“CVV is the three digit number on the back of a credit card.”

Token Provisioning


In the process flow diagram above, we can see that in step 8, the network returns the token along with the cryptogram, which is essentially the TAVV (Token Authentication Verification Value).

The CVV is required when the card is being tokenized for the first time. Once tokenized, CVV-less transactions can be performed provided the following conditions are met:

1/ The Payment Gateway is technically equipped to integrate and process it.

2/ The Card Network must be equipped with this feature. (While writing this article Visa, Mastercard, Amex, DCI and RuPay are currently supporting this feature).

Transaction Flow

1/ Customer selects the card on the Merchant website.

2/ Instead of entering the CVV, the page directly redirects to the OTP page.

3/ Customer enters the OTP.

4/ Authentication and Authorization process.

5/ Transaction Result (Approval / Decline).

(To understand in detail how Authentication and Authorization happens, please visit following articles on 3D Secure Transactions)

3D Secure Transaction Flow

Disclaimer:

  • The process flow diagrams included in this blog are original creations by the author, Neeraj Singh. Any reproduction or use of these diagrams requires prior permission from the author.
  • Mentions and images of Amazon, Visa, Mastercard, RuPay, Amex, and Discover name/logo are the property of their respective organizations and have been sourced from Google search. All rights to these trademarks and logos belong to their respective organizations.


 

Location: Mumbai, Maharashtra, India

Comments

Post a Comment

Popular posts from this blog

3D Secure (Online / Card Not Present / eComm) Transaction Flow

Image
  While making an online payment, have you ever seen any of the above logo on the OTP page, depending on the card network you use? Visa - Verified by Visa Mastercard - Mastercard SecureCode American Express (Amex) - Safekey Discover and Diners Club International (DCI) - ProtectBuy Have you ever wondered what these mean? All of them are the proprietary names given by their own networks. Basically they are the 3D Secure protocol.😀 Let us decode them today in this article in the simplest form possible (only functional). I will explain the step-by-step transaction flow of eCommerce / Card Not Present (CNP) / Online transactions. When you see any of the above logo on the web page where you are making a payment, it means that your transaction is protected by the 3D Secure protocol. This security protocol adds an additional layer of authentication for online transactions to reduce fraud. If a transaction has happened on 3D Secure protocol, then in case of Chargeback, liability is shifte...
Read more

Decoding Basic Structure of ISO8583 (MTI, Bitmap and Data Elements)

Image
The way we speak in a certain language to make our life easier by communicating with each other, payments also have various languages. For Card Payment it is ISO8583. This language keeps the Card Payment world connected with each other. Let us try to understand the basic structure of this beautiful language in the simplest form ever.  Imagine an ISO8583 message as a structured sentence where different parts tell a story about a transaction. Each message is made up of 1/  MTI (Message Type Indicator) - Like a title it tells you what type of message it is (e.g. a payment request) 2/  Bitmap - A map that shows which parts of the message are included 3/  Data Elements - The actual details of the transaction like the card number, amount and date etc Detailed Explanation 1/ Reading the MTI (Message Type Indicator) The MTI is a 4 digit code that specifies the type of message. For example, 0200 indicates a financial transaction request (authorization) 1.1/ Br...
Read more

Card Payments - Part 1 (Auth)

Image
  Image Courtesy:https://paytechlaw.com/ Card Payments is a very vast domain and covering it through a blog becomes more challenging. This blog aims to give a high-level understanding of Card Payments in the most structured and organized way. Today world is moving at a great pace and hence stress would be laid in bestowing benefits to almost all groups influenced by Card Payments under professional and domestic growth. The topic will focus gradually on exploring the functionality and the mechanism behind this one of the most used methods of the payment system.   Participants Acquirer An Acquirer is a financial institution that processes transactions on behalf of a merchant. It holds the merchant's bank account and facilitates the acceptance of payment cards. Merchant A merchant refers to a business, either physical (Card Present) or online (Card Not Present), where a customer makes a purchase using a card issued by a financial institution (Issuer). The Point of Sale (POS) term...
Read more