This page is an overview of all PSD2 SCA requirements, organized by business model. It also shows transaction types within business models, whether these transaction types require SCA, and which payment request parameter values to use.
Business models
The following table shows common business models and whether SCA is required for each type of transaction:
| Business model | Transaction type | SCA required? | Payment request parameters | |
|---|---|---|---|---|
shopperInteraction value |
recurringProcessingModel value |
|||
| 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 where shopper agrees to the contract. 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 authorization to validate the shopper's account status. | Generally does not require SCA. | Ecommerce | |
| Transaction with a USD 1 authorization, for issuers that do not accept zero-value authorization. | 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 | |
| Authorization adjustment | Transactions submitted with the Classic/adjustAuthorisation or Checkout/amountUpdates endpoint, used for example in tipping scenarios. | No, this falls under MIT. |
||
Payment request parameters
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.
Merchant-Initiated Transaction framework (MIT)
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 for the first transaction of a series of Subscription or UnscheduledCardOnFile payments. You need to store the returned additionalData.networkTxReference to be able to include it with subsequent payments. Issuers can return soft declines if you fail to do so.
The following table describes transactions for a Subscriptions business model:
| Transaction type | SCA required? | shopperInteraction value |
recurringProcessingModel value |
Additional implementation steps |
|---|---|---|---|---|
| First transaction where shopper agrees to the contract | Yes. | Ecommerce | Subscription or UnscheduledCardOnFile | This value is returned in the networkTxReference field of the /payments/details 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 networkTxReference field in your payment request. This allows the issuing bank to link the subsequent recurring charge with the initial, fully authenticated sign-up transaction. |