Testing with the Mock Service

Jumio provides a mock service you can use to generate specific transaction outcomes. This is useful for testing any decision logic you have developed to respond to specific decisions returned by Jumio. Consistently producing the full range of decision values your integration may encounter is often difficult or impossible using actual transactions. By using the mock service you can develop robust sets of tests that use synthetic transactions to produce specific outcomes.

The mock service requires a dedicated tenantClosed A secure, isolated KYX environment for a customer. Each tenant includes its own configuration, users, and transactions. A tenant belongs to a customer. A customer can have multiple tenants. that is configured to support it. Contact Jumio Support or your account manager to create and configure the tenant if you want to use the mock service. All transactions that are initiated in a tenant that is configured to use the mock service will use the service.

You initiate a synthetic transaction as you would any other transaction, with these differences:

  • Use OAuth2 credentials from a tenant configured to support the mock service to obtain the bearer token for authorizing the account request.

  • Specify the desired state of the decision in a JSON string passed as the value of the "customerInternalReference" key in the body of the account request.

Example: Synthetic Transaction

The following example shows how to initiate a synthetic IDV transaction for workflow 10011. The account request body is the same as for a regular transaction, except that the "customerInternalReference" value is a string representation of a JSON object that specifies the desired decision state.

Account Request Body

{
	"customerInternalReference": "{\"customerInternalReference\":\"mockuser\", \"decisionLabel\":\"NFC_CERTIFICATE\", \"credentialWithDecision\":\"ID\", \"extractionOverrides\":{\"firstName\":\"JOHN\", \"idType\":\"PASSPORT\", \"issuingCountry\":\"USA\", \"lastName\":\"DOE\"}}",
	"userReference":"Jumio Documentation",
	"workflowDefinition":{
		"key": 10011
	},
	"userConsent": {
		"userIp": "226.80.211.232",
		"userLocation": {
			"country": "USA",
			"state": "IL"
		},
		"consent": {
			"obtained": "yes",
			"obtainedAt": "2022-07-20T17:20:35.000Z"
		}
	}
}
The customerInternalReference value is a string. Therefore quotation marks inside the JSON object must be escaped using a \ character.

Decision

The transaction details for a mock transaction are available from the retrieval API or in the Portal. For the account request above, the transaction decision would look like this:

	"decision": {
		"type": "REJECTED",
		"details": {
			"label": "MISMATCHING_DATAPOINTS"
		},
		"risk": {
			"score": 99.0
		}
	},

In the "capabilities" block the "dataChecks" JSON would look like this:

		"dataChecks": [
			{
				"id": "5960c353-614c-445c-9506-219e1a1dbd38",
				"credentials": [
					{
						"id": "df82c2ed-76e8-4ff9-aa53-270b5a9e3d54",
						"category": "ID"
					}
				],
				"decision": {
					"type": "REJECTED",
					"details": {
						"label": "MISMATCHING_DATAPOINTS"
					}
				}
			}
		],

In this case the "MISMATCHING_DATAPOINTS" label specified in the account request is only returned by the Data Checks capability. The other workflow capabilities have a decision.type value of "PASSED" and a decision.details.label value of "OK".

If a workflow capability has a dependency on a capability that is given a decision.type of "REJECTED", the dependent capability will have a decision.type value of "NOT_EXECUTED" and a decision.details.label value of "PRECONDITION_NOT_FULFILLED".

Specifying the Decision State

The value of the "customerInternalReference" field in the account request body is a string representation of a JSON object. The fields in the JSON object determine the decision values that will be returned for the mock transaction:

  • A fitting decision for the given "decisionLabel" value will be applied to any fitting capability in any fitting credential.

  • If there are mutliple credentials, the credential can be selected by the "credentialWithDecision" value.

  • Specific values to be returned in the capabilities.extraction.data object can be set in "extractionOverrides" value. The value is a nested JSON string.

By default, all decisions for capabilities that do not return the specified "decisionLabel" will have a "type" value of "PASSED" and a "label" value of "OK".

Any capabilities that have a dependency on a capability with a mocked "REJECTED" decision.type will be set to "NOT_EXECUTED".

Field Description
customerInternalReference Provides a way to set the value as you would for a regular transaction.
decisionLabel Specifies the decision label you want to appear in the decision. This value will be used to determine the decision for any capability that returns the label, as well as for the overall transaction decision.
credentialWithDecision Allows you to specify which credential will trigger the decision. For example, if the workflow processes both an ID and a Selfie and both are evaluated by the Usability capability, you can control which Usability instance gets the decision.
extractionOverrides A nested JSON sting that allows you to override the default Extraction data values.