Search

Are you looking for test card numbers?

Would you like to contact support?

PSD2 SCA compliance and implementation guide

Check this page frequently as we will add new sections and topics when we receive more guidance from card schemes. If you have questions on topics not covered in this guide, contact Support Team.

The information we provide on this page is meant to help you prepare for PSD2 SCA compliance using 3D Secure. However, the information here should not be taken as legal advice. This guide is intended to supplement the following sources:

  • Regulatory guidance provided by official domestic authorities
  • Card scheme regulations
  • EMVCo specifications on the 3D Secure 2 protocol

PSD2 overview

The Revised Payment Services Directive (PSD2) is the latest version of the Payment Services Directive, a European regulation governing electronic and non-cash payments first introduced in 2007 and then updated in 2015. PSD2 includes a mandate for payment service providers to implement strong customer authentication (SCA) to make payments more secure for cardholders.

Scope

  • PSD2 mandate applies to the following countries within the EEA: Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Monaco, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, and the UK.
  • PSD2 mandate applies to all transactions where both the issuing and acquiring banks are located within the countries listed above.
  • Some online payment transactions are not within the scope of PSD2. See PSD2 out-of-scope transactions.

Strong customer authentication (SCA)

PSD2 mandates strong customer authentication for online payments and online banking transactions. This means that before issuing banks authenticate a transaction, the shopper is required to provide two out of three factors:

  • Something only the shopper knows.
  • Something only the user possesses.
  • Something the user is.

For example, before an issuing bank authenticates and authorises a payment, a shopper is required to supply a one-time authentication code received on their phone (something the shopper has), and a password that only the shopper knows (something the shopper knows).

Not all transactions are required to undergo SCA. These transactions are classified as possible exemptions, and if the issuing bank approves, may not require SCA. See Possible SCA exemptions.

To make sure your transactions are PSD2 SCA compliant, you need to implement 3D Secure.

Using 3D Secure for SCA compliance

If you are using our Checkout SDKs, HPP, Plugins, or APIs with 3D Secure 1 integration, you are already PSD2 SCA-compliant and you don't need to do anything. You can also already support 3D Secure 2 through the same redirect authentication.

To ensure that your transactions meet SCA requirements, we recommend that you support both 3D Secure 1 and 3D Secure 2. We expect that by 14 September 2019 (the PSD2 SCA compliance date), some European issuing banks may not be ready yet for 3D Secure 2 and still use 3D Secure 1 to comply with SCA.

In the note above we explained that if you already have an existing 3D Secure 1 integration with us, you can choose to not do anything. However, we also have existing solutions to support 3D Secure 2 authentication natively within your app or payment form. If you decide to implement native 3D Secure 2 authentication in addition to your 3D Secure 1 integration, check out our 3D Secure implementation options.

Next, see our list of important things to consider for PSD2 SCA compliance.

PSD2 SCA compliance checklist

Before you proceed with the rest of the guide, we recommend that you use this checklist to track your PSD2 compliance progress.

Aspects to consider Action that you need to take
Your technical implementation Make sure that you are ready to support both versions of 3D Secure. See 3D Secure implementation options.
Your business model If you are using API integration, check if your transactions require SCA and submit the correct parameters in your API request.
Your strategy for managing SCA compliance

Decide on how you want to manage SCA compliance for your transations. Your options are to:

  1. Do nothing and let us handle your SCA compliance. We will configure a default 3D Secure rule by 14 September 2019 (the PSD2 SCA compliance date). You can also contact us to configure this before the said date so you can already start testing your integration.
  2. Use Dynamic 3D Secure to configure additional conditions when to trigger 3D Secure. For example, configure rules for transactions you deem as high risk. If you are already using Dynamic 3D Secure, check your current rules to ensure that 3D Secure will be triggered for all transactions with an SCA mandate.
  3. Submit your 3D Secure preference per transaction in your API request. If you choose this option, this will override our default PSD2 compliance handling logic. We recommend to use the API fields only if you have an extensive knowledge of PSD2 SCA regulations and the 3D Secure protocol.

PSD2 out-of-scope transactions

If you want to know how this will impact your technical implementation based on your business model, see SCA requirements based on business models.

Out-of-scope transactions are transactions not covered by the PSD2 mandate. The issuing bank will not apply any strong authentication and guarantees that shoppers will not be presented with an authentication challenge, unless you specifically ask for 3D Secure in your payment request.

Out-of-scope transactions include:

  1. Interregional transactions: Payments where the card was issued outside of Europe or where the country you are acquiring from is outside of Europe. Some European issuing banks are expected to require SCA anyway even if a payment is acquired outside of Europe.
  2. Merchant-Initiated Transactions (MIT) and Direct Debits: A payment or a series of payments with fixed or variable amounts that the merchant performs without direct involvement of the shopper. Examples are subscriptions, automatic account top-ups, and installments. The initial transaction should have gone through SCA and the shopper should have agreed to the terms and conditions of the succeeding MITs. To ensure that your transaction is accurately classified as MIT, see SCA requirements based on business models for more information on MIT implementation. Adjust authorizations are also considered MIT.
  3. Mail Order and Telephone Orders (MOTO): MOTO transactions are not considered to be electronic payments, so these are out of the scope of the regulation.
  4. Anonymous cards: This type of cards can only be identified by the issuing bank. For example, anonymous prepaid cards.

Possible SCA exemptions

For transactions within the scope of PSD2, you or Adyen can request for an SCA exemption if the transaction meets any of the criteria in the following list. The issuer decides if the exemption is granted or not. For some types of transaction, the issuer can grant an exemption without you or Adyen requesting for it.

If a transaction is in scope of PSD2 SCA, by default Adyen will apply and request for the most suitable exemption type on your behalf. If you want to manage exemption requests on your own, see Managing PSD2 compliance.

You can request for exemptions for the following types of transactions:

  1. Low Value: Transactions under EUR 30 do not require SCA but the issuing bank will keep track of certain counters such as the number of transactions or the sum of transaction amounts. If the shopper's transactions for one card exceed the counter, for example, after five consecutive transactions or if the sum exceeds EUR 100, the issuing bank will require SCA.
  2. Low Risk / Transaction Risk Analysis (TRA): Issuing banks can consider transactions as low risk based on the average fraud levels of the card issuer, or of the acquirer processing the transaction, or of both.
    TRA has two kinds of implementation:
    • TRA exemption request from you or your acquirer: You can request the issuer for a TRA exemption if your fraud levels are below fraud thresholds. If the exemption is granted, the chargeback liability stays with you.
    • TRA exemption from the issuer: The card issuer can apply the TRA exemption even if you or your acquirer did not request for it. Send additional information in your payment request to maximize the probability of getting the exemption. The chargeback liability shifts to the issuer.
  3. Recurring transactions with exact same amount. This exemption is expected to be overridden by MIT and might be considered as out of scope.
  4. Whitelisted Merchants or Trusted Beneficiaries: After a strongly authenticated payment session, shoppers can add the merchant to a whitelist for the issuer. In 3D Secure 2, shoppers will be able to select a check box to add the merchant to a whitelist. The issuing bank will not require SCA on the next payments for the same merchant. However, note that this exemption depends on whether the issuer supports whitelisting.
  5. Secure corporate payments: These are payments made through dedicated corporate processes initiated by businesses and not available for consumers. Examples are payments made through central travel accounts, lodged cards, virtual cards, and secure corporate cards, such as those used in a corporate travel management system.

For technical implementation, see SCA requirements based on business models. If you have further questions on exemptions and out-of-scope transactions, contact Support Team.

Consequences of not being PSD2 SCA compliant

The PSD2 mandate is for banks, not for merchants. This means that issuing banks that approve non-compliant transactions are violating the law in their home country.

As issuing banks implement protocols to comply with PSD2 SCA regulations, you as a merchant should ensure that your transactions are compliant to avoid the risk of issuing banks refusing your transactions, leading to lower authorisation rates.

SCA requirements based on business models

As a general rule, expect that issuing banks will require SCA for transactions, unless the transaction is exempted or out of scope.

The following table shows common business models with the corresponding SCA requirements. For transactions that can be exempted from SCA, make sure to provide the correct payment request parameters so that we can classify and request for the most applicable exemption.

If your business model falls outside of the scenarios described in the table, contact Support Team for further guidance.

For MIT models that 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 was made on or after 14 September 2019.

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 was made on or after 14 September 2019. 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 /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, you should submit the values on your API request. See Tokenization for more information.

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.

If you are using our tokenization service, refer to SCA requirements based on business models.

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 Contact Support Team so we can send back the card scheme transaction identifier (for example, the Visa Transaction ID) in the response to the first transaction. 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 in 14 September 2019, 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. The static values will be supported until 31 October 2020.

Managing PSD2 SCA compliance

To handle PSD2 compliance, your options are:

Regardless of the option you choose, note that the general rule for chargeback liability shift applies. If you, Adyen on your behalf, or your acquirer requests for an exemption and the request is accepted by the issuer, the liability stays with you. If the exemption is applied by the issuer, the liability shifts to the issuer.

In addition to managing exemption requests, you can also help increase the probability of achieving an exemption by providing additional information in your payment request. Issuing banks can use these information and may then choose to apply the TRA exemption without the you requesting for it.

Option 1: Default PSD2 compliance handling

If you want to manage PSD2 compliance on your own, skip this section and proceed to handle PSD2 compliance on your own using Dynamic 3D Secure or submit preferences through your API request.

By default, our Authentication Engine will handle the PSD2 SCA compliance for you. We will not trigger 3D Secure for out-of-scope transactions or if the issuing bank does not enforce 3D Secure. Our Authentication Engine will also handle requesting for an exemption whenever applicable.

Option 2: Configure rules with Dynamic 3D Secure

Skip this section if you want to use our default compliance handling. If a transaction is eligible for PSD2 SCA, by default Adyen will apply and request for the most suitable exemption type on your behalf.

Use Dynamic 3D Secure to define additional conditions for transactions that you want to apply 3D Secure authentication on. For example, you can set conditions to use 3D Secure for transactions that you deem as high risk.

Scenarios Action from Adyen
Transaction meets condition with a Use 3DS: Always rule We will request the issuer to perform 3D Secure 1 or 2 depending on the version supported by the issuer.
Transaction meets condition with a Use 3DS: Prefer no rule We will not request for 3D Secure authentication unless the issuing bank requires it to complete the authorization.
Transaction does not meet any of your configured rules We will apply our default PSD2 compliance handling by 14 September 2019. By default, we will trigger 3D Secure if a transaction is in scope of PSD2 and SCA is mandated. If an exemption is applicable for a transaction, we will manage the exemption request.

See Dynamic 3D Secure to learn how you can configure rules.

Option 3: Specify preference in your API request

Skip this section if you want to use our default compliance handling.

If you choose this option, this will override our default PSD2 compliance handling logic, including checking if the transaction is out of scope, determining the most suitable exemption type to request for, and evaluating whether to send the exemption in the authentication or authorisation request.

We recommend to use the API fields only if you have an extensive knowledge of PSD2 SCA regulations and the 3D Secure protocol.

To manage 3D Secure preferences on a per transaction level, submit the following fields in your API request. If you also have Dynamic 3D Secure rules enabled, transaction-level preferences will override rules set in Dynamic 3D Secure.

  • additionalData.executeThreeD: Indicates if you want to perform 3D Secure authentication for the particular transaction or not.

    • true: Perform 3D Secure authentication depending on the version the issuer supports.
    • false: Do not perform 3D Secure authentication. However, note that PSD2 SCA requirements might mandate you to perform 3D Secure anyway so if this is set to false, this increases the chance of getting the authorisation declined.
  • additionalData.scaExemption: Indicates the exemption type that you want to request for the particular transaction. If a value is specified, this will override our exemption logic.

    • lowValue
    • secureCorporate
    • trustedBeneficiary
    • transactionRiskAnalysis: By default, Adyen will determine whether it is possible to apply a TRA exemption on a transaction as per option 1. You also have the option to either apply the Transaction Risk Analysis (TRA) exemption per transaction yourself, or to disable the TRA exemption from being applied. You can configure this in our Customer Area. Navigate to Risk > Risk Settings > General > Perform TRA. If you choose either of these options, you will override Adyen’s choice to apply TRA for a transaction or not.
  • threeDS2RequestData.challengeIndicator: Indicates your preference for a challenge for the particular transaction.

    • noPreference: Default if not set.
    • requestNoChallenge
    • requestChallenge
    • requestChallengeAsMandate

If the issuer denies the exemption request, you will receive a soft decline code in the API response indicating that an authentication is required for the transaction. See our generic refusal reasons and raw acquirer responses.

The following table describes sample values:

executeThreeD value scaExemption provided? challengeIndicator provided? Action from Adyen
TRUE No No, by default this is noPreference. Adyen will perform 3D Secure authentication depending on the version the issuer supports.
TRUE Yes, for example transactionRiskAnalysis. No, by default this is noPreference. Adyen will apply and request for the specified exemption in the authentication request, after the device fingerprint is submitted to the issuer. Card schemes will start supporting this from August or September 2019.
FALSE Yes, for example lowValue. No, by default this is noPreference. Adyen will apply and request for the specified exemption in an authorisation request. Device fingerprinting will not be performed.
FALSE No No, by default this is noPreference. Adyen will not apply 3D Secure authentication for the transaction.
TRUE No Yes, for example requestNoChallenge Adyen will perform 3D Secure authentication depending on the version the issuer supports. We will relay your challenge preference to the issuer, however, it is up to the issuer to decide if the shopper gets a challenge or not.

Sample request for 3D Secure 2 exemption

{
  "amount":{
    "currency":"EUR",
    "value":1000
  },
  "reference":"YOUR_ORDER_NUMBER",
  "paymentMethod":{
    "type":"scheme",
    "encryptedCardNumber":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "encryptedExpiryMonth":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "encryptedExpiryYear":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "encryptedSecurityCode":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "holderName":"S. Hopper"
  },
  "additionalData" : {
     "allow3DS2" : true,
     "executeThreeD" : true,
     "scaExemption" : "transactionRiskAnalysis"
  },
  "browserInfo":{
    "userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/70.0.3538.110 Safari\/537.36",
    "acceptHeader":"text\/html,application\/xhtml+xml,application\/xml;q=0.9,image\/webp,image\/apng,*\/*;q=0.8",
    "language":"nl-NL",
    "colorDepth":24,
    "screenHeight":723,
    "screenWidth":1536,
    "timeZoneOffset":0,
    "javaEnabled": true
  },
  "shopperIP": "192.0.2.1"
  "channel" : "web",
  "origin" : "https://your-company.com/",
  "returnUrl" : "https://your-company.com/checkout/",
  "merchantAccount":"YOUR_MERCHANT_ACCOUNT"
}'

See also