Smart 3DS

Smart 3D Secure, or Smart 3DS, allows PXP Financial to decide dynamically - depending on criteria set up for the merchant - if 3D Secure should be used to authenticate a customer or not.

❗️

Applicability of Smart 3DS

Smart 3DS Logic is applied only if the card is enrolled in 3DS 2.0 and PSD2 is not mandated (i.e. a one-leg-transaction).

If the card is enrolled in 3DS 2.0 and PSD2 is mandated, then Smart 3DS cannot be applied, as SCA will be necessary.

If the Smart 3DS conditions are met, the a standard browser-based 3DS2 flow will apply. If the conditions are not met, then the standard card deposit flow will apply.

📘

Prererequisites for using Smart 3DS

• Merchant uses PXP Financial's 3DS Server
• Merchant has specified a set of conditions when customers need to authenticate and when they do not have to authenticate
• Merchant System is passing the IsThreeDSecureConditionalRequired = true parameter in the initiatePayment (for direct integration) or in getRedirectData (for Checkout based integration).

When does it make sense to use Smart 3DS?
If the merchant does not want to perform SCA on every transaction, Smart 3DS should be used.

For example, the merchant may require the customer to authenticate only once every 5 days, and only if the amount exceeds 50 EUR. Additionally, because some card issuers provide a bad mobile authentication experience, the merchant may decide to skip 3DS authentication for such cards.

Factors that can be used to determine the authentication experience:

• Has this card ever been successfully authenticated by this customer?
• The number of days passed since the last successful authentication of this card by this customer
• The result of the last authentication. If the last authentication failed, the merchant will probably not allow a customer to skip 3DS under any circumstance
• The country of the issuing bank of the card used
• The payment option selected by the customer (Visa, Mastercard). Please also note that a Maestro payment always needs to be authenticated
• The Acquirer being used - this can be PXP Financial or an alternative Acquirer integrated into PXP Financial's Gateway
• The total number of successful purchases the customer has done with this card
• The payment amount
• The specific BIN of the card, if such granularity is required
• The name of the Card Issuer
• The purchase volume of the customer in the last 24 hours, 7 days or 30 days
• The time of day the purchase is made (maybe those purchase requests coming at 4-6 AM are slightly more suspicious?)
• The information if a customer is a VIP user
• The date when the user has been registered in the merchant portal
• The date when the user has made his last activity in the merchant portal.
• The type of the device which has been used by the customer

All these parameters can be freely combined into a set of rules.

📘

Examples

For issuer 1, who provides a good and intuitive 3DS authentication experience, the merchant wants to ask his customers to authenticate only once every 7 days if their total purchase volume in those 7 days does not exceed 200 EUR and as long as their last authentication attempt was successful.

For issuer 2, who does not offer a positive 3DS authentication experience, the merchant wants to ask his customers to authenticate only once every 14 days, provided the amount of the transaction is not more than 20 EUR and the total volume in the last 7 days does not exceed 150 EUR.

Example initiatePaymentRequest:

<?xml version="1.0" encoding="utf-8"?>
<initiatePaymentRequest xmlns="http://www.cqrpayments.com/PaymentProcessing" 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <merchantID>KalixaAcceptDEMO</merchantID>
  <shopID>KalixaAcceptDEMO</shopID>
  <merchantTransactionID>VISA_Test</merchantTransactionID>
  <paymentMethodID>2</paymentMethodID>
  <amount currencyCode="EUR">10</amount>
  <userID>KalixaTestUser</userID>
  <userData/>
  <userIP>127.0.0.1</userIP>
  <userSessionID>8a957ebe-d903-4b01-8170-20dae95673a1</userSessionID>
  <creationTypeID>1</creationTypeID>
  <specificPaymentData>
    <data xsi:type="keyStringValuePair">
      <key>PaymentDescription</key>
      <value>some description</value>
    </data>
    <data xsi:type="keyStringValuePair">
      <key>PaymentDescriptionLanguageCode</key>
      <value>en</value>
    </data>
    <data xsi:type="keyBooleanValuePair">
      <key>IsThreeDSecureConditionalRequired</key>
      <value>true</value>
    </data>   
    <data xsi:type="keyBooleanValuePair">
      <key>ShouldAllow3DSFallback</key>
      <value>true</value>
    </data>   
    <data xsi:type="keyStringValuePair">
      <key>BrowserHeaderAccept</key>
     <value>text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8</value>
    <data xsi:type="keyStringValuePair">
      <key>BrowserHeaderUserAgent</key>
     <value>Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0</value>    
    </data>
  </specificPaymentData>
  <paymentAccountID>VISATestAccount</paymentAccountID>
  <paymentAccount>
    <specificPaymentAccountData>
      <data xsi:type="keyStringValuePair">
        <key>CardNumber</key>
        <value>4111111111111111</value>
      </data>
      <data xsi:type="keyStringValuePair">
        <key>HolderName</key>
        <value>Test</value>
      </data>
      <data xsi:type="keyStringValuePair">
        <key>CardVerificationCode</key>
        <value>111</value>
      </data>
     <data xsi:type="keyIntValuePair">
        <key>ExpiryMonth</key>
        <value>1</value>
      </data>
      <data xsi:type="keyIntValuePair">
        <key>ExpiryYear</key>
        <value>2025</value>
      </data>
    </specificPaymentAccountData>
  </paymentAccount>
</initiatePaymentRequest>

Depending on the Smart 3DS configuration, the initiatePaymentResponse will contain either a payment state related to the 3DS outcome (e.g. UserAuthenticationSuccessful), or a final card deposit authorization state (AuthorisedByProvider/RefusedByProvider).