Merchant initiated transactions (MIT)

SCA is not required for adjustments or subsequent charges

SCA is not required for an authorisation adjustment or for subsequent payments related to a subscription or contract.
However, the initial authorisation or the first transaction for the subscription or contract does require SCA.

MIT

Card schemes refer to payments initiated by merchants instead of shoppers directly as Merchant Initiated Transactions or MIT. Payments made to adjust the initial transaction made by a shopper or subsequent payments in a subscription or contract fall under the scope of MIT.

To ensure that a transaction can be correctly classified as MIT, subsequent payments or authorisation adjustments must be linked to the first payment using a network transaction reference.

Authorisation adjustments

The pre-authorisation transaction requires SCA, but any transaction made to adjust the amount of the pre-authorised amount or to extend the validity of the initial payment is classified as MIT and is, thus, exempt from SCA compliance.

Adyen automatically handles sending the network transaction reference when you adjust the pre-authorised amount or extend the validity of the authorisation.

Subscriptions and contracts with non-fixed time intervals

The first payment in a subscription or a contract falls under the SCA as the shopper directly initiates the transaction. This means that, under PSD2, SCA is required on the sign-up for a series of Subscription or UnscheduledCardOnFile payments. All subsequent payments in a subscription or a contract are classified as MIT and don't fall under the scope of SCA compliance.

How the subsequent payments are linked to the first payment depends on how you tokenize card details.

Tokenizing with Adyen

If you are tokenizing with Adyen, you don't have to store the network transaction reference. Adyen automatically stores and submits the networkTxReference for MIT transactions.

Not tokenizing with Adyen

If you are not tokenizing cards with Adyen and are using your own or an external card vault, you'll need to handle storing and submitting the network transaction reference.

1. Store the value returned in the additionalData.networkTxReference field from the response of the first authenticated payment in a subscription or contract.
2. For the subsequent payments, submit the additionalData.networkTxReference in your request. Failing to do so can cause issuers to return soft declines.

When PSD2 SCA becomes mandatory, issuers will apply grandfathering for ongoing recurring contracts. We recommend that you send the networkTxReference from the initial transaction where the shopper signed up for a series of Subscription or UnscheduledCardOnFile payments. However, if you do not have the networkTxReference, we will insert a card scheme-compliant static value on your behalf. We will do that until the schemes no longer allow static values (Visa, for example, won't support static values after 31 October 2021).

Business model	Transaction type	SCA required?	Shopper Interaction	Recurring Processing Model	Additional implementation steps
Recurring contracts for fixed or variable amounts. For example, streaming service subscription, or auto account top-ups.	Subsequent charges	No, this falls under MIT.	ContAuth	Subscription or UnscheduledCardOnFile	Provide the card scheme transaction identifier in the additionalData.networkTxReference in your payment request. This allows the issuing bank to link the subsequent recurring charge with the initial, fully authenticated sign-up transaction.

Next steps

Although authorisation adjustments and subsequent charges in subscriptions and non-fixed contracts don't require SCA, you still need to apply SCA to the initial authorisation or the first transactions for the subscription or contract.