Guides

Merchant Initiated Transactions

Understand which properties you need to set for authorisations initiated by merchants

Suggest Edits

A merchant initiated transaction (MIT) is, as its name implies, a payment that is requested by the merchant without the involvement of the cardholder. MITs are widely used for recurring payments such as subscriptions or instalments.

Establishment for future MITs

Some card schemes require an initial Customer Initiated Transaction (CIT) between the merchant and the customer, before a merchant can initiate an MIT. This initial transaction can be a standard Authorisation or an Account Status Inquiry (ASI).

MIT Establishment During an Authorisation

If a merchant is planning to initiate MITs in the future using the respective card, the merchant can set the following properties to inform the scheme and the issuer during a customer initiated authorisation:

fundingSource is set to the nature of future MITs as:

  • CardOnFile for one-off or mixed use MITs,
  • Recurring for recurring MITs, such as subscription fees,
  • Installment for the payments for an instalment plan

isSubsequentTransation is set to False or omitted from the request

merchantInitiated is set to False or omitted from the request

MIT Establishment During an Account Status Inquiry

Similar to an authorisation, an ASI can be used for establishment of future MITs using the following properties as:

fundingSource is set to the nature of future MITs as:

  • CardOnFile for one-off or mixed use MITs,
  • Recurring for recurring MITs, such as subscription fees,
  • Installment for the payments for an instalment plan

isSubsequentTransation is set to False or omitted from the request

merchantInitiated is set to False or omitted from the request

🚧

Storing Scheme Transaction Id for Future MITs

While initiating an MIT, some schemes expect you to provide the Scheme Trace Id of the establishment transaction. So, we advise you to save the schemeTraceId property returned in the establishment Authorisation or the ASI API response and pass it during the related MIT Authorisation API requests as the previousSchemeTraceId

Initiating an MIT Authorisation

An MIT authorisation is done through the standard Authorisation API by setting certain properties in the request body:

fundingSource is set to the nature of the current MIT from one of the following values as:

  • CardOnFile for a one-off payment
  • Recurring for the current instance of a recurring payment, such as a subscription
  • Installment for the instalment of the respective period

isSubsequentTransation is set to True

merchantInitiated is set to True

previousSchemeTraceId if available, this is set to the Scheme Trace Id returned in the response of the establishment transaction request as schemeTraceId

List of All Use Cases and Potential Errors

You may use the following tables to have a better understanding of how Cards Connect manages various modes of transactions.

Use CasepaymentSourcemerchantInitiatedisSubsequentTransaction
Customer Initiated Card on File PaymentCardOnFileFalse or omittedTrue
Merchant Initiated One-off PaymentCardOnFileTrueTrue
Merchant Initiated Recurring PaymentRecurringTrueTrue
Merchant Initiated Instalment PaymentInstallmentTrueTrue
Customer Initiated Payment with the Establishment of Future MITsDepending on the nature of future MITs one of:
CardOnFile
Recurring
Installment		False or omittedFalse or omitted
Account Status Inquiry with the Establishment of Future MITsDepending on the nature of future MITs one of:
CardOnFile
Recurring
Installment		False or omittedFalse or omitted

If you pass properties that are incompatible with each other, you may receive an error, some of these cases are explained below:

paymentSourcemerchantInitiatedisSubsequentTransactionIssue
One of:
ECommerce
Mail
Phone		TrueTrueAn MIT should have a valid use case such as “One-off”, “Recurring”, or “Instalment“ but the selected paymentSource lacks this information.
AnyTrueFalse or omittedBy setting the isSubsequentTransaction as False or omitting it, the merchant sets the intent as establishing for future MITs which is expected to happen through a customer initiated transaction, however, merchantInitiated is also set to True creating a contradiction.
One of:
Recurring
Installment		False or omittedTrueSetting the merchantInitiated as False means that this is a Customer Initiated Transaction (CIT). Considering isSubsequentTransaction is set to True, this is also not an establishment attempt for future MITs but card on file transaction. However, a CIT card on file payment can only be done as a one-off transaction, requiring the paymentSource to to be set as CardOnFile

For example, if a customer wants to pay an instalment at an earlier date using the merchant app rather than waiting it to be debited on the scheduled date (Which would be an MIT), the transaction becomes a one-off Customer Initiated Card on File.

Updated 5 days ago