With the increasing popularity of subscription-based services, e-commerce, and digital payments, the need for a clear distinction between Customer Initiated Transactions (CIT) and Merchant Initiated Transactions (MIT) has become crucial for card networks to provide a better experience for customers, merchants, and issuers. Visa introduced a mandate that intends to improve the security, transparency, and efficiency of recurring payments and other transactions where merchants are initiating payments.

Customer Initiated Transactions (CIT) are transactions initiated by the cardholder, typically through an e-commerce website or a mobile app. Examples of CITs include one-time online purchases, bill payments, and initial transactions to set up a recurring payment agreement. These transactions usually require the cardholder's active involvement and authentication.

Merchant Initiated Transactions (MIT) are transactions initiated by the merchant without the cardholder's direct involvement, based on a prior agreement with the customer. Examples of MITs include recurring subscription payments, installment payments, and account top-ups. These transactions do not require the cardholder's active involvement or authentication at the time of the transaction, but the cardholder must have provided consent during the initial agreement set up.

Visa's CIT and MIT rules outline specific requirements for merchants and issuers to follow, including:

1. Clear identification of transaction types: Merchants must clearly identify and distinguish between CITs and MITs during the transaction process.
2. Enhanced authorization and authentication: Merchants must use specific indicators to flag MITs and comply with SCA requirements for CITs.
3. Transparency and communication: Merchants must inform customers about the terms and conditions of recurring payments or other MIT agreements, and provide notifications of upcoming charges.
4. Dispute rights and protections: Visa's mandate ensures that customers have the right to dispute unauthorized MITs and that issuers have the necessary information to resolve disputes effectively.

We have added new parameters to our API that can be used to comply with this mandate.

📘

Note

Currently these parameters can be used by merchants processing with Chase Paymentech, Fiserv RapidConnect, Elavon, FIS, and First Data Omaha.

CIT/MIT API Parameters

These are the parameters that can be sent to QSAPI to mark a transaction as customer or Merchant initiated.

Example Transactions

Below are some example transactions where these parameters are used.

• SALE and AUTHORIZATIONS (greater than $0) transactions do not contain any default values for these parameters but can be included in the API request.
• STORE and $0 AUTHORIZATION transactions have default values of:
  • stored_credential_indicator of Initial
  • transaction_initiator of Customer
  • card_on_file_schedule_indicator of Unscheduled

SALE Transaction Using CIT/MIT Parameters

This transaction is a typical SALE transaction utilizing the parameters above to communicate to the processor that the transaction was initiated by a merchant's customer, that it is the first (or initial) transaction, and that it was an unscheduled transaction.

curl --location 'https://cert.payconex.net/api/qsapi/3.8' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'account_id=180000000000' \
--data-urlencode 'api_accesskey=b5ac4d76ef7073e66a6330f296ddbda5' \
--data-urlencode 'response_format=JSON' \
--data-urlencode 'transaction_type=SALE' \
--data-urlencode 'tender_type=CARD' \
--data-urlencode 'card_number=5405980000337223' \
--data-urlencode 'card_verification=123' \
--data-urlencode 'card_expiration=1233' \
--data-urlencode 'first_name=test' \
--data-urlencode 'last_name=tester' \
--data-urlencode 'transaction_amount=55' \
--data-urlencode 'transaction_initiator=Customer' \
--data-urlencode 'stored_credential_indicator=Initial' \
--data-urlencode 'card_on_file_schedule_indicator=Unscheduled'

Reissuing transactions using CIT/MIT Parameters

In this example scenario, a merchant is processing a scheduled recurring transaction on behalf of their customer by reissuing a SALE using a previous transaction_id.

• stored_credential_indicator is set to Subsequent because there was an original transaction.
• transaction_initiator is set to Merchant because the merchant is processing the recurring on behalf of their customer.
• card_on_file_schedule_indicator is Schedulded.

curl --location 'https://cert.payconex.net/api/qsapi/3.8' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'account_id=180000000000' \
--data-urlencode 'api_accesskey=719fa19a4c5adf51425ce5c98fecc264' \
--data-urlencode 'transaction_amount=1.00' \
--data-urlencode 'transaction_type=SALE' \
--data-urlencode 'tender_type=CARD' \
--data-urlencode 'response_format=json' \
--data-urlencode 'first_name=Test' \
--data-urlencode 'last_name=Tester' \
--data-urlencode 'token_id=000000000001' \
--data-urlencode 'reissue=1' \
--data-urlencode 'transaction_amount=25'
--data-urlencode 'transaction_initiator=Merchant' \
--data-urlencode 'stored_credential_indicator=Subsequent' \
--data-urlencode 'card_on_file_schedule_indicator=Schedulded'

In this example scenario, a merchant is processing an unscheduled transaction on behalf of their customer by reissuing a SALE using a previous transaction_id.

• stored_credential_indicator is set to Subsequent because there was an original transaction.
• transaction_initiator is set to Merchant because the merchant is processing the transaction on behalf of their customer.
• card_on_file_schedule_indicator is Unscheduled.

curl --location 'https://cert.payconex.net/api/qsapi/3.8' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'account_id=180000000000' \
--data-urlencode 'api_accesskey=719fa19a4c5adf51425ce5c98fecc264' \
--data-urlencode 'transaction_amount=1.00' \
--data-urlencode 'transaction_type=SALE' \
--data-urlencode 'tender_type=CARD' \
--data-urlencode 'response_format=json' \
--data-urlencode 'first_name=Test' \
--data-urlencode 'last_name=Tester' \
--data-urlencode 'token_id=000000000001' \
--data-urlencode 'reissue=1' \
--data-urlencode 'transaction_amount=25'
--data-urlencode 'transaction_initiator=Merchant' \
--data-urlencode 'stored_credential_indicator=Subsequent' \
--data-urlencode 'card_on_file_schedule_indicator=Unscheduled'

In this example scenario, a customer initiates a one-time transaction with a merchant. The merchant has a previously generated transaction_id that the customer can select for use as a token_id in a SALE transaction.

• stored_credential_indicator is set to Subsequent because there was an original transaction.
• transaction_initiator in this scenario is Customer because the merchant is processing the transaction on behalf of their customer.
• card_on_file_schedule_indicator is Unscheduled.

curl --location 'https://cert.payconex.net/api/qsapi/3.8' \
--header 'Accept: application/json' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'account_id=180000000000' \
--data-urlencode 'api_accesskey=719fa19a4c5adf51425ce5c98fecc264' \
--data-urlencode 'transaction_amount=1.00' \
--data-urlencode 'transaction_type=SALE' \
--data-urlencode 'tender_type=CARD' \
--data-urlencode 'response_format=json' \
--data-urlencode 'first_name=Test' \
--data-urlencode 'last_name=Tester' \
--data-urlencode 'token_id=000000000001' \
--data-urlencode 'reissue=1' \
--data-urlencode 'transaction_amount=25'
--data-urlencode 'transaction_initiator=Merchant' \
--data-urlencode 'stored_credential_indicator=Subsequent' \
--data-urlencode 'card_on_file_schedule_indicator=Unscheduled'