Understanding CIT and MIT indicators

Applies to:DevelopersPartnersPaypoints

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.

Regulatory compliance

Payabli isn’t supported in regions that require CIT and MIT indicators for regulatory compliance. We’ve included this information for educational purposes.

PSD2 and SCA: In regions governed by regulations like the Payment Services Directive 2 (PSD2), transactions must comply with Strong Customer Authentication (SCA) requirements. Sending the wrong indicators can result in fines and penalties.
Global compliance: Regions have different regulations for electronic payments. Sending the correct indicators can help you stay compliant with local laws.

Fraud prevention

Accurate risk assessment: Card networks and card issuers use CIT and MIT indicators to help assess a transaction’s risk. CIT transactions involve active cardholder participation, which allows for real-time fraud checks. MIT transactions depend on the initial authorization and might follow different fraud detection protocols.
Security measures: Incorrect indicators might bypass typical security checks, which can increase the risk of fraud.

Example

The card network or card issuer’s fraud detection mechanism detects something suspicious and finds that the initiator value is merchant. They can decline the transaction, and send a notification by text, email, or push notification to let the cardholder know about the suspicious activity.

If the initiator value is payor, then the card network or issuer knows that the cardholder is present at the time of the transaction. They may hold the transaction and wait for the cardholder to approve it by responding to a notification. If the response is received within a reasonable period, then the transaction is approved. Otherwise, the card network or issuer can decline the transaction and let the cardholder know about the suspicious activity.

If you know how the transaction was initiated, send the correct initiator value to trigger the proper security measures. If you don’t send values, Payabli defaults to unscheduled and MIT.

Allowing Payabli to send default values may not trigger the correct fraud detection and security measure.

Transaction processing and routing

Fee calculation: Interchange and other processing fees can differ between CIT and MIT transactions. Using the wrong indicators can lead to incorrect fee calculations, which can affect you financially.
Authorization and Settlement: Card networks process CIT and MIT transactions differently. Sending incorrect indicators can cause declined transactions, delays, or issues in settlement.

With CIT transactions, the card networks send the transaction to the card issuer for verification. With MIT transactions, the card networks fetch the original transaction from when the card was tokenized for the first time. This verifies the validity of the original transaction and that the merchant is the same before sending the transaction to the card issuer.

Customer trust and experience

Dispute handling: Using the correct indicators can help in disputes. When indicators aren’t accurate, it can complicate chargeback processes and dispute handling, leading to customer dissatisfaction.
Card networks take several things into account when deciding who is liable in a dispute. The following example shows how proper use of the CIT and MIT indicator can help the merchant. If a cardholder disputes a MIT transaction, the merchant must prove that the transaction was legitimate. If the cardholder disputes a CIT, then card issuer won’t be able to pass the dispute to the merchant.
Service continuity: For recurring payments or subscriptions (MIT), making sure that transactions have the correct indicators helps maintain uninterrupted service. Incorrect indicators can cause payment failures that lead to service disruptions and customer churn.

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.

Expand for code examples

$ curl --request POST \
>      --url 'https://api-sandbox.payabli.com/api/MoneyIn/getpaid?forceCustomerCreation=false' \
>      --header 'accept: application/json' \
>      --header 'content-type: application/*+json' \
>      --header 'requestToken: API TOKEN'
> 
>      // This example tokenizes a card method and makes a transaction with one call. 
>      // It sets the indicators to qualify this as an unscheduled CIT
>      
> {
>     "entryPoint": "f743aed24a",
>     "ipaddress": "255.255.255.255"
>     "paymentMethod": {
>         "method": "card",
>         "cardnumber": "4293189100000008",
>         "cardexp": "0924",
>         "cardcvv": "345",
>         "cardzip": "34234",
>         "cardHolder": "John Smith",
>         "initiator": "payor",
>         "storedMethodUsageType": "unscheduled",
>         "saveIfSuccess": true
>     },
>     "paymentDetails": {
>         "totalAmount":20,
>         "serviceFee": 0.00
>     },
>     "customerData": {
>         "customerId": 224,
>         "customerNumber": "888",
>         "billingAddress1": "5127 Linkwood ave"
>    }
> }

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.

Step 1: The card is tokenized, but not charged

Use the /tokenstorage/add endpoint to save the payment method. The API response includes the stored payment method’s ID.

Step 2: Authorize or make a sale with the stored payment method

Use the /getpaid or /authorize endpoint to make the sale or authorize the transaction sending the saved payment method ID as the storedMethodId. To qualify the transaction as a first-time CIT transaction, send initiator = “payor” and storedMethodUsageType = “unscheduled”.

If initiator and storedMethodUsageType aren’t sent, or sent with values different from what Payabli expects, Payabli detects the sequence and defaults to the correct values of initiator= “payor” and storedMethodUsageType = “unscheduled” to help qualify the transaction as a first-time CIT transaction.

Step 3: Process subsequent sales

Use the /getpaid or /authorize endpoint to make a sale or authorize the transaction sending the saved payment method ID as the storedMethodId. To qualify the transaction as a subsequent MIT transaction, send initiator = “merchant” and storedMethodUsageType = “subscription”.

Both initiator and storedMethodUsageType should be sent to qualify the transaction correctly. If you don’t send them, Payabli defaults to initiator = “merchant” and storedMethodUsageType = “unscheduled”. This qualifies the transaction as a subsequent MIT transaction, but without the correct storedMethodUsageType of “subscription”.

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.

Step 1: Make or authorize a transaction and tokenize the card

Use the /getpaid or the /authorize endpoints and include the first payment’s amount and the parameter saveIfSuccess set to true.

To qualify the transaction as a first-time CIT transaction, include initiator = “payor” and storedMethodUsageType = “unscheduled”. The tokenized payment method’s ID is returned in the API response.

Step 2: Authorize or make subsequent sales with the stored 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.