Merchant Initiated Transactions

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 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).

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.

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.

(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.

(Select FollowOnMitPayment from the examples drop-down).

 

Testing your Integration

To test MIT, see Testing Merchant Initiated Transactions