What is a merchant-initiated transaction?

The two interactions behind an MIT

Current Visa developer documentation describes a merchant-initiated transaction as one connected to a previous consumer-initiated transaction and conducted without the consumer present or providing additional validation at that time. This makes the earlier interaction and the later payment distinct parts of the same business story.

Common examples

Visa materials group several types of later payments under merchant-initiated activity. Everyday examples can include a scheduled subscription payment, an installment collected after the initial purchase, an unscheduled payment submitted under an existing arrangement, or a delayed amount associated with an earlier service interaction.

These examples explain the concept, but they are not a universal configuration guide. A platform may use specific transaction types, reference fields, and workflow labels. Merchants should not guess which option applies or copy values from an unrelated integration.

• Recurring service: The customer enrolls during an active interaction, then the business submits later scheduled payments without a new checkout each time.
• Installment arrangement: The customer agrees to a purchase structure, and later payment events occur according to that arrangement.
• Unscheduled stored-credential use: A later amount is submitted under an existing arrangement, but not on a fixed repeating schedule.
• Follow-up business event: A later transaction relates to an earlier customer interaction and is initiated by the business after that interaction ends.

The details behind each category vary. Confirm the real use case with the payment provider and integration team before changing production settings.

How MIT differs from a customer-initiated payment

The difference is active participation at the time of the individual transaction. A customer may use a saved card and still initiate a payment by deliberately placing a new order. By contrast, the business may initiate a later payment under the earlier arrangement while the customer is not completing a new checkout.

Consider a membership. The enrollment checkout may be customer-initiated because the customer selects the service and confirms the first purchase. A later scheduled payment may be merchant-initiated because the business submits it without another checkout action. If that same customer later returns and actively buys a separate item using the saved credential, that new purchase can again be customer-initiated.

For the companion definition, read what a customer-initiated transaction is. The recurring payments and card-on-file FAQ hub provides more background on related workflows.

Why accurate workflow mapping matters

Payment systems can ask for information that describes how a transaction began and how it relates to an earlier interaction. A clear internal map helps the business explain its flow to the provider, connect later payments with the appropriate business record, and avoid treating every stored-card transaction as the same type of event.

General educational content cannot determine the correct processing indicators for a specific account. Those details depend on the configured provider, integration, transaction type, and current network instructions.

Questions to take to a payment provider

Before implementing or revising a stored-payment flow, show the provider a plain-language diagram of what actually happens. Useful questions include:

• Which customer action establishes the initial interaction in this exact checkout?
• Which later events does the provider classify as merchant-initiated?
• How should recurring, installment, unscheduled, and other follow-up events be distinguished?
• Which non-sensitive reference links a later payment to the earlier customer interaction?
• What should happen if the customer returns and actively starts a new purchase?
• How should staff handle changes, cancellations, duplicate attempts, and unsuccessful payments?
• Which test cases and provider documentation apply to the configured integration?

For a broader view of payment flows, visit the payment processing overview. If the current workflow needs to be discussed, use the Payments Max contact page and share only non-sensitive operational details.

Privacy-safe records for later payments

A useful operations record can include the sales channel, customer-facing action, internal order reference, arrangement type, transaction timestamp, provider response, and staff follow-up. Keep access limited to people who need the information and use approved systems for payment details.

Do not place full card numbers, security codes, passwords, bank credentials, one-time passcodes, or secret API keys in general forms, tickets, spreadsheets, or ordinary email. Use redacted examples and non-sensitive references when asking a provider or Payments Max to help map a workflow.