Credentials-on-File (MIT/CIT)

When processing Credential-on-File (CoF) transactions—such as subscriptions, installments, or saved-card checkouts—merchants must clearly communicate to the issuing bank whether the transaction is Cardholder-Initiated (CIT) or Merchant-Initiated (MIT).

Failing to pass the correct stored credential indicators, initiation flags, and original transaction IDs can cause transactions to "downgrade," resulting in higher interchange fees and an increased risk of declines.

To ensure that transactions qualify for the best possible rates, use the following fields to accurately tag your CoF traffic.

1. Core Stored Credential Fields

When sending a transaction with a saved card (or saving a card for the first time), merchant's must state the initiation and schedule.

indicator (String): Indicates if this is the first time the card is being stored or a subsequent use.
- 1 = First time (Visa/Discover only).
- S = Subsequent charge (Visa, Mastercard, Discover).
initiation (String): Indicates who is initiating the transaction.
- C = Cardholder Initiated (CIT) - e.g., the customer is actively checking out on your website.
- M = Merchant Initiated (MIT) - e.g., your server is running a nightly billing script.
schedule (String): Indicates the agreement structure.
- S = Scheduled (e.g., a fixed $10/month subscription).
- U = Unscheduled (e.g., an automatic account top-up when the balance falls below $5).

2. The E-Commerce Flag

The ecommerce_flag dictates the transaction environment. To prevent downgrades, pair MIT/CIT fields with the correct integer:

2 (Recurring): Fixed, scheduled subscriptions (MIT).
3 (Installment): Fixed number of scheduled payments (MIT).
7 (E-commerce SSL): Standard online checkout (CIT).
5 or 6 (3D Secure): Authenticated online checkout (CIT).

3. Network-Specific Trace Fields (Important for MIT)

To properly qualify subsequent MIT transactions, Visa and Discover require merchants to link the new charge to the original CIT transaction where the cardholder gave you permission to store the card.

transaction_id (String): (Visa & Discover Only) An identifier assigned by the card brand during the initial setup transaction. You must capture this from your initial API response and pass it in all subsequent MIT requests to uniquely link the records.
original_amount (Number): (Discover Only) The approved amount of the original setup transaction. Without this, subsequent Discover MIT transactions may be rejected.
authorization_type_override (String): (Visa Only) Used for specific edge cases.
- R = Reauthorization of Prior Amount
- A = Resubmission
- E = Estimated Authorization
- [Space] = Default

Examples

Example 1: Initial Setup (CIT)

The cardholder is on your website, entering their card details for the first time to start a monthly subscription. Note: You must save the transaction_id returned in the response to this request!

{
  "amount": 10.00,
  "transaction_type": "00",
  "cc_number": "4111111111111111",
  "cc_expiry": "1225",
  "ecommerce_flag": 7, 
  "indicator": "1",
  "initiation": "C",
  "schedule": "U"
}

Example 2: Subsequent Recurring Charge (MIT)

The next month, the customer is not online, and your server is automatically billing the stored card of file (using a Tagged Transaction) for their subscription. Notice how we pass the Visa transaction_id to link the chain.

{
  "amount": 10.00,
  "transaction_type": "30",
  "transaction_tag": "2150127336",
  "authorization_num": "ET184355",
  "ecommerce_flag": 2, 
  "indicator": "S",
  "initiation": "M",
  "schedule": "S",
  "transaction_id": "837492837482938"
}

📘
Pro-Tip for Zero-Dollar Authorizations
If you want to store a card without charging the customer immediately, perform a Pre-Authorization type transaction (transaction_type: "01" or "40") for $0.00 using ecommerce_flag: 7 and indicator: "1". Capture the returned transaction_tag and transaction_id, and use them to process subsequent MIT charges using indicator: "S".