CIT and MIT Transactions

CIT (Customer Initiated Transaction) and MIT (Merchant Initiated Transaction) are classification types used in payments to help card networks, payment gateways, and merchants distinguish how a transaction was initiated. These terms are important for recurring billing, card-on-file, and compliance with card network rules.

CIT (Customer Initiated Transaction)

Definition: The transaction is started by the customer (cardholder) themselves.

Typical Use Cases: Standard e-commerce checkout, first payment in a subscription, adding a card to file, making a payment via a website/app.

Authorization: Requires active cardholder authentication (entry of card details, 3DSecure, etc.).

Network Treatment: Treated as a “fresh” or original payment, often with stronger authentication.

Gateway Example: When using NetValve Token, you can indicate CIT with:

"additionalData": {
  "requestTransactionType": "RECURRING",
  "recurringScheduleType": "CIT_COF",
  "recurrenceMode": "Initial",
  "schemeTransactionLinkIdentifier": "mastercard-tlid-if-already-available"
}

MIT (Merchant Initiated Transaction):

Definition: The transaction is started by the merchant without direct customer interaction at the time of charge.

Typical Use Cases: Recurring billing (subscriptions), automatic rebills, installments, delayed/capture, no-show, credential-on-file (COF) charges.

Authorization: Based on an agreement between customer and merchant, the customer’s credentials are stored securely (tokenized).

Network Treatment: May be exempt from certain types of authentication (PSD2/SCA), but must reference the original CIT.

Gateway Example: In NetValve API calls, you indicate MIT with:

"additionalData": {
  "requestTransactionType": "RECURRING",
  "recurringScheduleType": "MIT_SUBSCRIPTION",
  "recurrenceMode": "Repeated",
  "schemeTransactionLinkIdentifier": "mastercard-tlid",
  "credentialOnFileTransaction": "original-cit-network-transaction-id"
}

credentialOnFileTransaction is optional. Leave it out when the original CIT was processed through NetValve and NetValve will look up the Network Transaction ID from the card's earlier transactions. See Network Transaction ID below.

How to Use CIT and MIT in NetValve Integration

First Payment: Process as a CIT (customer is present, card is verified).

Subsequent Recurring Payments: Process as MIT, referencing the original CIT, "requestTransactionType": "RECURRING".

Mastercard Transaction Link Identifier

For Mastercard card-on-file transactions, schemeTransactionLinkIdentifier contains the Mastercard Transaction Link Identifier (TLID). Send this field in additionalData when your integration already has the TLID, such as when a previous CIT was processed through another PSP or when your system manages the CIT schedule.

NetValve returns schemeTransactionLinkIdentifier in transaction responses, inquiry/detail responses, webhooks, and transaction exports when it is available from the processor response.

For processor mapping:

Processor	Mapping
TSYS	Mastercard TLID is read from TSYS additional transaction specific data for Mastercard and sent to TSYS as group G3v091 when supplied in the request.
Shift4	Mastercard TLID is read from Shift4 response field z70.

credentialOnFileTransaction remains the existing Network Transaction ID field. Use schemeTransactionLinkIdentifier only for the Mastercard TLID.

Network Transaction ID

additionalData.credentialOnFileTransaction carries the Network Transaction ID (also called the scheme transaction ID or TRN) of the original CIT that a merchant-initiated payment refers back to. It is a reference value, not a flag.

Scenario	What to send
CIT (customer present)	Omit the field.
MIT where the original CIT was processed through NetValve	Omit the field. NetValve looks up the Network Transaction ID from the card's earlier transactions.
MIT where the original CIT was processed outside NetValve	Send the Network Transaction ID you received from the other processor.

Never send CIT, MIT or any other literal in this field

Values like CIT or MIT are passed to the processor as the transaction reference. The processor rejects them and the payment is declined. Sending any value in this field also stops NetValve from looking up the correct Network Transaction ID. Use requestTransactionType, recurringScheduleType and recurrenceMode to indicate how a transaction was initiated.

Why Is This Important?

• Meets requirements for card network rules and regulatory compliance (like PSD2 in Europe).
• Reduces likelihood of declined recurring or unscheduled merchant-initiated payments.
• Ensures correct liability shift and chargeback rights.

RecurringScheduleType Values

Value	Description
CIT_COF	Customer Initiated - Credential on File
CIT_STANDING_ORDER	Customer Initiated - Standing Order (variable amount, fixed frequency)
CIT_SUBSCRIPTION	Customer Initiated - Subscription (fixed amount and fixed frequency)
MIT_UNSCHEDULED_COF	Merchant Initiated - Unscheduled Credential on File
MIT_STANDING_ORDER	Merchant Initiated - Standing Order (variable amount, fixed frequency)
MIT_SUBSCRIPTION	Merchant Initiated - Subscription (fixed amount and fixed frequency)

RequestTransactionType Values

Value	Description
RECURRING	Recurring transaction type
ECOMMERCE	eCommerce transaction type