SCA requirements based on business models

The following table shows common business models with the corresponding SCA requirements.

If you are implementing Merchant Initiated Transactions (MIT) but are not using Adyen's tokenization service, see MIT framework for additional implementation guidelines.

Business model	Transaction type	SCA required?	Payment request parameters
			Shopper Interaction	Recurring Processing Model
Online purchase with shopper in-session	One-off online purchase where a shopper enters card payment details on the checkout page.	Yes, unless exemption applies.	Ecommerce
	Online purchase where shopper agrees to store card details for future use on your website or app. This can be a zero-value transaction.	Yes, unless exemption applies.	Ecommerce	CardOnFile
	Online purchase where shopper uses previously stored card payment details.	Yes, unless exemption applies.	ContAuth	CardOnFile
Subscriptions	First transaction to sign up for a subscription. This can be a zero-value transaction. The terms and conditions should describe the policy for later subsequent charges, for example, fixed or variable amounts.	Yes, if the first transaction is made on or after PSD2 SCA compliance is made compulsory.	Ecommerce	Subscription
	Subsequent subscription charges as described in the initial terms and conditions during the sign-up transaction, following equal time intervals.	No, this falls under MIT.	ContAuth	Subscription
Contracts with non-fixed time interval, such as auto account top-ups	Initial transaction where shopper agrees to the terms and conditions of later subsequent charges. This can be a zero-value transaction.	Yes, if the first transaction is made on or after PSD2 SCA compliance is made compulsory.	Ecommerce	UnscheduledCardOnFile
	Subsequent charges as described in the initial terms and conditions during the sign-up transaction, following non-fixed time intervals.	No, this falls under MIT provided that the cardholder is off-session at the time when the charge occurs.	ContAuth	UnscheduledCardOnFile
One-off account status check	Transaction with a zero-value authorisation to validate the shopper's account status.	Generally does not require SCA.	Ecommerce
	Transaction with a USD 1 authorisation, for issuers that do not accept zero-value authorisation.	Generally requires SCA, unless exemption applies.	Ecommerce
Purchase through MOTO	Mail Order / Telephone Order transaction. For example, a shopper calls a travel agency and the agent initiates a transaction.	No, this transaction is out of scope of PSD2 SCA.	Moto
Purchase through POS	Regular purchase at a payment terminal in a store	This is a shopper-present transaction where shopper performs SCA in-store, for example, through chip-and-pin authentication.	POS
Adjust authorisations	Transactions submitted with the /adjustAuthorisation endpoint, used for example in tipping scenarios.	No, this falls under MIT.

Use the following values for shopperInteraction and recurringProcessingModel parameters:

• shopperInteraction: Specifies the sales channel through which the shopper gives their card details, and specifies whether the shopper is a returning customer. Possible values are:

  • Ecommerce: Customer-initiated transactions (CIT). These transactions can be one-off online purchases or transactions that start a series of ContAuth transactions.
  • ContAuth: Transactions using the shopper's stored card details. Cardholder is known to the merchant (a returning customer).
  • Moto: Mail-order and telephone-order transactions where the shopper is in contact with the merchant through mail or telephone.
  • POS: Point-of-sale transactions where the shopper is physically present to make a payment using a secure payment terminal.

• recurringProcessingModel: Defines a recurring payment type. Possible values are:

  • Subscription: Contracts for a series of transactions with fixed or variable amounts, following a fixed time interval. If not set in the payment request, this will be the default value for shopperInteraction ContAuth.
  • CardOnFile: Models where a shopper stores card details and then purchases from the website or app at a later time using the stored card details.
  • UnscheduledCardOnFile: Contracts that occur on a non-fixed schedule and/or have variable amounts using stored card details. For example, automatic top-ups when cardholder's balance drops below certain amount.

  If you set up a default Recurring Processing Model on your account, all transactions from your account will use the assigned default model. If you want to set the Recurring Processing Model on a transaction level, submit the values in your API request. For more information, refer to Tokenization.

MIT framework

If you are not tokenizing cards with Adyen and are using your own or an external card vault, use the card schemes' MIT framework to maximize the probability of the transaction being correctly classified as MIT.

Under PSD2, SCA is required on the sign-up for a series of Subscription or UnscheduledCardOnFile payments. You need to store the returned networkTxReference to be able to include it with subsequent payments. Failing to do so can cause issuers to return soft declines.

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.	First transaction where shopper agrees to the contract.	Yes.	Ecommerce	Subscription or UnscheduledCardOnFile	This value is returned in the additionalData.networkTxReference in the response. Save this scheme transaction identifier for use in the subsequent transactions.
	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.

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