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 do not 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 do not 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.
- Store the value returned in the
additionalData.networkTxReferencefield from the response of the first authenticated payment in a subscription or contract. - For the subsequent payments, submit the
additionalData.networkTxReferencein 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 do not require SCA, you still need to apply SCA to the initial authorisation or the first transactions for the subscription or contract.
