BNPL Payment MethodsRecurring PaymentsAccounting as a Service

Strong Customer Authentication (SCA)

Strong Customer Authentication (also known as SCA) fulfills a set of regulatory requirements, designed to reduce fraud, making online payments more secure while establishing trust with consumers. SCA adds an extra layer of security by using a third party like a bank to verify the end-customer prior or during an online payment. Riverty currently offers this functionality in Sweden, Norway, Denmark, Finland, and Netherlands.

Practical Use

SCA is used for risk handling (consumer ratings and fraud risk). For Norway and Sweden SCA is almost always mandatory as it is a key element of fraud prevention and it is a known process for online shoppers. In Sweden SCA is used by 98% of the population between 18-67 years of age.

Country Specifics

Country Sweden Norway Finland Denmark Netherlands DACH
Name of eID method BankID (SE) BankID (NO) FTN (Finnish Trust Network) MitID (replaces NemID) iDIN One Time Password (SMS/Email)
Required field(s) Identification number Identification number Identification number Identification number Date of birth, first name, last name Phone Number, Email Address
Supports headless ✓
Country specific restrictions Only for customers using the following banks: ABN AMRO, ASN Bank, Bunq, ING, Rabobank, RegioBank, SNS. More info: https://www.idin.nl/en/can-i-use-idin/
Country specific testcases The last name has to be Vries and date of birth has to be 1975-07-25

Redirect vs Headless Flow

SCA can be implemented in two different ways, redirect flow or headless flow (currently available only in Sweden).

Redirect flow requires the end-customer to be redirected to the secure login URL that was provided by Riverty API during the Authorize Payment or Verify request. The end-customer will be presented with a page with further instructions. After the verification process is completed the end-customer is redirected back to merchant’s web page.

Headless flow does not require the end-customer to input any additional information on a separate page. There are no redirects that the end-customer needs to follow – customer stays on the merchant page.

Automatically Opening BankID (SE) Mobile Application - Headless Flow

When using headless SCA the merchant can choose to open the BankID (SE) mobile application which would make the customer authentication process more seamless. Documentation about is can be found in BankID (SE) Launching

How And When To Start The SCA?

Starting the SCA process can be either decided based on the merchant configuration or the merchant.

SCA Initiated Based On The Merchant Configuration

When the SCA process is based on the merchant configuration, the Authorize payment request contains information about the customer and order.

Initiated By The Merchant

Merchant can decide when to initiate SCA for the end-customer. Customer verify request must be used when merchant wants to control when SCA is performed for the end-customer. Customer verify request does not have information about the order and is performed separately from the authorize payment request. This allows for custom decision making, e.g. perform SCA on every new device or perform SCA for new users, etc.

Redirect Flow Using Authorize Payment Request

For this solution, Riverty will decide for which orders and customers SCA will be triggered. This decision is based on a number of parameters, such as order amount, shipping address and other fraud and risk related variables.

SCA 1.png

  1. Customer selects Riverty in the Merchant checkout and clicks ‘Pay’ to finalize a purchase
  2. Merchant does a Authorize payment request to Riverty API with customer and order details
  3. Riverty API decides based on merchant configuration if SCA is required to finalize the purchase. If SCA needs to be performed Riverty API sends a response with “outcome” : “Pending” and risk check messages containing “message” : "Strong identification needed" with “code” : “200.910”.
  4. The authorize payment response contains a “secureLoginUrl” where the return URL needs to be specified in the URL parameters “?merchantUrl=<merchant-redirect-url>”. This specifies where the client would be redirected after the SCA process is completed or canceled.
  5. Merchant redirects customer to the secure login URL which contains the merchant redirect URL in the parameters.
  6. Customer uses the country specific eID method to verify their identity.
  7. After successful authentication Riverty redirects the customer to the merchant return URL (specified in step 4)
  8. Merchant has to make a GetOrder request to Riverty API to check what is the order status when customer arrives back on merchant’s page.
    • If the order status is accepted, order is finalized
    • If the order status is cancelled, expired or pending - order is not finalized. After 15 minutes the pending order times out, so a new try with a new order number is required.

Headless Flow Using Authorize Payment Request

SCA 2.png

  1. Customer selects Riverty in the Merchant checkout and clicks ‘Pay’ to finalize a purchase
  2. Merchant does a Authorize payment request to Riverty API with customer and order details
  3. Riverty API decides based on merchant configuration if SCA is required to finalize the purchase. If SCA needs to be performed Riverty API sends a response with “outcome” : “Pending” and risk check messages containing “message” : "Strong identification needed" with “code” : “200.910”. ⚠ Note – response does not contain a “secureLoginUrl” because no redirects are used in a headless flow.
  4. Merchant communicates the need of verification to the end-customer. During the verification merchant must poll Riverty API for the SCA status using GetOrder request (status Open indicates that the verification process is not completed). ⚠ Note- The first GetOrder request creates the SCA session for the end-customer
  5. Customer uses the country specific eID method to verify their identity.
  6. Merchant receives a response from GetOrder with status Pending, Success, Cancelled or Expired.
  7. Based on the GetOrder response merchant either proceeds with a purchase or tries to verify the customer again.

Redirect Flow Using Verify Customer Request

  1. Merchant decides to verify end-customers identity
  2. Merchant does a Verify customer request to Riverty API with customer details. ⚠ Note – No information about order is provided
  3. Riverty API responds with a “scaSessionId” and “secureLoginUrl” which is used to check the verification process status
  4. Merchant redirects the end-customer to secure login URL. ⚠ Note – Add merchant return URL to the URL parameters if you see “?merchantUrl=” at the end of the secure login URL.
  5. Customer uses the country specific eID method to verify their identity.
  6. After successful authentication Riverty redirects the customer to the merchant return URL which was specified during the Verify customer request or added to URL parameters (see step 4).
  7. Merchant does a GetScaStatus request when customer is redirected to merchant’s web page.
  8. Based on the GetScaStatus response merchant can see if the end-customers identity was verified. Status : Open, Success, Cancelled, Expired, Failure
    • AuthorizationType – Desktop, App, Mobile. When App or Mobile is used the eID application is opened automatically or the end-customer is presented with a button to open the appropriate application.
    • MerchantReturnUrl – URL where the end-customer will land after the verification is completed. Customer- Information about the customer (see the table above for required fields for different countries).

Request

{
  "authorizationType": "App",
  "countryCode": "SE",
  "merchantReturnUrl": "https://devportal.riverty.dev",
  "customer": {
    "customerCategory": "Person",
    "conversationLanguage": "EN",
    "identificationNumber": "194308236340"
  }
}

Response

{
  "outcome": "Pending",
  "secureLoginUrl": "https://secure-dev.riverty.dev/ssnauthentication/login/b959ee3c27bd4432b326837dcf3b04a0",
  "scaSessionId": "b959ee3c27bd4432b326837dcf3b04a0",
  "riskCheckMessages": [
    {
      "type": "BusinessError",
      "code": "200.910",
      "message": "Strong identification needed",
      "actionCode": "AskConsumerToIdentify",
      "fieldReference": "customer.identificationNumber"
    }
  ]
}

Get SCA Status For Verify Flow

When using the Verify Customer flow for the SCA you need to poll Riverty API for the SCA status update. To poll Riverty API for the SCA status use GET /api/v3/customer-identity/sca/{scaSessionId}/status endpoint where you include the specific SCA session ID.

{
  "scaSessionId": "a37aec25da4145d1a77b9356287f78d1",
  "status": "Open"
}