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.
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! | |
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. | |
Saving Cards | You must make sure, that SCA is performed during a card registration. This also includes such cases, where you do not intend on performing MITs and instead only want to provide a service, where your customer does not have to insert their card again. Note: The Payment Page and Transaction Interface perform 3DS automatically during the process. However note, that, if your intention is to maybe perform MITs, you must force SCA -see further down-. With normal CITs, this is not necessary, the default 3DS process is sufficient. |
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. | |
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 |
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: During an initial transaction, for Recurring Payments, SCA is automatically enforced, if either
Payment.Recurring.InitialorPayment.Installment.Initialare set totrue.
While these settings do cover 99% of all transactions, Worldline has been made aware of certain banks/issuers behaving in a non-compliant manner. Thusly, it can happen, that some transactions will be processed as frictionless, even though a challenge has been requested. Please always check the authentication result at the end of the transaction.
During a transaction: Please check the
Liability.ThreeDs.AuthenticationTypeparameter and make sure, that it is set toSTRONG_CUSTOMER_AUTHENTICATION.Standalone registration: Please make sure, that
CheckResult.Authentication.ResultisOK.
This behavior is currently out of the control of Worldline Saferpay and has been reported.
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!
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!
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!
If you have a high risk business, or generally want a higher level of protection against fraud, you can, of course, force SCA too!
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.
SCA Exemptions
SCA Exemptions are certain cases, where SCA either doesn't have 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).
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!
Even if you are allowed to submit exemptions, you have to make sure, that your implementation generally follows the PSD2 rules!
When an exemption is granted, no Liabilityshift through 3D Secure is given! You, the merchant, will thus take full responsibility, in case of fraud!
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).
Furthermore, while it may seem so, 3D Secure will still be attempted (If the flow supports it!). You still have to do a redirect. Saferpay will forward your requested exemption to the bank and the bank will decide, whether they accept the exemption, or not.
If it is accepted, 3DS will be skipped and Saferpay will continue with the next step.
If it is rejected, 3D Secure will still be performed, as normal.
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:
| |
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! | |
Authentication.Exemption: "RECURRING" | DO NOT USE THIS, IF YOU DO NOT KNOW, THAT YOU ARE ALLOWED TO O SO! This is a special exemption for extreme edge-cases and does not necessarily do, what you think it does! | |
Authentication.ThreeDsChallenge: "AVOID" | A 3D Secure authentication 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)! |
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
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:
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.
These values then can be transferred to the external system.
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
Example of a Soft Decline Error message with Visa/American Express
Test Cards
If you want to force a Soft-Decline response, you can do so, by using our test-cards, found in this chapter.
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.
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!
Thusly, we highly recommend, that you implement a Soft Decline handling, to automatically recognize this error and maybe contact your customers.
Last updated