v3 - Web flow / Selfie / Liveness

ID document checking and general document scanning are historically the most common means of identifying new customers and is still considered an option to national electronic identification methods. We offer automatic detection and analysis of identity cards, passports and driving licenses.

The service Forgery Detection can be used as a measure to increase the confidence level and safeguard against deliberate tampering. Forgery Detection – ZignSec Docs

A scanning session is the overarching unit of work. It contains a collection of documents to be analysed. A scanning session can contain several analyses. An analysis is started by supplying the scanning session with an analysis configuration object.

Scanning flow can be configured using merchant settings, please contact Zignsec Support for assistance.

Step 1: Initialize scanning session

NOTE: all parameters are optional, document to be done by default. Pass empty object to use defaults.

Step 1.1: Example of initializing scanning session

POST https://test.zignsec.com/v3/scanning HTTP/1.1
Authorization: YOUR-KEY....

{
  "relay_state": "client_state",
  "analysis_types": [
    "document",
    "selfie"
  ],
  "target": "https://landing.mysite.com",
  "target_error": "https://landing.mysite.com/problem",
  "webhook": "https://webhook.site/"
}

Step 1.2: Description of request model

`locale`	Preferred Language to use, we support multiple languages like : en , se ,de , fr, gr, it ,ru ,es , cz, tr. We can add more languages as per your business requirements
`relay_state`	This semi-optional parameter will be returned to you at the redirect back to your server. Use it to link an unique ID of your choice that you can parse. If not relaystate is specified, ZignSec will automatically set the ZignSec’s unique session identifier, the RequestID token here. Example: `"relay_state":"client_state"`
`analysis_types`	Parameter to set up types of analysis that will apply for current session. Types of analysis: document selfie liveness
`target`	If this parameter is supplied the browser session will finally be redirected to this URL-value. Example : `"target": "https://landing.mysite.com"`
`target_error`	`target_error` works as `target` except it is navigated on user cancel or error situations.
`webhook`	A URL where success/error results will automatically be POST:ed. During test you try https://webhook.site/ for free web hook URLs.

Step 1.3: Example of response for initializing scanning session

{
    "id": "231a7aa4-f6d3-468b-9aab-7ec4c6ee3a8c",
    "errors": [],
    "redirect_url": "https://test.zignsec.com/v3/eid/scanningsessions/scan/231a7aa4-f6d3-468b-9aab-7ec4c6ee3a8c"
}

Step 1.4: Description of response model

`id`	The session identifier, a GUID (globally unique identifier) unique for the started workflow, used both in the `redirect_url` and the get analysis results.
`errors`	A JSON object that contains information on error conditions that might have resulted from the request, in an array of property-value pairs. If multiple errors occur, a pair of parameters is returned for each error. `code` Code for the error. List of codes is in table below. `description` A string that describes the type of error that occurred. If no errors occur, then this object is empty. `errors : []`
`redirect_url`	The URL that the user need to be redirected to complete the data via the web interface. It is possible to load the URL in an iframe.

Step 2: Browser steps

There are two approaches to complete files upload to scanning:

- Browser flow – where you complete the flow on the same device as you triggered the URL
- Mobile flow – where you complete the flow on a mobile by either scanning the QR code or sending an SMS both methods will give you a URL-link to trigger