CIT vs MIT

DEFINITION

CIT and MIT describe who starts a card payment: a customer initiated transaction (CIT) is one the cardholder actively begins, while a merchant initiated transaction (MIT) is charged later using stored credentials with no cardholder present, such as a subscription renewal. Recurly tags each charge correctly and carries the original CIT reference into later MITs.

RELATED TERMS

Merchant Initiated TransactionCustomer Initiated TransactionStored CredentialStrong Customer AuthenticationSCA ExemptionInvoluntary churnDunning

CIT and MIT describe who starts a card payment and whether the cardholder is present when it happens. A customer initiated transaction (CIT) is a payment the cardholder actively begins, such as entering card details at checkout, confirming a purchase in an app, or signing up for a subscription. A merchant initiated transaction (MIT) is a payment the merchant charges later using stored credentials, with no cardholder present, such as a recurring renewal, a usage-based invoice, or a retry after a declined charge.

The distinction matters because card networks and issuers treat the two differently for authentication, fraud scoring, and compliance. A CIT usually requires the cardholder to authenticate in the moment, while an MIT relies on an agreement the cardholder set up earlier during a CIT. A subscription platform such as Recurly flags each charge with the correct indicator and carries the reference from the initial CIT into later MITs so that renewals process cleanly. Getting the tag right is what separates a renewal that goes through from one an issuer declines as unexpected. Recurly captures the network transaction ID, and for Mastercard a transaction link ID, from the initial CIT and references it on later MITs, and it automatically applies the gateway-specific MIT flags a renewal needs.

Why CIT vs MIT matters for subscription businesses

For a business that bills the same cards over and over, most revenue arrives through MITs. The customer authenticates once when they subscribe, and every renewal after that is charged without them present. If those renewals are not correctly identified as merchant initiated, issuers can treat them as suspicious and decline them, which turns into involuntary churn.

Labeling each transaction correctly affects three things at once:

  • Authorization rates, because issuers approve more MITs when the initial cardholder agreement is referenced.

  • Authentication requirements, because a properly flagged MIT can be processed without asking an absent cardholder to complete a step they cannot complete.

  • Regulatory compliance, since regional rules for strong customer authentication apply to CITs but exempt many correctly tagged MITs. This is primarily PSD2 and Strong Customer Authentication in the EU and UK; Recurly applies the MIT exemption automatically on renewals, though the issuer always has final discretion to still require authentication.

How CIT and MIT work

The two transaction types are linked. A stored-credential arrangement almost always begins with a CIT, and later MITs point back to it.

  1. The cardholder starts a CIT, entering or confirming their card and agreeing that the merchant may charge it again later.

  2. During that first transaction, the merchant stores the credential and records the network reference the card scheme returns.

  3. On each later charge, the merchant sends an MIT that includes the stored credential and the original reference, signaling that the cardholder already consented.

  4. The issuer sees the link to the initial agreement and evaluates the MIT accordingly, which typically raises the chance of approval.

CITs and MITs also carry different indicators for their reason. A renewal, an automatic top-up, and a retry after a decline are each MITs but for different stated purposes, and the correct sub-type helps the issuer understand the charge. Recurly sends reason codes that indicate the specific type of MIT.

How to use the CIT and MIT distinction

Treat the first transaction as the moment to capture everything later charges will depend on. During the sign-up CIT, collect explicit agreement to store and reuse the card, and keep the network reference the transaction returns. From then on, send renewals, usage charges, and dunning retries as MITs tied to that reference rather than as fresh customer transactions.

A few control points are worth checking:

  • Confirm that new subscriptions authenticate the cardholder and record consent at the CIT.

  • Confirm that renewals and retries are sent as MITs, not mislabeled as CITs, which would wrongly demand cardholder authentication.

  • Confirm that updated cards obtained through account updater services or a re-entry flow are relinked so MITs keep referencing a valid agreement. Recurly sends the network transaction ID and transaction link ID along with the updated card on a renewal, so that reference stays intact.

Benefits and examples

Correctly separating CIT from MIT protects recurring revenue that would otherwise leak through avoidable declines. When renewals are flagged as merchant initiated and reference the original agreement, more of them clear on the first attempt, fewer active subscribers are dropped by mistake, and the business spends less effort recovering payments that should never have failed.

Consider a streaming service that charges a monthly plan. A new subscriber enters their card and confirms the plan, which is a CIT that authenticates the cardholder and stores the credential. Thirty days later the service charges the renewal as an MIT that references that first transaction. The subscriber does nothing and may not even open the app, yet the charge processes because the issuer can see the standing agreement behind it. If the same renewal had been sent as a CIT, the issuer might expect cardholder authentication that no one is there to provide, and the payment could fail. This example is hypothetical.

Frequently asked questions

Is a subscription renewal a CIT or an MIT? A renewal is a merchant initiated transaction. The cardholder set up the agreement earlier during a CIT, and the renewal is charged later without them present, so it should be flagged as an MIT that references the original transaction.

Does an MIT need strong customer authentication? In regions that require strong customer authentication, the authentication generally happens on the initial CIT, and correctly tagged MITs can qualify for an exemption because the cardholder is not present. This applies mainly to PSD2 and Strong Customer Authentication in the EU and UK; Recurly automatically flags renewals as MITs to claim the exemption, though the issuer always has final discretion to still require authentication.

What happens if a renewal is mislabeled as a CIT? The issuer may expect the cardholder to authenticate the charge in real time. Because no one is present to do that, the transaction can be declined, which causes involuntary churn even when the customer intended to keep paying.

Why does the original transaction reference matter? The reference links each later MIT back to the agreement the cardholder made. Sending it tells the issuer the charge is expected and tied to consent, which typically improves approval rates.