The second version of the European Payment Service Directive or PSD2 for short is a major driving force behind stronger security and equality of the European payments market. Part of the directive is specifically regarding the use of Strong Customer Authentication for remote transactions. For cards this means all non-cardholder-present transactions that fall within the scope of this directive need some kind of strong customer authentication. Version 2 of 3-D Secure addresses this requirement with an improved user experience compared to the old version of 3-D Secure. Both are compliant with the regulation, as long as the issuer uses the right factors to authenticate their users.

Out of scope for PSD2 RTS SCA

Certain types of transactions are out of scope for the Payment Service Directive 2 (PSD2) Regulatory Technical Standards (RTS) Strong Customer Authentication (SCA) requirements. This simply means you aren't required to perform Strong Customer Authentication on these transactions, as in most cases the consumers aren't online to authenticate themselves.

Here are an overview of these types of transactions.

Anonymous prepaid cards

Due to their very nature, payments made through the use of an anonymous payment instrument such as anonymous prepaid (e.g.) gift cards, are't subject to the obligation of strong customer authentication.

Mail Order / Telephone Order (MOTO)

The PSD2 RTS is not covering Mail Order/Telephone Order (MOTO) transactions. Worldline automatically skips 3-D Secure for transactions that are flagged as MOTO, MAIL or TELEPHONE using the transactionChannel property.

One-leg transactions (one leg in the EEA, the other out)

The location of the consumer is determined based on the location of their issuer. Your location, however, is based on the location of the acquirer used to process the transaction. If one or both of these are not within the European Economic Area (EEA) PSD2 RTS SCA (Strong Customer Authentication) is't required.

Based on the Issuer Identification Number (the first 6 digits of the cardnumber, this is sometimes also refered to as BIN) of the card processed and the acquirer used for the transaction, Worldline determines if SCA is required. If you know the transaction will be processed through an acquirer inside the EEA you can create a Dynamic 3D Secure rule, which is based on the country where the card was issued.

Merchant Initiated Transactions (MIT)

Merchant Initiated Transactions are payments initiated by you without the interaction of the payer. Such payments can happen in the following cases:

• Recurring Payments for fixed or variable amounts.
• The final amount is higher than the amount used at authentication time. This can happen when additional charges are added to the initial agreed amount.

In our API merchant initiated transactions are flagged as either a recurring transaction (isRecurring = true and recurringPaymentSequenceIndicator = recurring) or as a subsequent unscheduled card on file transaction (unscheduledCardOnFileRequestor = merchantInitiated and unscheduledCardOnFileSequenceIndicator = subsequent).

Importantly, it's required to perform a Consumer Initiated Transaction (CIT) with SCA in order to setup a MIT. Three possible cases of CIT transaction types exist using our API, which are:

• First of a recurring, flagged by setting the isRecurring property to true and setting the recurringPaymentSequenceIndicator property to first. Please note that you'll also have to provide the endDate and the minFrequency properties in this case
• First of an Unscheduled Card On File (UCOF) transaction, flagged by setting the unscheduledCardOnFileRequestor property to cardholderInitiated and the unscheduledCardOnFileSequenceIndicator property to first
• Subsequent Unscheduled Card On File (UCOF) transaction that is initiated by the consumer, flagged by setting the unscheduledCardOnFileRequestor property to cardholderInitiated and the unscheduledCardOnFileSequenceIndicator property to subsequent

Providing a link back to the CIT

It will be required to provide a link back to the CIT with SCA transaction when sending in a MIT. To create this link, you submit the schemeTransactionId you received in the response when you performed the CIT in the initialSchemeTransactionId property in your request.

If the initial CIT occurred before the 14^th of September 2019, and the initialSchemeTransactionId is unknown, then it's advisable to submit either the schemeTransactionId of the last transaction belonging to the same chain or in case of Mastercard, a dummy value of "MCC99999991231 ".

Exemptions

For transactions that aren't out of scope for Strong Customer Authentication (SCA), it is possible to request an exemption to be used. Possible exemptions that can be requested are:

• Transaction Risk Analysis (TRA)
  • The value of the transaction must be less than EUR 500, and
  • Your acquirer's fraud rate must be within the reference fraud rate for the relevant transaction value band, and
  • The acquirer must be prepared to apply the exemption on behalf of you, and
  • Transaction risk analysis must have been undertaken by your acquirer, us (through the use of fraud screening) or by yourself on behalf of the acquirer, and
  • The transaction must have been assessed to be at low risk of fraud
• Low Value
  • The value of the transaction must be less than EUR 30, and
  • The number of consecutive transactions since the last SCA must not exceed five, or the cumulative value of the consecutive transactions since the last application of SCA must not exceed EUR 100
• Whitelist
  • You are qualified for application of a whitelist or trusted beneficiary exemption by the issuer, and
  • The cardholder has added you to its list of trusted beneficiaries that is held and managed only by the issuer (existing trusted beneficiary)

You can request the use of exemptions per transaction using the exemptionRequest property. This property also supports an automatic setting that mechanically selects the most appropriate exemption, based on the parameters of your transaction.