Merchant Backend Sample 6.4

Overview

The sample merchant backend app demonstrates the recommended way of integrating the mobile and browser uSDKs with the 3DS Server. It is a server application written in Java programming language leveraging SpringBoot framework.

The sample application code

Download link

3ds-samples-merchant-backend-6.4.77-rel.5.zip

Version

6.4.77-rel.5

Last updated at

Dec 17, 2020

Scope

The Merchant Backend Sample application supports all 3DS v2 flows - mobile authentication, browser 3DS method, browser authentication, and the challenge flows.

Prerequisites

Java programming language and SpringBoot concepts

It is required to understand the Java programming language as well as to have certain experience developing web applications and backends. It assumes that concepts like JSON, HTTP Headers, POST requests, and others are well understood.

A connection to a 3DS Sever

In order to be able to perform 3DS transactions, the merchant backend needs to talk to a 3DS server.

Getting the application configured

Download and open the project

Download the project from the top of this page. Extract into a local folder. Then open the folder as a project in a Java IDE. IntelliJ Idea is recommended. Upon opening, all gradle dependencies will be downloaded automatically by the IDE.

Starting 6.4, the sample backend features the uMPI 3.0 plugin, so it has to be manually downloaded from uMPI 3.0 page and placed in libs folder of the project. See uMPI 3.0 documentation page for more details on what dependencies it requires.

Configuring the app

By default, the application is configured to contact the Customer Testing platform.

Merchant Identifier

The Customer Testing platform requires the customer to include an identifier in AReq.threeDSRequestorID field. This identifier can be requested from mSIGNIA administration.

To set the identifier, open src/main/resources/application.yml file and set the value for three-ds-requestor-id property. The example identifier is shown below:

app: ... three-ds-requestor-id: 5b638dca-b0d8-410a9babcae8

Running the application

Navigate to com.msignia.samples.threeds.backend.BackendApplication class and run its main method. The application launches a web server listening on port 8080 by default.

Seeing log entries like the following would confirm the app is up and running:

2020-04-24 14:07:14.272 INFO: Tomcat started on port(s): 8080 (http) with context path '' 2020-04-24 14:07:14.278 INFO: Started BackendApplication in 3.071 seconds (JVM running for 3.667) 2020-04-24 14:07:25.380 INFO: Initializing Spring DispatcherServlet 'dispatcherServlet' 2020-04-24 14:07:25.380 INFO: Initializing Servlet 'dispatcherServlet' 2020-04-24 14:07:25.389 INFO: Completed initialization in 9 ms

Under the hood

The sample application demonstrates how to integrate the uSDKs for both mobile and web, as well as completing the flow with a 3DS Server via the mSIGNIA uMPI plug-in. Details are outlined below:

Browser Authentication

The app shows how to perform 3DS v2 authentication for a web app that utilizes the browser uSDK. You should use the Browser Sample Application as it handles the client functionality.

Using the Browser Sample App, let it initialize the uSDK and click the button on the web page to kick off a transaction. At that point, the Browser Sample App will send a request to SupportedVersionsController#/api/v2/supported-versions endpoint and then to AuthenticationController#/api/v2/auth so it is advisable to put a breakpoint in the methods and step through to see what the merchant backend typically does for a browser authentication case.

Please note that browser auth flow consists of several steps, and you should familiarize yourself with the Browser Sample Application as it performs the routines in the correct order.

Mobile Authentication

The mobile authentication is a much simpler flow. To see it in action it is recommended to leverage either the Android Sample App or iOS Sample App. Both apps initiate a 3DS auth flow and provide backend code that can be reviewed.

Behind the scenes, the mobile uSDKs perform exactly the same routine as the browser one does - calling SupportedVersionsController#/api/v2/supported-versions and then AuthenticationController#/api/v2/auth. These are also good places to set a breakpoint and review the flows.

Changelog

[6.4.77-rel.5] - 12/18/2020

  • Updates to support uSDK 6.4.77