CIT vs. MIT: How Credentials on File Work for Recurring Payments
A customer signs up for a monthly service, saves a card and successfully completes the first payment. Thirty days later, the business submits the next recurring payment using the same stored credential.
To the merchant, it may look like the same payment happening again. To the issuer, it is a different transaction with different requirements.
The first payment is a customer-initiated transaction, or CIT. The subsequent recurring payment is a merchant-initiated transaction, or MIT, made under the agreement established during the original purchase.
When that relationship is not identified correctly, a routine recurring payment can appear to the issuer as an unexpected charge. The result may be an avoidable decline, an interrupted subscription and a customer who leaves without ever actively deciding to cancel.
That last outcome matters. Involuntary churn, meaning customers lost to failed payments rather than a real decision to leave, is one of the quietest and most preventable sources of lost recurring revenue. It rarely shows up as a complaint. It shows up as a recurring payment that
simply did not go through.
Credentials on file, then, are not just a payment-storage issue. They sit at the intersection of a business’s authorization strategy, recurring-revenue performance and customer experience.
What Are Credentials on File?
Credentials on file are payment credentials that a business stores, or has stored by a payment service provider, for future transactions. Our monthly-service customer created one when they chose to save their card at signup.
The pattern appears across many recurring and stored-card models: subscription payments and membership renewals, recurring invoices and usage-based billing, one-click checkout, installment plans, and hotel or vehicle rental charges. In each case, a credential captured once is intended to be reused later.
The stored credential may be the card number itself, a payment token or another secure reference connected to the original card.
Whenever possible, businesses should avoid storing raw card data. Tokenization replaces sensitive card information with a token that can be used for future transactions without exposing the original data throughout the merchant’s systems. The PCI Security Standards Council recommends minimizing stored payment data and using technologies such as tokenization when card data must be retained.
The Customer-Initiated Transaction
A customer-initiated transaction occurs when the customer actively participates in the payment.
In our example, the signup payment is the CIT. The customer is present, enters or selects their card, and agrees to store it for future use.
CITs cover the moments where the customer is in control of the payment experience, such as completing an online checkout, buying through a mobile app, selecting a saved card for a one-click purchase, adding a new card to an account, or agreeing to store a payment method for future use.
That first CIT does more than move money. It establishes the credentials-on-file relationship.
During this transaction, the merchant should obtain the customer’s consent to store and reuse the credential. The response from the transaction may also include an identifier that needs to be retained and associated with merchant-initiated transactions that follow.
Get this step right and the subsequent transaction has a clear lineage back to a consentingcustomer. Skip it and later transactions may have nothing to point back to.
The Merchant-Initiated Transaction
A merchant-initiated transaction occurs when the merchant submits a payment without the customer actively participating at that moment.
In our example, the subsequent monthly recurring payment is an MIT. The customer is not actively completing the checkout, but the charge is legitimate because it is based on an agreement they previously accepted.
MITs can support several use cases, including recurring payments, installment payments, unscheduled credential-on-file payments, delayed charges and certain resubmissions.
What they have in common is that the merchant initiates the transaction under an agreement previously established with the customer.
This distinction can be easy to overlook.
An MIT is not simply any transaction processed without the customer present. It must be connected to a valid agreement and, where required, linked back to the original customer-initiated transaction.
Stored credential frameworks require merchants and their payment partners to identify the initial storage of a credential and distinguish the subsequent transactions that use it.
Why CIT and MIT Indicators Matter to Issuers
Here is the crux: to a merchant, a CIT and an MIT may appear to use the exact same stored card. To an issuer, they represent different circumstances.
A CIT tells the issuer the customer is participating in the transaction now.
An MIT tells the issuer the merchant is charging a credential under a previously established agreement.
Sending the correct indicator gives the issuer important context for making an authorization decision and helps establish the relationship between the original transaction and the subsequent payments that follow.
This is also why linking MITs back to the original CIT through the appropriate transaction identifier can be important.
That link helps the issuer understand the history behind the charge and recognize that it is part of an established payment relationship rather than an isolated transaction against a stored credential.
Without that context, a recurring payment can arrive at the issuer stripped of its history: an isolated charge against a stored card with less information explaining why the merchant is initiating it.
When credentials-on-file information is missing or submitted incorrectly, the downstream costs can be significant: avoidable declines, interrupted subscriptions, failed recurring payments, increased customer support requests, greater dispute risk and lost recurring revenue.
Managing credentials on file correctly is therefore not only a compliance consideration. It is a core part of a strong payment-authorization strategy.
What Recurring Payments Actually Depend On
Reliable recurring billing is the result of several systems working together.
The business has to securely retain the credential, record the customer’s consent, store the relevant transaction identifiers, and submit each future transaction with the correct CIT or MIT information.
It also has to account for the reality of cards that expire, get reissued or are replaced between one recurring payment and the next.
In practice, a durable recurring-payment setup often combines:
- Secure tokenization.
- Stored consent records.
- Correct CIT and MIT indicators.
- Original transaction identifiers.
- Account Updater services to help keep card details current.
- Sensible retry rules.
- Reporting and audit trails that document the payment relationship.
Some businesses also use multiple gateways or processors for resilience.
Together, these capabilities protect stored data while improving the likelihood that future transactions are processed successfully.
Credentials on File Do Not Mean Storing Everything
It is worth being explicit about a common misconception: credentials on file are not a license to store every payment field.
Card verification values, including CVV and CVC codes, cannot be stored after authorization, including for recurring or card-on-file transactions.
These values are not required for future recurring payments and should not be retained for that purpose.
Businesses should keep only the information future transactions actually require and protect the underlying card data through a PCI-compliant payment provider.
How Tokenization Supports Credentials on File, and Who Controls the Token
Tokenization allows a business to replace the customer’s card number with a non-sensitive reference that can be retained in a billing, CRM or subscription platform.
When a future payment is due, the token can be submitted through an approved payment flow without exposing the original card number throughout the merchant’s applications.
But not all tokens provide the same level of flexibility.
A gateway-specific token may only work with the gateway that issued it. If stored credentials are tied entirely to one provider’s tokens, the business may also be tying its recurring-payment infrastructure to that provider.
Changing processors, adding a backup gateway or routing transactions according to different business rules can become more difficult because the references the billing system depends on may not work elsewhere.
An independent payment token changes that relationship.
When the token is controlled independently of a single gateway, the enterprise has greater flexibility over where and how its stored credentials are used.
That can support multiple gateways, processor changes, Account Updater workflows and transaction routing based on factors such as geography, cost or reliability, without forcing the merchant’s billing systems to depend entirely on a single gateway’s token.
For a business that relies heavily on recurring revenue, that control can have a direct impact on payment flexibility and resilience.
Where HostedPCI Fits
HostedPCI helps businesses securely collect, tokenize and manage payment credentials for future transactions, while supporting the transaction lineage required for credentials-on-file use cases.
The initial customer-initiated transaction establishes the credentials-on-file relationship and can return the identifier needed for subsequent payments.
The merchant can retain that identifier alongside the HostedPCI token and submit the relevant information when a later merchant-initiated transaction is processed.
This allows the MIT to retain its connection to the original customer-initiated transaction rather than appearing as an isolated charge against a stored credential.
Raw card data does not have to spread throughout the merchant’s applications for this process to work.
Because HostedPCI’s tokenization architecture is designed to give enterprises control over payment routing, gateway relationships and stored credentials rather than tying them to a single processor, businesses can maintain greater flexibility as their processing requirements evolve.
Building a Recurring-Payment Foundation That Holds
Come back to the customer we started with.
Their next recurring payment succeeds not simply because a card was saved and charged again, but because a chain of small, correct decisions held together.
Clear consent was captured at signup. The initial CIT was distinguished from the subsequent MIT. The relevant transaction identifier was retained. The credential was protected through tokenization. The recurring payment was submitted with the correct information. The card details were kept current between transactions.
When those elements work together, a recurring payment becomes exactly what it should be: routine.
The customer keeps their service, the issuer receives the appropriate transaction context, and the business reduces the risk of losing recurring revenue to preventable payment failures.
If you would like to see how HostedPCI supports credentials on file, tokenization and the CIT/MIT lineage behind recurring payments, talk to our team. We can walk through how it applies to your own billing setup.
Learn more at www.HostedPCI.com.