What is a customer-initiated transaction?

What makes the transaction customer-initiated

Current Visa documentation describes a consumer-initiated transaction as one where the consumer is present and provides a payment credential, either at an in-store terminal or through an online checkout. In practical merchant language, the customer is taking the action that starts the payment and is engaged with that purchase.

Common customer-initiated examples

The exact data and indicators used behind the scenes depend on the merchant's payment setup, but these everyday situations illustrate active customer participation:

• At a staffed checkout: A customer inserts, taps, or swipes a payment credential and follows the terminal prompts.
• At a self-service device: A customer selects the purchase and presents a card or eligible device during that session.
• At an online store: A customer reviews an order, supplies or selects a payment method, and submits the purchase.
• Within an app: A customer deliberately confirms a new order using a payment credential available through the app's checkout.
• Using a saved card: A signed-in customer selects a stored credential and actively places a new order rather than waiting for an automatic billing event.

These examples explain the concept; they do not determine the technical classification for every provider. Merchants should use the integration guidance supplied for their actual gateway, processor, and sales channel.

How it differs from a merchant-initiated transaction

A merchant-initiated transaction, often abbreviated MIT, is generally submitted without the customer actively participating at that moment and is tied to a prior arrangement or interaction. Mastercard's current transaction-processing rules describe an MIT as a card-not-present transaction initiated by the merchant based on a prior agreement with the cardholder. Visa likewise distinguishes merchant action taken without additional cardholder participation from a consumer-initiated payment.

A subscription illustrates the difference. The customer's first checkout, where they actively select the plan and provide or choose a payment method, may be customer-initiated. A later scheduled payment submitted automatically under the agreed arrangement may be merchant-initiated. That distinction is about who initiates the particular payment event, not simply whether the same credential is used.

For a broader explanation of automatic billing, see how recurring ecommerce payments work and the recurring payments and card-on-file FAQ hub.

Why the distinction matters operationally

Payment platforms can ask merchants or their integration partners to identify how a transaction began. Accurate classification gives the provider better context about the customer interaction and helps keep the transaction record aligned with the actual checkout flow. The required fields, values, and terminology are implementation-specific, so a generic article cannot substitute for current provider documentation.

Questions to confirm with a payment provider

Before changing checkout or stored-payment logic, merchants should compare their real customer journey with current documentation from the parties that support the account and integration. Useful questions include:

• Which terms does the provider use for customer-, consumer-, or cardholder-initiated payments?
• How should the integration identify an active checkout that uses a newly entered credential?
• How should it identify a customer actively choosing a credential already stored on file?
• How are later recurring or other merchant-initiated payment events distinguished from the original customer interaction?
• Which transaction references connect an initial interaction with a related later payment?
• How should canceled, interrupted, duplicate, or unsuccessful attempts appear in the order system?
• Which test cases should be completed before a workflow change is released?

Ask for account-specific implementation material rather than copying field names or values from an unrelated platform. A payment gateway may carry transaction information between systems, but the merchant's actual integration determines what it must send.

Privacy-safe documentation

A useful internal payment-flow record can show the sales channel, customer action, order reference, stored-credential choice, payment timestamp, provider response, and follow-up event without reproducing sensitive payment data. Limit access to the staff who need it and use the provider's approved dashboard or support process when investigating a transaction.

Do not place full card numbers, security codes, passwords, bank credentials, one-time passcodes, or secret API keys in a general contact form, ticket, spreadsheet, or ordinary email. When asking for help, use non-sensitive order references and redacted examples. For more context on a customer actively selecting a stored checkout option, review what Click to Pay is.