# Understanding CIT and MIT indicators > Optimize card processing with proper CIT and MIT indicators. Understand cardholder vs merchant initiated transactions to reduce declines, prevent fraud, and maintain compliance 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. 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. * **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. * **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. * **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. ```bash Unscheduled CIT 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" } } ``` ```bash Subscription MIT 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 makes a transaction with a saved payment method. // It sets the indicators to qualify this as an subscription MIT { "entryPoint": "f743aed24a", "ipaddress": "255.255.255.255" "paymentMethod": { "method": "card", "storedMethodId": "1ec55af9-7b5a-4ff0-81ed-c12d2f95e135-4440", "initiator": "merchant", "storedMethodUsageType": "subscription", }, "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. Use the `/tokenstorage/add` endpoint to save the payment method. The API response includes the stored payment method's ID. 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. 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". ### 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. 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. 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. 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". ### 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.