Understanding CIT and MIT Indicators

Cardholder Initiated Transaction (CIT) and Merchant Initiated Transaction (MIT) are indicators used in transactions to identify whether a transaction was initiated by the cardholder or the merchant. These indicators help card networks, issuers, and processors determine the appropriate authentication measures, risk assessment, and processing flows for each transaction based on who initiated it.

A cardholder initiated transaction is a transaction where the cardholder is an active participant. Here are examples of CIT transactions:

• In-store purchases made at a physical card terminal, where the cardholder consents to saving their card details for future transactions
• One-time online purchases where the cardholder manually enters their card information and consents to saving their card details for future purchases
• Online purchases made by cardholder using a card-on-file

A merchant initiated transaction is a transaction that’s made with a saved payment method for which a cardholder gave prior authorization to the merchant to use. The saved payment method can be used without the cardholder’s active involvement. Here are examples of MIT transactions:

• Online subscriptions like streaming services or autoship orders
• Recurring automatic payments such as utility bills or payment plans

Sending the correct CIT and MIT indicators helps prevent fraud and maintain customer trust. Failing to send the right indicators can lead to negative consequences like declined transactions, financial penalties, and increased fraud and chargebacks.

​

Benefits

Although sending CIT and MIT indicators with transactions isn’t required by Payabli, there are benefits to including them, and potential drawbacks if you don’t.

​

Send CIT and MIT indicators in Payabli

To send CIT and MIT indicators in Payabli, use the storedMethodUsageType and initiator field in the Payment Method section in your transaction request. You can also view a transaction’s CIT or MIT indicator in transaction-related query requests.

How a merchant saves a card and uses it later depends on their business processes. In the next two sections, we’ve outlined the most common scenarios: save the card and charge later, and charge and save the card at the same time.

​

Charge later

Customers sign up with the merchant and save a payment method for future use, but aren’t charged immediately. Later, the customer is charged using the saved payment method. This first charge could happen when their plan begins, or the time when their first subscription order is sent or first service is provided.

​

Charge at sign up

When signing up with the merchant, customers save their payment method for future use, and they’re charged their first payment as part of the sign up process. Customers give their card information for the payment, payment is processed, and Payabli tokenizes and saves the card information. Future payments are then processed with the saved payment method.

​

One-time transactions

Sometimes, a customer wants to use their saved payment method to make a one-time purchase outside of their subscription or recurring payment. The following are some example scenarios:

• A customer’s gym membership is paid monthly using a saved card. The customer wants to make a one-time purchase of a block of classes, and wants to pay with their card on file.
• A customer’s media subscription is paid monthly using a saved card. The customer wants to rent a game, and wants to pay with their card on file.
• A customer’s landscaping service is paid monthly using a saved card. The customer wants to make a one-time purchase of hedge shaping and pay with their card on file.

Depending on how the merchant has designed their workflow in their web or mobile app, and their customer agreements, these purchases could be initiated by the customer themselves, or the customer could authorize the merchant to automatically charge to the saved card.

​

Customer initiates the payment

If a customer initiates the one-time payment from the merchant’s web or mobile app, use the /getpaid or /authorize endpoint to make or authorize the transaction sending the saved payment method ID as the storedMethodId. To correctly qualify the transaction as a subsequent CIT transaction, send initiator = “payor” and storedMethodUsageType = “unscheduled”.

If the request message contains only initiator = “payor”, then Payabli detects the intent and sets storedMethodUsageType to “unscheduled”` and treats it as a subsequent CIT transaction.

If neither initiator or storedMethodUsageType are sent, Payabli defaults to initiator = “merchant” and storedMethodUsageType = “unscheduled”. This qualifies the transaction as a subsequent MIT transaction, which isn’t accurate, because it’s a CIT transaction.

​

Merchant initiates the payment

If the merchant initiates the one-time payment, use the /getpaid or /authorize endpoint to make or authorize the transaction sending the saved payment method ID as the storedMethodId. To correctly qualify the transaction as a subsequent MIT transaction, send initiator = “merchant” and storedMethodUsageType = “unscheduled”.

Payabli recommends sending both initiator and storedMethodUsageType to qualify the transaction correctly. However, when no indicators are sent, Payabli defaults to initiator = “merchant” and storedMethodUsageType = “unscheduled”. In this case, the default values correctly classify the transaction as a subsequent MIT transaction.