---
title: Merchant Initiated Transactions
slug: mits
docTags: 
createdAt: 2024-05-28T15:42:43.955Z
---

Merchant-Initiated-Transactions (MIT)s, (for example, subscription type payments, unscheduled transactions such as tips and an increase in taxi fares) are also impacted by [Strong Customer Authentication](docId\:uLg1uCaYg3ljb7t0SVcw5) (SCA).

You need to tag your MIT / recurring transactions correctly to ensure your transactions are not declined by your customers’ issuing bank.

## Existing Agreements / Subscriptions

There may be cases where you have agreements/subscriptions agreed with customers previous to the SCA deadline. These transactions still need to be tagged as MIT / recurring and reference the first transaction's receipt ID for that card or a previous transaction's receipt ID.

The older the transaction referenced in the MIT, the more likely it will be accepted by the issuer (customers bank).

:::hint{type="warning"}
In the event that a customer's issuing bank declines a transaction with reason requiring authentication –  you may need this customer to re-register their card through SCA.
:::

***

## New Agreements / Subscriptions

For new cards, you must ensure your customer goes through SCA when registering their card.

:::hint{type="info"}
You must also store the **card token** and **receipt ID** returned by the API and / or SDK callbacks for future transactions.
:::

**Example Subscription Flow**:

1. Customer enters payment information
2. Merchant makes a zero-authorisation to validate card with 3D Secure
3. Customer completes 3D Secure
4. Merchant stores **Card Token**, **Consumer Reference** and **Receipt ID** from the transaction response
5. Future Recurring Payments should be tagged as **Recurring **and reference the stored information above, with the Receipt ID entered as the **Related Receipt ID**

You can find an example Recurring in our Transaction API Reference [here](docId\:bcXNM5keOk-nlNrZTafUT).
(Select** FollowOnScheduledRecurringPayment** from the examples drop-down).

***

## Varying Final Amount (Ride-sharing / Hospitality)

There are instances where the final amount may change, for example a taxi having to take a longer route, or a customer giving a tip after receiving their order.

If the customer is not able to go through SCA again, you will be able to create an MIT request for the additional amount.

**Example MIT Flow**:

1. Customer enters payment information
2. Merchant makes a pre-authorisation with 3D Secure for an estimated amount
3. Customer completes 3D Secure
4. Merchant stores **Card Token**, **Consumer Reference** and **Receipt ID** from the transaction response
5. The total amount owed is more than the estimated amount previously pre-authorised
6. Merchant collects amount pre-authorised previously
7. Merchant makes MIT payment request for the surplus amount, tagged as **MIT **and references the stored information above, with the Receipt ID entered as the** Related Receipt ID**

You can find an example MIT request in our Transaction API Reference [here](docId\:bcXNM5keOk-nlNrZTafUT).
(Select **FollowOnMitPayment **from the examples drop-down).

***

## Testing your MIT Integration

To test MITs, see [Testing Merchant Initiated Transactions](docId\:gB1c-OQBH7UUW8rzUSawt).