Protect Plus for JavaScript Library

Protect Plus is a sophisticated counter-fraud service that provides your site with an extra layer of security against fraudulent transactions. It makes use of the industry’s largest negative database to perform a comprehensive suite of fraud assessments, including identity checks against the UK electoral roll and BT databases.

Sign up for Protect Plus

Before you can get started, you will need to contact our Sales Team and enable Protect Plus on your account.

What checks are performed?

We analyse the customer’s billing, delivery and payment details using a rule-based system to detect suspicious patterns in user activity. Our system will assist you in deciding on whether to process a customer’s transaction based on the perceived level of risk. Checks performed include:

The industry’s largest negative database.
Neural-based fraud assessments.
Tumbling or Swapping, where there is an unusual usage pattern in the card number, expiration date or customer details associated with a transaction.

Protect Plus does not guarantee against fraud

You should consider all data regarding a transaction before accepting the payment.

What happens after the checks are performed?

The Protect Plus system will analyse transaction details and issue one of the following fraudcontrolshieldstatuscode values:

“ACCEPT”	The details are not deemed suspicious.
“CHALLENGE”	Further investigation is recommended.
“DENY”	The details are suspicious and a transaction should not be performed.
“NOSCORE”	Transaction was declined by the acquirer before checks were performed.

Order of requests

Protect Plus checks are performed when a RISKDEC request is submitted to our system. There are two methods in which you can configure your system to process RISKDEC requests using our JavaScript Library:

RISKDEC then AUTH – Perform the checks first, then seek authorisation for the payment. By default, we suspend suspicious payments, allowing you to investigate them before proceeding.
AUTH then RISKDEC – Seek authorisation for the payment first, then perform the checks. Checks performed are more accurate because they take the results of AVS, Security Code Checks and 3-D Secure into account.

Configuration of request

RISKDEC then AUTH request

Process overview

When the customer clicks “Pay” on your checkout, the JavaScript library submits a request to Trust Payments.
Trust Payments checks the payment details and generates a shield status code.
The customer is authenticated with 3-D Secure.
Trust Payments contacts the acquiring bank to process the payment.
Trust Payments returns the response JWT to your system. You will need to interpret the response.

By default, when you opt to perform the RISKDEC before the AUTH, we automatically suspend authorised transactions when the fraudcontrolshieldstatuscode is “CHALLENGE” or “DENY”. This will allow you to investigate further and make a more informed choice on whether or not to authorise a suspicious transaction. This behaviour can be changed. Please contact the Support Team for further information.

Update the JWT payload

You will need to update the JWT payload to instruct our JavaScript Library to process a RISKDEC prior to performing a standard transaction. This is done by submitting requesttypedescriptions following the specification outlined below:

Field specification

	Field	Format	Description
	requesttypedescriptions	List	This must be set to [“RISKDEC”,”THREEDQUERY”,”AUTH”].

Payload example

{
  "payload":{
    "accounttypedescription":"ECOM",
    "baseamount":"1050",
    "currencyiso3a":"GBP",
    "sitereference":"test_site12345",
    "requesttypedescriptions":["RISKDEC","THREEDQUERY","AUTH"]
  },
  "iat":1559033849,
  "iss":"jwt.user"
}

Handling the response

The contents of the response is dependent on whether the customer was subject to more stringent authentication (referred to as step up authentication).

If the transaction is subject to step up authentication

After the customer has completed the payment session, you will receive a single response JWT that contains the response to the AUTH request, the process in which the transaction is authorised by the issuing bank. Your system will need to ensure that the errorcode value returned for the AUTH is “0”, indicating success. If the AUTH has failed, the payment will be unsuccessful. As well as checking the errorcode, your system should perform these additional recommended checks.

If the transaction is subject to frictionless authentication

After the customer has completed the payment session, you will receive a single response JWT consisting of the RISKDEC, THREEDQUERY and AUTH responses. The most important response to check is that of the AUTH, the process in which the transaction is authorised by the issuing bank. Your system will need to ensure that the errorcode value returned for the AUTH is “0”, indicating success. If the AUTH has failed, the payment will be unsuccessful. As well as checking the errorcode, your system should perform these additional recommended checks.

The following fields are returned in the RISKDEC response:

Field	Format	Description
fraudcontrolreference	Alphanumeric (255)	Unique reference to identify the Risk Decision check performed.
fraudcontrolresponsecode	Numeric (4)	A numeric code that is mapped to further information on the results of the Risk Decision checks performed.
fraudcontrolshieldstatuscode	Alpha (10)	One of the following values: “ACCEPT” – The details are not deemed suspicious. “CHALLENGE” – Further investigation is recommended. “DENY” – The details are suspicious and a transaction should not be performed.
rulecategoryflag	Alphanumeric (255)	Reference used to identify a condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode. Only returned if checks are performed successfully.
rulecategorymessage	Not defined	Condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode. Only returned if checks are performed successfully.

AUTH then RISKDEC request

Process overview

When the customer clicks “Pay” on your checkout, the JavaScript library submits a request to Trust Payments.
The customer is authenticated with 3-D Secure.
Trust Payments contacts the acquiring bank to process the payment.
Trust Payments checks the payment details and generates a shield status code.
Trust Payments returns the response JWT to your system. You will need to interpret the response.

If the shield status code is “CHALLENGE” or “DENY”, Trust Payments recommends that you update the AUTH to a suspended state (settle status “2”). This allows you to review the transaction and either opt to proceed by updating the settle status of the AUTH to “1” or to cancel by updating the settle status to “3”.

Update the JWT payload

You will need to update the JWT payload to instruct our JavaScript Library to process a RISKDEC following a standard transaction. This is done by submitting requesttypedescriptions following the specification outlined below:

Field specification

	Field	Format	Description
	requesttypedescriptions	List	This must be set to [“THREEDQUERY”,”AUTH”,”RISKDEC”]

Payload example

{
  "payload":{
    "accounttypedescription":"ECOM",
    "baseamount":"1050",
    "currencyiso3a":"GBP",
    "sitereference":"test_site12345",
    "requesttypedescriptions":["THREEDQUERY","AUTH","RISKDEC"]
  },
  "iat":1559033849,
  "iss":"jwt.user"
}

Handling the response

The contents of the response is dependent on whether the customer was subject to more stringent authentication (referred to as step up authentication):

For step up authentication: After the customer has completed the payment session, you will receive a single response JWT, consisting of the responses to the AUTH and RISKDEC requests.
For frictionless authentication: After the customer has completed the payment session, you will receive a single response JWT consisting of the THREEDQUERY, AUTH and RISKDEC responses.

When checking the THREEDQUERY and AUTH responses:
- We recommend following the checks outlined on this page.
When checking the RISKDEC response:
- It is important that this request is successful (check the errorcode is “0”).
- Check the fraudcontrolshieldstatuscode – We recommend investigating instances where “CHALLENGE” and “DENY” are returned.
- There are additional fields specific to Protect Plus that your system will need to check. These are described in the table below.

Field	Format	Description
fraudcontrolreference	Alphanumeric (255)	Unique reference to identify the Risk Decision check performed.
fraudcontrolresponsecode	Numeric (4)	A numeric code that is mapped to further information on the results of the Risk Decision checks performed.
fraudcontrolshieldstatuscode	Alpha (10)	One of the following values: “ACCEPT” – The details are not deemed suspicious. “CHALLENGE” – Further investigation is recommended. “DENY” – The details are suspicious and a transaction should not be performed. “NOSCORE” – Returned when a parent AUTH Request has been declined.
rulecategoryflag	Alphanumeric (255)	Reference used to identify a condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode. Only returned if checks are performed successfully.
rulecategorymessage	Not defined	Condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode. Only returned if checks are performed successfully.

Testing

We recommend that you thoroughly test your solution before enabling on your live Site Reference.
Click here for details that you can submit to simulate different RISKDEC responses on our test system.

Further reading on this topic