The following table shows common business models with the corresponding SCA requirements.
|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. For more information, refer to our Support guide.
|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. For more information, refer to our Support guide.||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 $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
||No, this falls under MIT.|
Use the following values for
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.
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
|Subsequent charges||No, this falls under MIT.||ContAuth||Subscription or UnscheduledCardOnFile||Provide the card scheme transaction identifier in the
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
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).