CIT/MIT Compliance Framework guide

This page explains how you can become compliant with the Stored Credential Framework.

CIT/MIT Compliance for Australia and NZ Partners

The Stored Credential Frameworks by Visa, introduces a number of policies and procedures relating to the processing of stored customer credit/debit card information that were previously not required, in an attempt to reduce fraud and improve customer experience and trust. Both merchants and payment facilitators are obligated to adhere to this framework as a way to enforce responsible usage of cardholder data. The same requirements apply for all card types, such as Visa, Mastercard and AMEX.

This framework has already been rolled out globally, and will eventually become mandatory for all merchants and payment facilitators. Further information on the framework can be found in this document from Visa: Visa Stored Credential Framework

Framework Summary

One of the key points of this framework is the differentiation of these two ways that a transaction on a stored card can be triggered:

• Customer Initiated Transaction (CIT) - this is a payment on a stored card that has been actively triggered by your customer themselves (i.e. it involves the active participation of the cardholder).

• Merchant Initiated Transaction (MIT) - this is a payment on a stored card that you as the business have initiated yourself as part of collecting money based upon a pre-agreed contract between your business and the cardholder as part of whatever product or service you are providing them.

In practice, the framework requires doing the following:

• Specifying whether you are processing a CIT or MIT.

• Specifying the type of authorization you are performing.

• Linking all subsequent payments on a stored card using an authorization reference.

Compliance Requirements

There are two critical parts to ensuring compliance with the Stored Credentials Framework:

1. Data Element Configuration

Ensuring all the relevant Data Elements relating to tagging a transaction as a Customer initiated transaction or a Merchant initiated transaction should be properly set.

The first step is to audit all your transaction flows and correctly tag each as a Customer Initiated or Merchant Initiated Transaction. If the first transaction isn't tagged correctly, all the associated recurring transactions will create a chain of non-compliant transactions.

A simpler way to think about it: If a customer is actively participating in the transaction in real-time, that's a Customer Initiated Transaction. Even when using a saved card, if the customer is actively making the purchase, it's still considered a CIT.

2. Specific Data Elements Required for Visa and Mastercard

For Initial Transactions (Both Visa and Mastercard):

1. Credential On File (COF) Indicator

2. Cardholder Authentication

3. Consent Verification

For Subsequent Transactions:

1. Credential On File (COF) Indicator

2. Transaction Identifier

a. For Visa: Network Transaction ID (NTI)

b. For Mastercard: Mastercard Trace ID

3. Transaction Type: Specify the type (RECURRING, INSTALMENT, UNSCHEDULED)

Impacted REST API endpoints

We have built out CIT/MIT compliance on our side for REST API, electronic Direct Debit Request (eDDR) and the Hosted Payment Page (HPP) to assist you in becoming compliant and have highlighted the specific REST API function that require amendment or a change to a different API flow due to depreciation.

• PUT - Add or update a Payers card details - (Depreciation)

• POST - Add or update a Payers card details via token - (Depreciation)

• POST Make a live tokenized card transaction

• POST 3DS - Make a live tokenized card transaction

• POST Make a live card transaction

• POST Generate HPP Token

• POST Generate eDDR Token

• POST Generate Vault Token

  • superseded with POST Generate HPP Token

• POST Process a transaction using saved card details

• POST 3DS - Process a transaction using saved card details

Next Steps

If you are integrated using the REST API, eDDR or HPP, then the following pages will direct you in the small technical uplift required to become CIT/MIT compliant.

• CIT/MIT Compliant Worldpay for Platforms HPP

• CIT/MIT Compliant Worldpay for Platforms eDDR

• CIT/MIT Compliant Partner Software managed payment page REST API

If you are integrated using SOAP API, there is a higher portion of technical uplift required to become CIT/MIT compliant as your application will need to convert a few functions from SOAP to REST. The dedicated SOAP to REST API conversation developer guide is here below:

• CIT/MIT Compliance - SOAP to REST API Conversion Developer Guide

CIT / MIT - FAQ

Q: Do we have to re-authenticate all the existing cards? 

A: At this stage, existing payers with card details stored are not affected and will not need to be re-authenticated. This is subject to change should card scheme mandate this requirement for existing payers and is not particularly in our control. If this does change, we will attempt to provide a solution that impacts the partner and account holders minimally. 
 
Q: Do we have to create $0 transactions for all card updates?  

A: For payment details that are updated moving forward, yes it will require the $0.00 (Zero-Dollar Authentication) to store new card details as part of the CIT/MIT compliance framework. 
 
Q: Do partners need to implement CIT/MIT changes if they only create payer records and do not store card details? 

A: No. Partners who only create payer or customer records (for purposes such as assigning payment references) and do not store any card details fall outside the scope of CIT/MIT requirements.