PSD2

With the introduction of PSD2 within the EU, the ruleset for doing card transactions, has been changed in many ways. Specifically the need for Strong Consumer Authentication needs special attention from merchants. This chapter will contain important information on PSD2 and SCA specifically.

Does PSD2 apply to me?

The first step, is to figure out, if PSD2 applies to you -the merchant- in the first place. Important to know is, that PSD2 is valid for all countries inside the EEA (European Economic Area), which is NOT the same as the European Union! However the important part is, where you have signed your acquiring contract! When signing a card acceptance contract with an Acquirer, you have to pay attention to the country in which the contract is signed! Should this country be inside the EEA, then PSD2 does apply to you! This is also applies, if you -the merchant- have your company headquarters outside the EEA!

However should PSD2 not apply to you, then you do not have to follow the rules for SCA. Even though we highly recommend doing 3D Secure, since it is also an anti-fraud measure, you can request an exemption, to avoid 3DS (see further below).

API-response

Saferpay also tries to determine, whether or not a transaction has been inside the PSD2 scope. This information is then returned to you via the API, through the Liability.InPsd2Scope parameter.

Example

{
  "ResponseHeader": {
    "SpecVersion": "[current Spec-Version]",
    "RequestId": "[unique request id]"
  },
  "Transaction": {
    "Type": "PAYMENT",
    "Status": "AUTHORIZED",
    "Id": "f3QnO7bxCnY1vAlOvvr5A4z9IphA",
    "Date": "2021-05-17T13:05:49.920+02:00",
    "Amount": {
      "Value": "245",
      "CurrencyCode": "EUR"
    },
    "OrderId": "0",
    "AcquirerName": "MasterCard Saferpay Test",
    "AcquirerReference": "05945355638",
    "SixTransactionReference": "0:0:3:f3QnO7bxCnY1vAlOvvr5A4z9IphA",
    "ApprovalCode": "292749",
    "IssuerReference": {
      "TransactionStamp": "767980829703",
      "SettlementDate": "0517"
    }
  },
  "PaymentMeans": {
    "Brand": {
      "PaymentMethod": "MASTERCARD",
      "Name": "MasterCard"
    },
    "DisplayText": "xxxx xxxx xxxx 0006",
    "Card": {
      "MaskedNumber": "xxxxxxxxxxxx0006",
      "ExpYear": 2021,
      "ExpMonth": 5,
      "HolderName": "John Doe",
      "CountryCode": "US",
      "HashValue": "0DBC2E4EB492F7AB4122602B46D60D89DEF51C8C"
    }
  },
  "Payer": {
    "IpAddress": "87.123.201.46",
    "IpLocation": "DE",
    "BillingAddress": {
      "FirstName": "John",
      "LastName": "Doe",
      "CountryCode": "de",
      "Email": "john.doe@provider.com"
    }
  },
  "Liability": {
    "LiabilityShift": true,
    "LiableEntity": "THREEDS",
    "ThreeDs": {
      "Authenticated": true,
      "LiabilityShift": true,
      "Xid": "4ca1a5e4-f9fc-4081-873f-f02e30547c81",
      "Version": "2",
      "AuthenticationType": "FRICTIONLESS"
    },
    "InPsd2Scope": "YES"
  }
}

When to do SCA?

As a rule of thumb, ask yourself the following question:

Is the card holder present, to enter his/her card details, or otherwise be able to interact with your webshop/system? If so: SCA has to be performed, in any case!

This also applies to card registrations, if the card holder is not present during the next, real, transaction!

Also make sure, that you use a flow, that can do SCA -in form of 3D Secure- in the first Place! Be it the Payment Page, the Transaction Interface or a Standalone Secure Card Data Registration with an ONLINE_STRONG check. Saferpay will always attempt 3D Secure and thus SCA!

Your acquiring contract also has to support 3D Secure! However most acquirers do not offer contracts without 3D Secure in the first place, without being explicitly asked for one. When in doubt: Ask your acquirer, if your contract is set up for 3D Secure, or not!

Overview

PSD2 is very complex. So to give you an overview of what flows need and what do not need SCA, please refer to the following tables:

Transactions and flows, that DO need SCA

Case Description Flows/Requests
Customer Initiated Transactions (CIT) This is your standard transaction-type. The card holder comes to the shop and orders something. The card holer is present during these transactions and as mentioned above, they must be covered with SCA and thus 3-D Secure! Payment Page Integration, Transaction interface Integration, Transaction Initialize & Transaction Authorize, Payment Page Initialize & Payment Page Assert
Initial Recurring/Installment Transaction This is a special type of Customer Initiated Transaction. With PSD2 the first (initial) transaction within a recurring-chain needs to be covered by SCA! Thus, we highly recommend forcing SCA (see further down in this chapter). Each subsequent transaction then references this transaction. Recurring Integration, Payment Page Integration, Transaction Interface Integration, Transaction Initialize & Transaction Authorize, Payment Page Initialize & Payment Page Assert
Saving Cards If you intend on saving cards with the intent of doing MITs (see below), with no card holder presence, you must make sure, that SCA is performed during registration! You should force SCA. More information, on how to force SCA, can be found, further down in this chapter! However, if you simply intend on just saving the card, so the card holder doesn't have to enter his card details again, during the next transaction, performed with 3D Secure you do not have to do SCA during the registration. Note If you register a card during aPayment Page or Transaction Interface transaction, with 3D Secure, then this registration is fully PSD2 compliant! Standalone Secure Card Data registration

Transactions and flows, that DO NOT need SCA

Case Description Flows/Requests
Merchant Initiated Transactions (MIT) Basically all transactions, that are triggered by Merchant, with the card holders consent, while not being present. However: SCA has to be made, while acquiring the card details for this transaction, e.g. via a Secure Card Data registration (see above)! Authorize Direct e.g. using an alias
Subsequent Recurring/installment Transaction These are transactions, that follow the initial recurring transaction (see above) and are a special type of Merchant initiated Transaction (see above). They must reference the initial transaction. Recurring Integration, Authorize Referenced
Mail Phone Order Transactions, where the payment means are provided to the merchant via phone, or mail. MPO transactions are out-of-scope of PSD2! SCA does not apply here! N/A
One legged CIT transactions Generally, we always recommend doing 3D Secure. However there are CITs, that do not need SCA. Cases are, if either the card issuer (bank of the card holder), or the Acquirer of the Merchant, are outside the EEA (European Economic Area)! However, what is important here for the latter, is, in which country the acquiring contract has been signed. For instance: If a swiss merchant signs a contract within germany and a german card holder comes to his shop, PSD2 does indeed apply, even though the merchant is not inside the EEA! However the card issuer and the acquirer are! N/A

When and how to force SCA

There are certain Cases, where SCA must be made, with no exception! Saferpay offers the option to force SCA during a transaction and you -the merchant- has to make sure, that the transaction (or registration) is covered by SCA in the following cases:

  • MITs via Card Alias: If you intend on doing any kind of MIT, like Recurring Payments, via an alias, you must force SCA during the registration.
    • Forcing SCA during a transaction: When registering a card, during a transaction, be it via the Transaction interface or the Payment Page, you must force a 3D Secure Challanged flow, by also setting the Authentication.ThreeDsChallenge parameter to FORCE, within the respective Initialization request.
    • Forcing SCA during a standalone registration: In some cases, it may be viable to save a card first, but charge it way later down the line. However, those transactions are usually MIT, with the card holder not being present! Due to that, SCA has to be performed during registration, requiring a Strong Online Check with SCA!
  • Initial Recurring Transactions: We highly recommend you also force SCA during an initial transaction, for Recurring Payments. When doing the initial transaction, be it through the Payment Page or the Transaction Interface, you should also set the Authentication.ThreeDsChallenge parameter to FORCE.

Important: This only applies, if you intend on doing MITs right after the registration! However if you plan on using the Alias for CITs with 3DS -and thus SCA- beforehand, or only that, then you do not have to consider this!


Tip: If you have a high risk business, or generally want a higher level of protection against fraud, you can, of course, force SCA too!


Tip: If you have previously created aliases, without the necessary SCA-Info attached, you can perform a transaction with forced SCA and Saferpay will automatically update the Alias, with the SCA-data, so you may use the Alias for MITs.


Important: Forcing SCA is only possible with Visa/Vpay, Mastercard/Maestro and American Express! Other card-brands are currently NOT MIT-compliant under PSD2 and thusly cannot be used in this way!


Caution: Forcing SCA during the first transaction/registration, does NOT excuse you from doing SCA/3D Secure afterwards, if you intend on doing CITs with a saved card! There are exemptions (see below), but those also have their own set of rules to follow!

SCA Exemptions

SCA Exemptions are certain cases, where SCA either doesn't havve to be applied, or cannot be applied! Transactions in these cases must be flagged accordingly, or they may be refused. Also, in any case, the merchant would perform transactions against the PSD2! The Exemption value may be submitted via the Authentication.Exemption parameter, within the respective initial request (see flows and requests column).

Caution: Do not submit exemptions on your own, without the consent of your Acquirer! The Acquirer otherwise has the right to deny these transsactions at any time!

Very Important: Even if you are allowed to submit exemptions, you have to make sure, that your implementation generally follows the PSD2 rules!

Warning: When an exemption is applied, no Liabilityshift through 3D Secure is given! You, the merchant, will thus take full responsibility, in case of fraud!

Important: The issuing bank always has the right to reject a transaction and ask for a full transaction, with SCA! This also applies to Recurring Transactions! In these cases, the transaction will run into a Soft decline (see below).

Exemption Usecase Flows and requests
Authentication.Exemption: "LOW_VALUE"

This transaction has an overall value of 30 Euros, or lower and thus does not fall under SCA by PSD2! However, that falls under certain rules:

  • After 5 transactions, without SCA, SCA must be performed again!
  • After a cumulative value of 100,-, SCA must be performed again!
 Payment Page Flow, Transaction Interface Flow
Authentication.Exemption: "TRANSACTION_RISK_ANALYSIS" External Fraud Risk Analysis has been done and the transaction has been deemed at low risk.

Tip: Interested in using such a tool? Saferpay Fraud Intelligence offers the possibility of automatically analyzing transactions and applying the TRA exemption for you, if applicable!

Payment Page Flow, Transaction Interface Flow
Authentication.Exemption: "RECURRING" This transaction is a subsequent, recurring transaction, which does not need SCA! Recurring Flow
Authentication.ThreeDsChallenge: "AVOID"

A 3D Secure challanged flow should be avoided for this transaction!

CAUTION: This value may only be used by merchants and transactions outside the PSD2 scope. Do not use this value, without evaluating, if PSD2 applies to you/the transaction, or not! Attempting a transaction inside the PSD2 scope, with avoidance, will lead to a soft decline (see below)!

Payment Page Flow, Transaction Interface Flow

Special Cases

While Saferpay aims to make handling these cases as trivial, as possible, there are certain special cases, that deviate from the usual flows and integrations.

Transferring SCA from and to Saferpay

CAUTION: This flow is only possible, if you are fully PCI certified!

In certain cases, it may be necessary to perform SCA through a system, that is not connected to Saferpay, or transfer existing SCA-data to an external system. While Saferpay does not support the inclusion of external 3D Secure-systems, it does support the transfer of the transaction stamp, once an authorization has been made with SCA. So please keep that in mind, since these two are not the same. The transaction-stamp is only returned by the bank on a successful authrorization of a card!

SCA transfer to Saferpay

The transfer of SCA-data to Saferpay is currently only supported, while doing MIT transactions, using Authorize Direct and a direct post of the card-data (note the PCI-warning above!). In order to reference the SCA-data, one must also submit the parameters Authentication.IssuerReference.TransactionStamp and Authentication.IssuerReference.SettlementDate (if applicable), alsongside the Authorize Direct request:

Example

{
  "RequestHeader": {
    "SpecVersion": "[current Spec-Version]",
    "CustomerId": "[your customer id]",
    "RequestId": "[unique request id]",
    "RetryIndicator": 0
  },
  "TerminalId": "[your terminal id]",
  "Payment": {
    "Amount": {
      "Value": "100",
      "CurrencyCode": "CHF"
    },
    "Description": "Test123",
    "PayerNote": "Order123_Testshop"
  },
  "PaymentMeans": {
    "Card": {
      "Number": "912345678901234",
      "ExpYear": 2015,
      "ExpMonth": 9,
      "HolderName": "Max Mustermann",
      "VerificationCode": "123"
    }
  },
  "Authentication": {
    "IssuerReference": {
      "TransactionStamp": "767980829703",
      "SettlementDate": "0517"
    }
  }
}

SCA transfer from Saferpay

Likewise, whenever a transaction is done with SCA, Saferpay will return these values, alongside the Payment Page Assert and Transaction Authorize authorization responses, inside the Transaction.IssuerReference container.

Example

{
  "ResponseHeader": {
    "SpecVersion": "[current Spec-Version]",
    "RequestId": "[unique request id]"
  },
  "Transaction": {
    "Type": "PAYMENT",
    "Status": "AUTHORIZED",
    "Id": "f3QnO7bxCnY1vAlOvvr5A4z9IphA",
    "Date": "2021-05-17T13:05:49.920+02:00",
    "Amount": {
      "Value": "245",
      "CurrencyCode": "EUR"
    },
    "OrderId": "0",
    "AcquirerName": "MasterCard Saferpay Test",
    "AcquirerReference": "05945355638",
    "SixTransactionReference": "0:0:3:f3QnO7bxCnY1vAlOvvr5A4z9IphA",
    "ApprovalCode": "292749",
    "IssuerReference": {
      "TransactionStamp": "767980829703",
      "SettlementDate": "0517"
    }
  },
  "PaymentMeans": {
    "Brand": {
      "PaymentMethod": "MASTERCARD",
      "Name": "MasterCard"
    },
    "DisplayText": "xxxx xxxx xxxx 0006",
    "Card": {
      "MaskedNumber": "xxxxxxxxxxxx0006",
      "ExpYear": 2021,
      "ExpMonth": 5,
      "HolderName": "John Doe",
      "CountryCode": "US",
      "HashValue": "0DBC2E4EB492F7AB4122602B46D60D89DEF51C8C"
    }
  },
  "Payer": {
    "IpAddress": "87.123.201.46",
    "IpLocation": "DE",
    "BillingAddress": {
      "FirstName": "John",
      "LastName": "Doe",
      "CountryCode": "de",
      "Email": "john.doe@provider.com"
    }
  },
  "Liability": {
    "LiabilityShift": true,
    "LiableEntity": "ThreeDs",
    "ThreeDs": {
      "Authenticated": true,
      "LiabilityShift": true,
      "Xid": "c54a264e-dae2-45ad-b784-3eaa6be6956c"
    }
  }
}

These values then can be transferred to the external system.

Important: Not all external systems may support this feature!

Non Compliance

What happens in case of non-compliance? With PSD2, every bank inside the EEA is now obliged to reject transactions, that are not PSD2-compliant.

So for instance, if you register card details for, for example, recurring payments, without enforcing SCA during the registration, the card holders bank is obliged to reject every MIT, as they are described above.

In these cases, a so called Soft Decline is thrown:

Example of a Soft Decline Error message with Mastercard

{ 
"ResponseHeader": {
   "SpecVersion": "[current SpecVersion]",
   "RequestId": "[unique request id]"
 },
 "Behavior": "ABORT",
 "ErrorName": "PAYER_AUTHENTICATION_REQUIRED",
 "ErrorMessage": "Transaction declined by acquirer",
 "TransactionId": "llOKnfAEW57QSAErGdIYbAtAQ1fb",
 "ProcessorResult": "1A",
 "ProcessorMessage": "Additional customer authentication required"
}

Example of a Soft Decline Error message with Visa/American Express

{ 
"ResponseHeader": {
   "SpecVersion": "[current SpecVersion]",
   "RequestId": "[unique request id]"
 },
 "Behavior": "ABORT",
 "ErrorName": "PAYER_AUTHENTICATION_REQUIRED",
 "ErrorMessage": "Transaction declined by acquirer",
 "TransactionId": "dOrvUAAWn16USAU8d08OA10A03SA",
 "ProcessorResult": "65",
 "ProcessorMessage": "Soft decline, SCA required"
}

Test Cards

If you want to force a Soft-Decline response, you can do so, by using our test-cards Over here.

What to do, in case of a Soft Decline

If you recieve a Soft Decline, you have to re-initiate your process, with forced (see above) SCA in mind. In case of the above example, the card details have to be re-registered, with SCA. The old Alias effectively becomes invalid and has to be re-created. This also applies to Referenced Recurring Transactions, requiring a new initial transaction, to start a new recurring-chain. So you must contact your customer, for him/her to go through the process again, e.g. via e-mail, or similar means.

Important Info: A bank has the right to request SCA and thus throw a soft decline at any point, if it deems it necessary! This is out of control of Wordline/Saferpay!

Back to Top