3DS

Overview

3D Secure serves as a security safeguard, protecting online payment data and simplifying consumer payment experience.

DECTA's payment solution has been meticulously designed to comply with PSD2 regulations, effectively addressing the mandatory Strong Customer Authentication (SCA) requirements and the exemptions from SCA.

Integration with MPI

To ensure secure payment processing, the merchant system is required to complete 3D authentication (3D Secure / UCAF) before sending a request to the Payment Server. This authentication step is necessary for most types of transactions, except for refunds or reversals.

Key details that the merchant system can expect to receive in the response from the MDPay MPI (Merchant Plug-In) include sli or eci, cavv, xid, 3ds_protocol, and 3ds_ds_id, mdStatus (it is not mandatory for all these details to be present).

Mapping of MDpay MPI mdStatus and ECI/SLI

¹ Status only for EMVco 3DS 2.2.x and 2.3.x; for EMVCo 3DS 2.1 Txn Status =N and Txn status reason =81
² Sheck transaction status reason for more details
³ Merchant optional and applicable to Mastercard cards only; i.e., it is up to the merchant to decide whether to submit transaction for authorisation or do not

Compliance with Requirements of PSD2

Payment solution by DECTA is built to support the requirements of PSD2 for Strong Customer Authentication (SCA) as well the exemptions from SCA. EBA regulations and payment schemes are supporting seven types of payments where SCA exemptions could be applied:

• recurring payments (SCA exemption per EBA);
• low value payments (SCA exemption per EBA);
• transaction risk analysis (SCA exemption per EBA);
• secure corporate payment (SCA exemption per EBA);
• merchant whitelisting (SCA exemption per EBA);
• merchant initiated payment (out of PSD2 scope);
• authentication outage (out of PSD2 scope).

These payments (except authentication outage exemption) should be performed with involvement of MPI (highly recommended by payment card schemes and then payment must include valid 3D data fields) or without 3D. Authentication outage SCA exemption should be used only in authorisation mode without 3D.

Recurring Payments

If a recurring (regular) payment is made as described in the Recurring scenarios section, then DECTA will automatically provide the SCA exemption flag recurring payment to payment card schemes.

If the card and payment data is stored on the IPSP side, then the IPSP must provide the initial transaction identifier cof_original_tid with other recurring payment data. The initial transaction ID is returned to IPSP, where the initial transaction response is in TLV format and the data field iss_ref_data is populated with tag 0003.

Merchant Whitelisting

DECTA does not support merchant whitelisting or trusted beneficiary exemption. This means that DECTA does not provide a mechanism for merchants to maintain a whitelist of trusted beneficiaries or recipients. Any payment or transaction must adhere to standard processing procedures without exceptions based on whitelisting.

Low Value Payments

IPSP must use sca_exemptions detail with value "1" to flag the payment as low value payment for the SCA exemption to be applied.

Transaction Risk Analysis

IPSP must use sca_exemptions detail with value "01" to flag that transaction risk analysis is performed by the merchant and the transaction could apply for the SCA exemption.

Secure Corporate Payments

IPSP must use sca_exemptions detail with value "0001" to flag that the transaction was authenticated, using a secure corporate payment process or protocol and the transaction could apply for the SCA exemption.

Merchant Initiated Transaction

If a merchant initiated payment (irregular (ad-hoc) or installment) is made as described in Recurring scenarios section, DECTA will automatically provide the SCA exemption flag "merchant initiated transaction" to payment card schemes.

If the card and payment data are stored on the IPSP / merchant side, then IPSP / merchant must provide the initial transaction identifier (cof_original_tid) with other payment data. Initial transaction ID is returned to IPSP / merchant, where the initial transaction response is in TLV format and the data field iss_ref_data is populated with tag "0003".

Authentication Outage

IPSP must use sca_exemptions detail with value "00000001" to flag that the transaction was not authenticated with SCA due to 3D authentication system shortage at the time of the purchase, and the merchant asks to apply the SCA exemption for this transaction.

VISA Authorisation Downgrade

When processing a 3D secure authorisation, Visa may downgrade a 3D Secure authorisation to non-3D Secure, if the field 44.13 in the issuer's response is "0". In such case,iss_ref_data will contain "CAVR" with the value of 0.

If the IPSP disagrees with Visa's downgrade, they should perform an authorisation reversal as for cancel / return or REFND scenarios. If the IPSP agrees with Visa's downgrade, no further action is needed, and the transaction proceeds as non-3D Secure.

Soft Decline

During authorisation, the issuer may respond with a "soft decline" (as described in the authorisation response code 160). Merchants are obligated to follow a specific process when encountering a soft decline to ensure compliance with ICO (Interchange Organization) rules:

• When a soft decline is received, merchants should initiate 3D authentication with an additional challenge identifier TDS2.threeDSRequestorChallengeInd (also known as threeDSRequestorChallengeInd in the EMVCo specifications);
• After initiating the 3D authentication, the merchant should repeat the card authorisation request. This authentication should occur within an already established cardholder session;
• If 3D authentication is mandated, such as recurring payment initialization or SCA-mandated authentication for EEA (European Economic Area) issuers, merchants should use TDS2.threeDSRequestorChallengeInd=04;
• If 3D authentication is not mandated, merchants should use TDS2.threeDSRequestorChallengeInd=03;
• If a soft decline is received on a fully authenticated transaction (SLI 212), there is no need to repeatedly perform authentication. The transaction cannot be further processed.

Following these steps ensures compliance with ICO rules when encountering soft declines during the card authorisation, helping to maintain security and regulatory adherence in payment transactions.

Apple Pay and PSD2 SCA

PSD2 requires that SCA must be applied to all electronic payments - including proximity, remote and m-payments within the EEA.

Usually 3D Secure implementation is enough to meet the SCA requirements. However, Apple does not allow usage of 3D Secure in conjunction with the Apple Pay as Apple Pay payments should be considered as two factor authenticated payments.

Therefore, Apple Pay implementation is SCA compliant and this is currently verified for Mastercard and Visa payments.

---