"Recurring payments" refer to payments that occur at regular time intervals. For example, when Netflix charges you for a subscription every month, it is a recurring payment. From the user's perspective, the process is simple. You only need a credit or debit card with sufficient funds to make the first payment and start the subscription. Once the subscription starts, the merchant charges you based on the subscription plan until you cancel. But is it just as simple from a technical perspective? And are recurring payments secure? Recurring payments All card payments fall into two categories: Cardholder-initiated payments (CIT). The user (cardholder) initiates the payment.
Merchant-initiated payments (MIT). The merchant initiates the payment without the cardholder's participation. Cardholder-initiated payments (CIT). The user (cardholder) initiates the payment. Merchant-initiated payments (MIT). The merchant initiates the payment without the cardholder's participation. While the cardholder initiates the first recurring payment when starting a subscription, recurring payments are an example of MIT payments because the merchant initiates the subsequent payments without the cardholder's participation. The table below highlights the difference between CIT and MIT payments. Criteria

CIT payments

MIT payments, specifically, Recurring payments



Storing card details

Merchants typically do not store card details. However, if a merchant offers to "remember" a card for future use, they store the card details.

Merchants have to store card details because they need them to initiate subsequent recurring payments.



Cardholder authentication

The authorization request for each CIT payment may contain a cardholder authentication verification value (CAVV).

Only the first authorization request for a recurring payment may contain a CAVV. Merchants must not provide the CAVV in the subsequent recurring payment authorization requests. Criteria

CIT payments

MIT payments, specifically, Recurring payments



Storing card details

Merchants typically do not store card details. However, if a merchant offers to "remember" a card for future use, they store the card details.

Merchants have to store card details because they need them to initiate subsequent recurring payments.



Cardholder authentication

The authorization request for each CIT payment may contain a cardholder authentication verification value (CAVV).

Only the first authorization request for a recurring payment may contain a CAVV. Merchants must not provide the CAVV in the subsequent recurring payment authorization requests. Criteria

CIT payments

MIT payments, specifically, Recurring payments Criteria Criteria CIT payments CIT payments MIT payments, specifically, Recurring payments MIT payments, specifically, Recurring payments Storing card details

Merchants typically do not store card details. However, if a merchant offers to "remember" a card for future use, they store the card details.

Merchants have to store card details because they need them to initiate subsequent recurring payments. Storing card details Storing card details Merchants typically do not store card details. However, if a merchant offers to "remember" a card for future use, they store the card details. Merchants typically do not store card details. However, if a merchant offers to "remember" a card for future use, they store the card details. Merchants have to store card details because they need them to initiate subsequent recurring payments. Merchants have to store card details because they need them to initiate subsequent recurring payments. Cardholder authentication

The authorization request for each CIT payment may contain a cardholder authentication verification value (CAVV).

Only the first authorization request for a recurring payment may contain a CAVV. Merchants must not provide the CAVV in the subsequent recurring payment authorization requests. Cardholder authentication Cardholder authentication The authorization request for each CIT payment may contain a cardholder authentication verification value (CAVV). The authorization request for each CIT payment may contain a cardholder authentication verification value (CAVV). Only the first authorization request for a recurring payment may contain a CAVV. Merchants must not provide the CAVV in the subsequent recurring payment authorization requests. Only the first authorization request for a recurring payment may contain a CAVV. Merchants must not provide the CAVV in the subsequent recurring payment authorization requests. As you can see from the comparison, recurring payments require merchants to store cardholders' card details, which can be a headache. Here, even a minor vulnerability can bring serious risks. How to avoid it? One of the ways to go is tokenization. Tokenization Tokenization is the process of exchanging sensitive card details with a unique token. The token represents the original card details without exposing them. Each token is unique and specific to a merchant. So, tokenization reduces the risk of online attacks and data breaches, making tokens less attractive to fraudsters. To tokenize card details, merchants must integrate services like Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) directly or through third-party service providers. Let's find out how it works. Recurring payments with tokens First payment There are two steps in the payment process. The first step is to tokenize card details. The second step is to request a token cryptogram and provide it during the payment authorization. Step 1 Once the cardholder enters the card details, the merchant requests VTS or MDES to tokenize them. In case of success, the response includes the token and many more: Tokenization request:

Tokenization response:



Card number

Token*



Security code

Token ID



Cardholder name

Token expiry month and year**



Card expiry month and year

Token status (active, inactive, etc.)*** Tokenization request:

Tokenization response:



Card number

Token*



Security code

Token ID



Cardholder name

Token expiry month and year**



Card expiry month and year

Token status (active, inactive, etc.)*** Tokenization request:

Tokenization response: Tokenization request: Tokenization request: Tokenization response: Tokenization response: Card number

Token* Card number Card number Token* Token* Security code

Token ID Security code Security code Token ID Token ID Cardholder name

Token expiry month and year** Cardholder name Cardholder name Token expiry month and year** Token expiry month and year** Card expiry month and year

Token status (active, inactive, etc.)*** Card expiry month and year Card expiry month and year Token status (active, inactive, etc.)*** Token status (active, inactive, etc.)*** The token is a 13 to 19-digit numeric value (very similar to a card number). However, the token is not the same as the card number. The token expiry date might differ from the card expiry date: it can be either earlier or later than the card expiry date. Still, the token expiry date usually matches the card expiry date. Merchants can use only active tokens for payment authorizations. Inactive tokens will result in authorization failures. The status of the token may change during its ongoing use. Typically, merchants store both a token and a token ID. However, they can also choose to store only the token ID. By not storing tokens, merchants avoid one more piece of data that connects to cardholder card details, which helps reduce the scope of PCI requirements to comply with. Step 2 If the token from Step 1 is active, the merchant requests VTS or MDES to get a one-time token cryptogram. The one-time token cryptogram is a unique authentication value for the payment with a token. It is also known as token authentication verification value (TAVV). Get Payment Data (Token & Cryptogram) request:

Get Payment Data (Token & Cryptogram) response:



Token ID

Token





Token expiry month and year





Cryptogram (TAVV) Get Payment Data (Token & Cryptogram) request:

Get Payment Data (Token & Cryptogram) response:



Token ID

Token





Token expiry month and year





Cryptogram (TAVV) Get Payment Data (Token & Cryptogram) request:

Get Payment Data (Token & Cryptogram) response: Get Payment Data (Token & Cryptogram) request: Get Payment Data (Token & Cryptogram) request: Get Payment Data (Token & Cryptogram) response: Get Payment Data (Token & Cryptogram) response: Token ID

Token Token ID Token ID Token Token Token expiry month and year Token expiry month and year Token expiry month and year Cryptogram (TAVV) Cryptogram (TAVV) Cryptogram (TAVV) Before submitting the authorization request, the merchant decides if cardholder authentication is necessary. If it is, subsequently, the merchant sends both TAVV and CAVV in the authorization request, and the merchant's acquirer maps TAVV to field 126.8 and CAVV to field 126.9 in the ISO 8583 payment authorization message. When submitting the payment authorization request, the merchant sets the token instead of the card number, the token's expiry date instead of the card's expiry date, and adds TAVV. The authorization response includes the response code and the transaction ID. The merchant stores the transaction ID and, in case of authorization request approval, schedules the subsequent recurrent payment according to the subscription plan. Subsequent payments For subsequent recurring payment authorization requests, the merchant must include the token, the token's expiry date, and the first (original) transaction ID from Step 2. The merchant must not provide the TAVV in the subsequent recurring payment authorization requests (similar to CAVV). In such a way, the merchant can charge the cardholder until they cancel the subscription. Conclusion Summing up, recurring payments with tokens are safer for everyone. Using tokenization, merchants don't have to store cardholders’ card details, reducing many risks like: Using tokenization, merchants don't have to store cardholders’ card details, reducing many risks like: Data Breaches and Fraud. Even if fraudsters steal the tokens, they cannot use them to make payments elsewhere. Each token is unique and specific to a merchant.
PCI Compliance. Tokenization reduces the scope of PCI requirements, which merchants must comply with. Data Breaches and Fraud. Even if fraudsters steal the tokens, they cannot use them to make payments elsewhere. Each token is unique and specific to a merchant. PCI Compliance. Tokenization reduces the scope of PCI requirements, which merchants must comply with. Overall, tokenization not only reduces the risks but also improves payment efficiency. Payments with tokens have higher authorization rates and lower fraud rates. All this means that they are more reliable and secure.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

How Tokenization Makes Recurring Payments Safer for Merchants and Cardholders

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Don't Fall Into the 'Microservices Are Cool' Trap and Know When to Stick to Monolith Instead

An Introduction to PCI Compliance

Building a MongoDB NoSQL E-Commerce Data Model

Cloud Compliance And Regulation Resources

Handle Sensitive Data Securely with Skyflow

PCI DSS 4.0 is Out! Here's What You Need to Know About the Updates

Don't Fall Into the 'Microservices Are Cool' Trap and Know When to Stick to Monolith Instead

An Introduction to PCI Compliance

Building a MongoDB NoSQL E-Commerce Data Model

Cloud Compliance And Regulation Resources

Handle Sensitive Data Securely with Skyflow

PCI DSS 4.0 is Out! Here's What You Need to Know About the Updates

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps