What’s a Rich Text element?

‍

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

‍

<script>
  /**
   * Writes the current year to all elements that match the selector.
   */
  function setCurrentYear() {
    const YEAR_ELEMENTS_SELECTOR = '[fs-hacks-element="year"]';

    const yearElements = document.querySelectorAll(YEAR_ELEMENTS_SELECTOR);
    const currentYear = new Date().getFullYear().toString();

    yearElements.forEach((yearElement) => {
      yearElement.textContent = currentYear;
    });
  }
  
  document.addEventListener('DOMContentLoaded', setCurrentYear);
</script>

‍

Static and dynamic content editing

‍

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

‍

How to customize formatting for each rich text

‍

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Inside payments

SCA: finding the balance between risk and friction

Apr 9, 2024
•
9 min read
Alex Rayson
Manager, Customer Success Operations

The application of SCA (Strong Customer Authentication) is mandatory under PSD2 for card-not-present CITs (Customer Initiated Transactions), where both the acquirer and the issuer are located within the regulated jurisdiction (EEA & UK). This requirement came into effect in September 2019. In this guide, we will aim to break down the core components of 3DS2, currently the most broadly adopted version of 3DS.

An intro to 3DS

3DS is the protocol defined by EMVCo for implementing authentication. 3DS allows merchants and payment providers to send over 100 data elements to help the issuer assess the risk level of a transaction and authenticate the cardholder. Merchants can benefit from 3DS by lowering their exposure to fraud and in specific cases, shifting liability for losses to the issuer. However, there may also be drawbacks in the form of increased customer friction which can lead to higher churn rates.

There are multiple components to 3DS which can all have a significant impact on merchants' Conversion Rate. Choosing the correct set-up for your business is critical to achieving the right balance of reduced risk and increased friction.

How the 3DS flow works

The 3DS Authentication flow encompasses interactions between 3 core components (3-Domain Secure);

3DS Components

    1. 3DS Requestor Environment:
      • 3DS Client: 3DS component of the merchants checkout interface that integrates to the 3DS SDK/Browser
      • 3DS SDK/Browser: Functional interface that initiates the 3DS authentication by collecting device data, presenting the challenge (if a challenge flow), and interpreting messages from the 3DS Server
      • 3DS Server: Server-side software that takes in transaction data and communicates with the Directory Server (DS).
    2. Directory Server (DS): Primary role is to connect acquirers and issuers by routing messages between the 3DS Server and the ACS. Also ensures authenticity of connected servers.
    3. Access Control Server (ACS): Operated by the issuer for the purpose of authenticating the cardholder through the interpretation of 3DS data. The technology is often licensed from a 3rd party such as Arcot or Worldline.
3DS flow

3DS Core Messages

Frictionless Flow

  • AReq (Authentication Request): Formed by the 3DS Server to initiate the 3DS flow. Contains card, transaction and device information
  • ARes (Authentication Response): The issuer’s ACS response to the AReq. Indicates if the transaction has been authenticated, or if further interaction is required from the cardholder to complete authentication (TransactionStatus: C == Challenge)

Challenge Flow

  • CReq (Challenge Request): Formed by the 3DS Client to initiate the cardholder’s interaction in a challenge flow and used to carry authentication data from the cardholder
  • CRes (Challenge Response): The issuer’s ACS response to the CReq. Includes the Authentication result to complete the cardholder challenge. (Two or more CReq messages may be used in an app-based flow, including data necessary to display the 3DS challenge UI)
  • RReq (Result Request): Received directly by the 3DS server. Contains the 3DS challenge status outcome along with the associated authentication values to be submitted to the issuer in an authorization request (TransactionStatus: Y == Authentication Successful)

Where 3DS fits in the payment flow

The 3DS flow (Authentication) is distinct from the transaction Authorization flow. The result of a successful 3DS flow will be an Authentication cryptogram which is submitted within the Authorization flow and used by the issuer to verify that the transaction has been authenticated.

Authorization flow

‍

3DS Versions

3DS 1.0 

Support for 3DS 1.0 was discontinued on October 15, 2022.

A very limited number of 3DS 1.0 transactions may still occur, particularly originating from specific markets including India and Bangladesh.

3DS 2.1

The 3DS 2.1 specification was introduced in 2016, this was designed to be compatible across all device options. Additional key enhancements include:

  • 10x more data points collected, leading to more precise decision outcomes
  • Support for biometric authentication, reducing checkout times
  • May not require redirections, reducing cart abandonment
  • More authentication flows supported (out-of-band), such as redirection to banking app
  • More flexible implementation options; allowing for the separation of authentication and authorization. ProcessOut’s Separated Authentication functionality enables merchants to consolidate their 3DS flows, removing the dependency on each PSP for authentication.

3DS 2.2

This is currently the most dominant specification of the 3DS protocol at time of writing (2024). From October 2022, the major schemes required issuers and acquirers to support this enhanced standard. ProcessOut observes that around 90% of banks within the EEA & UK support 3DS 2.2 as of 2022. Note that 3DS 2.2 is not mandated for 3DS Server operators (often the PSP), so it is important to confirm what version of 3DS your 3DS provider supports.

The 3DS 2.2 specifications include some key enhancements designed to further optimize the consumer experience:

  • Enhanced out-of-band (OOB) authentication
  • Delegated Authentication; 
  • 3RI (3DS Requestor Initiated)
  • Decoupled Authentication (a type of 3RI)
  • Support for extended merchant Exemptions

3DS 2.3 was released in September 2021, but has yet to gain broad adoption and so is not covered in detail here.

Enhanced out-of-band (OOB) authentication

OOB authentication describes a flow where a 3DS Challenge (customer input) takes place in another channel, commonly the issuers banking app. With 3DS 2.2, enhanced OOB authentication was introduced which allows the challenge to present a link for redirecting a customer to the banking app. Best practice guidelines recommend the use of an in-app push notification to prompt the redirection, delivering a more seemless customer experience.

Delegated authentication

Delegated authentication allows authentication to be delegated to the merchant (who are required to provide a FIDO attestation of authentication). This allows merchants to host an authentication process (i.e. biometric fingerprint scan) directly within their own customer journeys. This can be used to eliminate customer redirections away from merchant checkout pages, as well as supporting other use cases.

This flow requires collaboration between the issuer, merchant and the 3DS Server provider. It is yet to receive broader adoption. However, this has the potential to further reduce customer friction.

3DS Requestor Initiated (3RI)

This type of 3DS transaction, initiated by a merchant when the cardholder is not present, is mainly used to maintain (or refresh) authentication data in the absence of a cardholder, for transactions that have been previously authenticated. This allows merchants to manage some complex payment use cases such as delayed split shipping. 

Decoupled Authentication (a type of 3RI)

Decoupled Authentication occurs when the 3DS authentication (customer input) takes place in a different channel outside of the merchants check-out flow. The challenge can take place up to 7 days after the request. Once completed, the ACS sends the authentication result to the 3DS Server, skipping the Creq/Cres message. This flow may be used as a fallback if the normal challenge flow fails, allowing the customer to still place an order and provide authentication asynchronously before shipping.

‍

How to influence the 3DS flow

Merchants are able to influence how 3DS is requested between either a Challenge flow or a Frictionless flow. This is influenced through the use of a Challenge Indicator and/or Challenge Exemption. Note that merchants may only influence a desired flow, the final decision is always determined by the issuer. Many factors can contribute to the likelihood of the issuer respecting the merchants 3DS flow preference.

Implications of different 3DS flows

3DS2 supports both a Frictionless flow and a Challenge flow.

  • Frictionless Flow: Only the customer's device data (device fingerprint) is used to complete authentication. In this case, the 3DS flow is still initiated but a customer input is not required. This provides a more seamless experience.
  • Challenge Flow: Requires two out of three possible authentication methods, one of which will include a form of customer input authentication. The three possible authentication methods are often referred to as; something they know, something they have, something they are.

Challenge indicator and SCA challenge exemption

  • Challenge Indicator: These values are used to indicate a preference for a Challenge or Frictionless 3DS flow. See the below chart to understand the liability shift implication of different Challenge Indicators. 
  • SCA Exemption Reason: These values, submitted within the Authorization Request, are used to indicate a risk-based exemption from the EMVCo SCA flow. While this is compliant, it also implies that the merchant (acquirer) accepts liability in the event of a fraud-based chargeback. The benefit of this flow is that it implies no friction in submitting the transaction request. This flow attracts an additional fee from schemes. Issuers may also still soft decline the transactions and request Authentication if it is deemed too high risk.

This table on the ProcessOut documentation indicates when Liability Shift will be granted, based on the merchant submitting a Challenge Indicator and this being accepted by the issuer. The values indicated are those supported by ProcessOut’s API. Information is accurate as of March 2024.

Liability shift table

‍

The outcome obtained through the application of challenge indicators can vary based on multiple factors, including issuer preferences. ProcessOut can help merchants optimize between different values to maximize the probability of achieving the desired flows.

‍

When to request a Challenge flow

The Challenge Flow guarantees that the merchant will benefit from Liability Shift in the event of a fraud-based chargeback. This can be a strong benefit to merchants, particularly for those that do not perform their own customer risk analysis or that operate in higher-risk sectors.

  • To request this preference, ProcessOut recommends passing the Challenge Indicator challenge-requested

If the transaction is intended to be the first transaction in a chain of subsequent MIT transactions (such as a subscription) then it is mandatory under PSD2 that the CIT goes through a Challenge flow.

  • In this case, ProcessOut recommends passing the Challenge Indicator challenge-requested-mandate

How to request a Frictionless Flow

As a general rule, if the merchant wants to retain liability shift, it is likely that an issuer will require a Challenge flow, particularly for higher value transactions. However, challenge indicators do exist to signal a preference for no challenge, while still retaining liability shift. In practice, these often have low impact. The challenge indicator in this case would be no-challenge-requested.

For merchants that are happy to assume the liability risk of a transaction in exchange for reduced customer friction, while still retaining some of the security benefits from frictionless 3DS, it is possible to apply an exemption based Challenge Indicator such as no-challenge-requested-tra-performed.

Core indicator and exemption decision flows

An overview of the key considerations and possible exemption / indicators that can be applied in the 3DS flow are indicated below.

3DS flow and challenge indicators

 

 

‍

Recent articles

Arrow Left IconLeft iconRight icon buttonSwiper icon right