SCA Partner Guide

Overview

This guide is for partners who are, or are intending to build out their own SCA journeys, known as Partner Owned Authentication (POA). This guide outlines the core SCA journeys, the key Solaris API integration points as well as perquisites and requirements for partners. There are three primary workflows that need to be handled for implementing POA:

  • Authenticating user login using 2FA.
  • Authenticating e-commerce transactions using 3-D secure (3DS).
  • Authenticating all other in-scope SCA events: payments, management of beneficiaries etc., using 2FA.

If you have not already, please ensure you have familiarized yourself with the SCA overview guide before proceeding with this guide.

Authenticating user login

As with all SCA events the user login journey needs to be authenticated using 2FA. Please note:

  • The login journey and all paths within it are managed entirely by you - there is no interaction required with the Solaris API.
  • Although exemptions are available for the user login event, it is strongly recommended to perform SCA for all login journeys to provide a consistent and more secure journey for the user.

Example mobile application login

Outlined below is an example login journey flow for a mobile application, using the following authentication factors:

  • Trusted device binding (possession).
  • Biometrics (inherence).

Example web application login

Outlined below is an example login journey flow for a web/desktop application, using the following authentication factors:

  • Password (knowledge)
  • 6 digit OTP (possession). A Third party authenticator could also been used, for example, for this factor.

Authentication flow for 3-D secure e-commerce transactions

3ds Challenge

The 3-D Secure (3DS) flow will only be invoked for transaction that are deemed to require user authentication.

Certain e-commerce transactions require authentication from the user to prove it is them making the transaction. This is known as step up authentication/3DS challenge. In such situations, the 3DS flow is used to allow the user to authenticate themselves and approve the transaction, as outlined below:

Journey initiation

  1. An e-commerce transaction is initiated online by the user:
    • If the transaction does not require authentication from the user (no challenge required) the transaction authorization stage commences.
    • Otherwise, the 3DS challenge stage is initiated, to require the user authenticate and approve transaction.

3DS challenge stage

  1. The transaction information is received by Solaris. Solaris sends a 3DS SCA notification to your system, containing details of the transaction including the merchant name, transaction amount etc. as well as a TransactionID parameter.
  2. The pertinent transaction information is presented to the user in your application, who is then prompted to approve or decline the transaction using a compliant 2FA flow.
  3. A call is then made to the security/Authorize method to commence Solaris' authorization of the transaction. This call must include:
    • The SCAReferenceNumber - this is the TransactionID included in the previously received 3DS SCA notification.
    • The FirstFactorSCAOptionType - the first factor used in the authentication (this factor may be carried from the user login event).
    • The SecondFactorSCAOptionType - the second factor used in the authentication. This must differ from the factor provided in FirstFactorSCAOptionType .
    • Cancelling the transaction . The transaction can/will be cancelled by either of the following:
      • If the CancelRequest parameter is included and set to true .
      • If the authorization request is not received within the required time (by default within 10 minutes of the 3DS SCA notification being sent).

Transaction authorization stage

  1. If all prerequisites and conditions are met (e.g. sufficient funds available) the transaction is approved by Solaris.
  2. Solaris will send respective notifications to your system for informational purposes:

Notes on the 3DS flow

  • Users who have been/are currently logged out, will need to log back into your app via your user login flow in order to approve the transaction.
  • Details of the online transaction - including the merchant name and transaction amount must be displayed in your app for the user for their approval.
  • By default a transaction must be authorized within 10 minutes of the respective 3DS SCA notification being sent. This time window can be shortened if required.
  • When authenticating a 3DS transaction:
    • If using OTPs as a possession factor, the OTP sent to the user must relate specifically to the transaction requiring authentication, by referencing both the transaction amount and merchant name. A generic OTP message would not constitute a compliant factor.
    • Please note it is not possible to use third-party authenticators as a possession factor as these do not provide a means of linking the authentication to a specific transaction.

Authentication flow for other SCA events (excluding e-commerce)

Certain requests made to the API will constitute an SCA event. These require the user to authenticate themselves before the request can be actioned by Solaris. The flow for authorizing these events is outlined below.

SCA APPLICABILITY

Solaris retains responsibility as to when SCA must apply, in part informed by a number of regulatory exemptions, which determines when you will receive an SCA Event response from the API.

  1. The user attempts to undertake a given action in your app, for example initiating a payment.
  2. The relevant request is made to the Solaris API to action this.
  3. If Solaris determines the request constitutes an SCA event, the request is held in a pending state and the API responds with an SCA Event response containing a SCAReferenceNumber .
  4. The user is prompted to perform authentication of the event in your app. This authentication constitutes the second factor (the first factor will have been carried over from the user's login).
  5. A call is made to the security/Authorize method to authorize the SCA event. This call must be made within 5 minutes of the API response and must include:
    • The SCAReferenceNumber received in the SCA Event API Response.
    • The FirstFactorSCAOptionType specifying the first factor used in the authentication (this factor may be carried from the user login event).
    • The SecondFactorSCAOptionType specifying the second factor used in the authentication. This must differ from the factor provided in FirstFactorSCAOptionType .
  6. Once authorized, the pending request is actioned.
UserPartner systemSolaris APISCA event raised.Request held in pending.User Performs Compliant2FA in app.Request ActionedInitiates payment(or other SCA event)Request to Solaris APISCA Event Response sentUser prompted to perform 2FA5 attempts max2FA PerformedRequest to Security/AuthorizeResponseUserPartner systemSolaris API

SCA Event Response

API requests that constitute an SCA event will return an SCA event response. The example below details a payment request requiring SCA:

Copy
Copied
{
    "BankTransferReferenceID": 0,
    "SCARes": {
        "SCAReferenceNumber": "514c0a64-390d-4f21-b713-5e932e26365c",
        "SCAType": 0,
        "AuthorizeOn": "",
        "AdditionalData": "",
        "ExpiryDateTime": "2023-11-02T09:36:01.583",
        "RemainingResendCount": 0,
        "RemainingFailAttempt": 0,
        "SCAIdentification": "",
        "StartDateTime": "2023-11-02T09:31:01.583",
        "Title": "Payment"
      },
    "Description": "SCA needs to be performed.",
    "ResponseCode": "900",
    "ResponseDateTime": "2023-11-02T09:31:01.657",
    "ClientRequestReference": "56c0aca6-3778-49b5-9bf3-9d58fb138c32",
    "RequestID": 538348141618587881
}

For such requests, the response will:

  • Have a HTTP response of 200 OK .
  • Include a Description field reading "SCA needs to be performed".
  • Include a ResponseCode field containing a code of "900".

The response will include an SCARes object specific to the given SCA event. Parameters pertinent to the POA workflow are outlined below:

  • SCAReferenceNumber - provides a unique ID for the given event, used when authorizing the SCA event.
  • SCAType - Value of 0 denotes Partner Owned Authentication.
  • Title field denoting the SCA event which requires 2FA.
  • ExpiryDateTime provides the time by which the given event must be authorized.

Notes and prerequisites for partners

  • Solaris is the regulated e-money account provider and therefore is accountable for all SCA-related activities and is required by regulations to dynamically link payments.
  • Solaris will need to review, validate and sign off your SCA flows before you can access the production environment. It is recommended you provide Solaris with your proposed flows, including unhappy paths, before commencing your build and integration phase.
  • After any period of inactivity in your app exceeding 5 minutes, the user must undertake the login journey again.
  • All SCA events in scope for your integration need to be authenticated via 2FA using a combination of factors. Points to consider when deciding which factors to use include:
    • The availability and applicability of factors on each range of devices you intend to target. For example, biometric factors (inherence) including facial and fingerprint recognition are typically only available on mobile devices.
    • You may need to support a number of factor combinations if targeting a range of device types.
    • The impact on user journeys the factors chosen will have.
Solaris is the brand name for the regulated entities Contis Financial Services Ltd and UAB „Finansinės paslaugos „Contis“, which are part of the Solaris Group.