Loading...
In this guide, we use our Card Storage solution to set up an MIT that is out of scope for SCA. To adhere to scheme rules, we first perform a 3D Secure 2 payment authentication (with Challenge Flag set to Mandated), even though we're not charging the card before we store it.
Next, we follow the standard practice for card storage, which includes performing a verification (open-to-buy, OTB) before storing the card. We then charge the stored card, performing an MIT. In each step, we include the correct COF data. For more information, see our Credential on File article.
A merchant-initiated transaction (MIT) refers to a card payment made by a merchant without the customer being actively involved. This follows a transaction and an agreement made between the merchant and the customer in what is referred to as a customer-initiated transaction (CIT).
When flagged correctly, MITs are deemed as out of scope for Strong Customer Authentication (SCA) requirements under the Revised PSD2 within Europe and the United Kingdom. This allows MITs to be processed without any further required customer authentication and the associated friction that comes with it.
For an MIT to be considered out of scope for SCA:
The following table describes the different types of MITs.
| Type | Description |
|---|---|
| Recurring | Transaction with a fixed amount but no fixed duration in which the merchant continues to process payments with the cardholder's credentials until the cardholder cancels (for example, a subscription or a gym membership). |
| Installments | Transaction with a fixed amount and duration in which the merchant can't process the cardholder's credentials once this fixed period ends. Installments are paid at an agreed amount on the same day of each month (for example, paying for a kitchen appliance over 12 months interest free). |
| Oneoff | Unscheduled transaction with no fixed duration but with an agreed amount (for example, a travel card "top up" if the credit falls below a certain limit). |
In this guide, we assume that you're already familiar with our 3D Secure 2 documentation and may have already integrated. In which case, you've already confirmed which version of 3D Secure the card supports and, conditionally, performed the Method URL step to allow the Issuer to gather data about the customer's device.
The payment authentication confirms the customer's billing and shipping address and performs checks using their browser data. Because this authentication initiates an MIT transaction sequence, we need to indicate to the Issuer that a challenge is mandated.
The following table lists the key data points to submit in the authentication message:
| Field | Value |
|---|---|
| Message Category | Payment Authentication (Must always be this value, even if you're not charging the customer right away.) |
| Preference | Challenge Mandated |
With a verification request, or OTB, you can check if a card is still valid and active without actually processing a payment against it. The outcome of the payment authentication tells us this as well. However, with the OTB, you can also check the security code and address before storing the card.
In this request, we provide the COF data, including the type of agreement between the merchant and customer as well as the transaction sequence — FIRST. We also need to flag this as a CIT. By including all this data, you'll set up the card for future MITs. The verification will return a brand reference (also known as Scheme Reference Data, or SRD) in the response, which is also important for subsequent transactions.
Now that we've successfully processed a payment authentication and validated the card, we can store it for future transactions. Our Card Storage solution returns a Payment Method ID (or token), which you can store with the brand reference from Step 2.
Now that the card is stored, we can use the Payment Method ID (token) to process future merchant-initiated transactions. Include the stored credential COF data to indicate that this is an MIT.