> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md). # Merchant-Initiated Transactions (MIT) Charge stored payment credentials without the customer being present – for subscriptions, recurring charges, and follow-up payments. A Merchant-Initiated Transaction (MIT) is a payment created directly by the merchant without the customer being actively involved at the time of execution. MITs are suitable for subscriptions, recurring charges, fees, and other follow-up payments where prior customer consent exists. MITs are performed using the customer’s previously stored payment credentials and must reference the consent established during the initial Customer-Initiated Transaction (CIT). The SEB Ecommerce Payment Gateway processes MITs in line with the Visa and Mastercard Stored Credential Framework. {% hint style="info" %} Merchant-Initiated Transactions are supported only for payment methods that allow credential storage and tokenization – currently, card payments. {% endhint %} ### Capability Summary
CapabilitySupport
Payment MethodsPayment Cards (Visa, Mastercard)
PrerequisiteSuccessful initial Customer-Initiated Transaction (CIT) with stored credentials
Customer InteractionNone – no customer participation at the time of execution
AuthenticationEMV® 3DS Requestor-Initiated (3RI), where applicable
TokenizationInternal (gateway) and network tokens (Visa TMS, Mastercard SCOF)
InitiationMerchant API – payments are initiated by your systems
SchedulingPerformed by your systems; the gateway does not schedule payments
Post-Payment OperationsCapture, refund, and reversal through standard flows
Status NotificationsCallback notifications (webhooks)
Sandbox TestingAvailable
Availability of individual capabilities depends on your merchant agreement, enabled services, and acquiring configuration. ### Prerequisites Before you can process Merchant-Initiated Transactions: 1. Complete an initial Customer-Initiated Transaction during which the customer explicitly agrees that their payment credentials may be stored for future use. See [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md). 2. Receive and store the token ID. During the initial payment, the gateway securely stores the customer’s payment credentials and generates a token. The token ID is returned to you together with the other payment details. 3. Retain evidence of the customer’s consent – for example, the billing model, frequency, amounts, and cancellation process the customer agreed to. Each MIT must reference this consent. {% hint style="info" %} Do not initiate Merchant-Initiated Transactions without a valid, successful initial CIT. If the initial CIT was declined or abandoned, no consent relationship exists and no stored credential may be charged. {% endhint %} ### Payment Flow A Merchant-Initiated Transaction is processed in two steps via the Merchant API: 1. Initiate the payment. Your system initiates the payment, providing the amount and currency, shopping cart details, and other required payment information. The gateway returns the ID of the initiated payment. 2. Charge the stored credential. Your system charges the payment by sending a request that references the previously stored token. No customer interaction is necessary. The gateway resolves the token and processes the transaction through the standard authorization flow. The issuer authorizes each payment according to applicable card scheme rules and its own risk assessment. The final payment status is returned in the API response and, if configured, delivered to your systems via callback notifications (webhooks). After authorization, standard post-payment operations – capture, refund, and reversal – are available through the same flows as for other card payments. See [Supported Operations](/payment-methods/cards/supported-operations.md). ### Common Use Cases Merchant-Initiated Transactions cover payment scenarios in which the charge is triggered by your systems rather than by the customer: * Recurring payments. Fixed-amount charges at agreed intervals – monthly subscriptions, annual renewals, memberships, insurance premiums. * Installment payments. A purchase amount split into scheduled parts agreed with the customer. * Usage-based billing. Charges of varying amount or timing based on actual usage – for example, metered services or top-ups – within the terms the customer agreed to. * Delayed or follow-up charges. Follow-up amounts collected after the original purchase, where this was agreed with the customer. * Fees. Account fees or service charges collected under the customer’s standing consent. Whatever the scenario, the amounts, timing, and conditions of merchant-initiated charges must stay within the scope of the consent the customer provided during the initial CIT. ### Authentication Because the customer is not present during an MIT, no cardholder authentication takes place at the time of the charge. Instead: * The Strong Customer Authentication (SCA) performed during the initial CIT covers the setup of the stored credential relationship. * Subsequent MITs may qualify for regulatory exemptions or fall outside the SCA scope, subject to applicable regulations. The final authorization decision always remains with the issuer. * Where applicable, MITs may utilize EMV® 3DS Requestor-Initiated (3RI) authentication as part of the gateway’s 3DS support. See [EMV® 3-D Secure (EMV 3DS) and Strong Customer Authentication (SCA)](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) for details. ### Division of Responsibilities The gateway provides secure execution of merchant-initiated payments. Subscription business logic remains with you. Understanding this split is essential for a correct integration:
Provided by the Payment GatewayYour Responsibility
Secure processing of the initial CIT, including SCA where requiredObtaining and retaining evidence of customer consent
Generation and management of secure payment tokens (PCI DSS)Storing the token ID and associating it with the customer profile
Execution of MITs referencing the stored token, including 3RI support where applicableScheduling payments – deciding when each charge is initiated
Transaction status handling and real-time notifications (webhooks)Retry handling for declined charges and subscription state updates
Standard capture, refund, and reversal operationsBilling plan configuration, invoicing, and customer communication
Visibility of transactions in the Merchant PortalSubscription lifecycle management and cancellation handling
{% hint style="info" %} The gateway does not independently schedule subscription payments. Recurring transactions are initiated by your systems through API calls at the intervals you manage. The gateway also does not provide billing plan configuration, invoicing, or subscription business logic. {% endhint %} ### Handling Declines and Card Changes MITs can be declined – for example, due to insufficient funds, a suspended token, or the issuer’s risk decision. The gateway returns the payment status in the API response and via callback notifications, enabling your systems to manage retries and subscription state updates. When handling declines: * Use the payment status and notifications returned by the gateway to drive your retry and dunning logic. * Where network tokenization is enabled, card reissuance and expiry updates are applied to the stored token automatically by the card schemes – the existing token reference remains valid, reducing declines caused by stale card details. * Subscribe to token status notifications. If a token is suspended or deactivated, pause merchant-initiated charges and ask the customer to provide a payment method again through a new Customer-Initiated Transaction. * Notify customers about failed charges and give them a way to update their payment method. ### Visibility and Reporting Merchant-initiated and subscription-related transactions are visible in the Merchant Portal under Orders/Transactions details. Where subscription functionality is enabled, the transaction detail view indicates whether a transaction represents an initial Customer-Initiated Transaction (CIT) or a Merchant-Initiated Transaction (MIT), supporting reconciliation and operational follow-up. ### Merchant Best Practices We recommend that merchants: * Initiate Merchant-Initiated Transactions only after a valid, successful Customer-Initiated Transaction. * Keep merchant-initiated charges within the scope of the customer’s consent – amounts, frequency, and conditions. * Notify customers before recurring charges where required by applicable regulations or card scheme rules. * Clearly communicate recurring billing terms and provide a simple cancellation process. * Monitor payment notifications, reconcile transactions regularly, and update subscription state based on the confirmed payment status. * Handle expired, replaced, or deactivated tokens appropriately using token status notifications. * Use tokenization instead of storing payment card numbers, and maintain PCI DSS compliance appropriate to your payment environment. ### Testing Complete all development and validation in the Sandbox environment before processing live transactions. Before requesting Production activation, verify: * An initial CIT with the customer consent step and successful token creation. * An MIT charge referencing the stored token, without customer interaction. * Declined MIT scenarios and your retry and notification handling. * Behavior with a suspended or deactivated token. * Callback or webhook notifications and subscription state updates in your systems. * Refund and reversal processing for merchant-initiated payments. ### Frequently Asked Questions #### Can an MIT be the customer’s first payment? No. Merchant-Initiated Transactions require a successful initial Customer-Initiated Transaction in which the customer explicitly agreed to store their payment credentials. The token created during that payment is what your MIT requests reference. #### Does the gateway schedule my subscription charges? No. The gateway executes the transactions you initiate but does not independently schedule payments. Your systems decide when each charge is initiated and call the Merchant API accordingly, using status notifications to manage the subscription state. #### Does the customer complete 3-D Secure during an MIT? No. The customer is not present, so no cardholder authentication takes place at the time of the charge. The SCA performed during the initial CIT covers the credential setup, and where applicable the gateway supports EMV® 3DS Requestor-Initiated (3RI) authentication for MITs. The authorization decision remains with the issuer. #### Can I use MITs with payment methods other than cards? Merchant-Initiated Transactions are supported only for payment methods that allow credential storage and tokenization – currently, card payments. Account-to-account payment methods follow different models; see Pay by Bank. #### What should I do when an MIT is declined? Use the payment status returned in the API response and via webhooks to drive your retry logic and subscription state updates. If the decline is caused by a suspended or deactivated token, ask the customer to provide a payment method again through a new Customer-Initiated Transaction. #### Can I refund a merchant-initiated payment? Yes. Captured MIT payments can be refunded, in full or partially, through the standard refund flow. See Supported Operations. ### Related Documentation Continue with the following topics: * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [EMV® 3-D Secure](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS) * [Tokenization](/payment-methods/cards/tokenization.md) * [One-Click Payments](/payment-methods/cards/stored-credentials/one-click-payments.md) * [Customer-Initiated Transactions](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) (CIT) * [Merchant API](/integration/merchant-api.md) * [Testing](/payment-methods/cards/testing.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.