Contents

Protect Plus (API)

 

Warning
The following content assumes you have obtained the necessary PCI certification to process and submit sensitive cardholder data in the request to our Webservices API.

If you are unsure, please contact our Support Team for assistance.

Info
If you are already processing e-commerce payments using our JavaScript Library, your existing solution can be updated to also submit Protect Plus requests with minimal changes to the mark-up. Click here to learn more.

 

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.

 

Process overview

Status good
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 or not to process a customer’s transaction based on the perceived level of risk. Checks performed include:

 

 

Warning
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 Webservices API:

 

RISKDEC then AUTH request

Process overview

  1. When the customer clicks “Pay” on your checkout, your system submits a RISKDEC request to Trust Payments using the Webservices API (we provide an example of how to structure this request below).
  2. Trust Payments checks the payment details, generates a fraudcontrolshieldstatuscode and returns this information to your system in a RISKDEC response.
  3. Your system will need to check the shield status code and determine whether or not to proceed with the payment.
  4. If you opt to process the payment, you can process a payment using our JavaScript as described herewith one important difference.
    The JWT in the payload must be updated to include field parenttransactionreference, including the unique transactionreference returned in the RISKDEC response.
    This is used to inherit data from the initial request.
  5. Trust Payments contacts the acquiring bank to process the payment.
  6. Trust Payments returns the response JWT to your system. You will need to interpret the response.

 

Info
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.

 

RISKDEC request example

Here is an example of a RISKDEC request, the details of which can be inherited in future payments processed using our JavaScript Library:


#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

riskdec= {
    "sitereference": "test_site12345",
    "requesttypedescriptions": ["RISKDEC"],
    "accounttypedescription": "ECOM",
    "currencyiso3a": "GBP",
    "baseamount": "1011",
    "orderreference": "My_Order_123",
    "pan": "4111111111111111",
    "expirydate": "12/2020",
    "securitycode": "123"
}

strequest = securetrading.Request()
strequest.update(riskdec)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php

if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
  throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);

$configData = array(
'username' => '[email protected]',
'password' => 'Password1^',
);

$requestData = array(
  'sitereference' => 'test_site12345',
  'requesttypedescriptions' => array('RISKDEC'),
  'accounttypedescription' => 'FRAUDCONTROL',
  'currencyiso3a' => 'GBP',
  'baseamount' => '1011',
  'orderreference' => 'My_Order_123',
  'pan' => '4111111111111111',
  'expirydate' => '12/2020',
  'securitycode' => '123'
);

$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());

?>
curl --user [email protected]:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias": "[email protected]",
"version": "1.00",
"request": [{
  "currencyiso3a": "GBP",
  "requesttypedescriptions": ["RISKDEC"],
  "sitereference": "test_site12345",
  "baseamount": "1011",
  "orderreference": "My_Order_123",
  "accounttypedescription": "FRAUDCONTROL",
  "pan": "4111111111111111",
  "expirydate": "12/2020",
  "securitycode": "123"
}]}'
{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"GBP","requesttypedescriptions":["RISKDEC"],"sitereference":"test_site12345","baseamount":"1011","orderreference":"My_Order_123","accounttypedescription":"FRAUDCONTROL","pan":"4111111111111111","expirydate":"12\/2020"}]}
<?xml version="1.0" encoding="utf-8"?>
<requestblock version="3.67">
  <alias>[email protected]</alias>
  <request type="RISKDEC">
    <merchant>
      <orderreference>My_Order_123</orderreference>
    </merchant>
    <billing>
      <amount currencycode="GBP">1011</amount>       
      <payment>
        <expirydate>12/2020</expirydate>
        <pan>4111111111111111</pan>
      </payment>
    </billing>
    <operation>
      <accounttypedescription>FRAUDCONTROL</accounttypedescription>
      <sitereference>test_site12345</sitereference>
    </operation>
  </request>
</requestblock>

Replace <DOMAIN> with a supported domain. Click here for a full list.

 

RISKDEC response example

Here is an example of the associated RISKDEC response:

For the RISKDEC response field specification, scroll down to the “Interpreting the response” section.


{
  u 'requestreference': u 'A0dcb11e6',
    u 'version': u '1.00',
    u 'response': [{
      u 'acquirerrecommendedaction': u 'C',
        u 'fraudcontrolresponsecode': u '0100',
        u 'paymenttypedescription': u 'VISA',
        u 'orderreference': u 'My_Order_123',
        u 'transactionstartedtimestamp': u '2016-12-07 16:19:28',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'fraudcontrolreference': u 'TEST',
        u 'accounttypedescription': u 'FRAUDCONTROL',
        u 'errorcode': u '0',
        u 'transactionreference': u '1-2-345678',
        u 'maskedpan': u '411111######1111',
        u 'requesttypedescription': u 'RISKDEC',
        u 'fraudcontrolshieldstatuscode': u 'ACCEPT',
        u 'livestatus': u '0'
    }]
}
array(3) {
  ["requestreference"] => string(9) "A58cdfkpy"
  ["version"] => string(4) "1.00"
  ["response"] => array(1) {
    [0] => array(15) {
        ["errorcode"] => string(1) "0"
        ["orderreference"] => string(12) "My_Order_123"
        ["fraudcontrolresponsecode"] => string(4) "0100"
        ["paymenttypedescription"] => string(4) "VISA"
        ["maskedpan"] => string(16) "411111######1111"
        ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:12:39"
        ["errormessage"] => string(2) "Ok"
        ["operatorname"] => string(23) "[email protected]"
        ["accounttypedescription"] => string(12) "FRAUDCONTROL"
        ["acquirerrecommendedaction"] => string(1) "C"
        ["transactionreference"] => string(9) "1-2-345678"
        ["requesttypedescription"] => string(7) "RISKDEC"
        ["fraudcontrolreference"] => string(4) "TEST"
        ["fraudcontrolshieldstatuscode"] => string(6) "ACCEPT"
        ["livestatus"] => string(1) "0"
      }
  }
}
{"requestreference":"W23-wt77f0n8","version":"1.00","response":[{"errorcode":"0","fraudcontrolresponsecode":"0100","paymenttypedescription":"VISA","orderreference":"My_Order_123","transactionstartedtimestamp":"2016-12-07 16:23:03","errormessage":"Ok","operatorname":"[email protected]","accounttypedescription":"FRAUDCONTROL","acquirerrecommendedaction":"C","transactionreference":"1-2-345678","requesttypedescription":"RISKDEC","maskedpan":"411111######1111","fraudcontrolreference":"TEST","fraudcontrolshieldstatuscode":"ACCEPT","livestatus":"0"}],"secrand":"E0ksvyuH5VKg"}
<?xml version="1.0" encoding="utf-8"?>
<responseblock version="3.67">
  <requestreference>X336659733</requestreference>
  <response type="RISKDEC">
    <merchant>
      <orderreference>My_Order_123</orderreference>
      <operatorname>[email protected]</operatorname>
    </merchant>
    <transactionreference>1-2-345678</transactionreference>
    <billing>
      <payment type="VISA">
        <pan>411111######1111</pan>
      </payment>
    </billing>
    <timestamp>2012-06-21 13:32:43</timestamp>
    <fraudcontrol>
      <shieldstatuscode>ACCEPT</shieldstatuscode>
      <reference>TEST</reference>
      <recommendedaction>C</recommendedaction>
      <responsecode>0100</responsecode>
    </fraudcontrol>
    <live>0</live>
    <error>
      <message>Ok</message>
      <code>0</code>
    </error>
    <operation>
      <accounttypedescription>FRAUDCONTROL</accounttypedescription>
    </operation>
  </response>
  <secrand>2ngbLQ3DO</secrand>
</responseblock>

 

AUTH then RISKDEC request

Process overview

  1. When the customer clicks “Pay” on your checkout, the JavaScript library submits a request to Trust Payments.
  2. Trust Payments contacts the acquiring bank to process the payment.
  3. Trust Payments returns the response JWT to your system. You will need to interpret the response.
  4. Following this, your system submits a RISKDEC request to Trust Payments using the Webservices API, including the field parenttransactionreference, which is the unique transactionreference value returned in the response JWT (we provide an example of how to structure this request below).
  5. Trust Payments checks the payment details, generates a fraudcontrolshieldstatuscode and returns this information to your system in a RISKDEC response.
  6. Your system will need to check the shield status code and determine whether or not to proceed with the payment.
  7. If you want to suspend or cancel a payment, you will need to process a transaction update request using the Webservices API.

 

Request example

Here is an example of a RISKDEC request to be submitted using our Webservices API, following a payment processed using our JavaScript Library.


#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

riskdec= {
    "sitereference": "test_site12345",
    "requesttypedescriptions": ["RISKDEC"],
    "accounttypedescription": "FRAUDCONTROL",
    "currencyiso3a": "GBP",
    "baseamount": "1011",
    "orderreference": "My_Order_123",
    "parenttransactionreference": "1-2-3"
}

strequest = securetrading.Request()
strequest.update(riskdec)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php

if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
  throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);

$configData = array(
'username' => '[email protected]',
'password' => 'Password1^',
);

$requestData = array(
  'sitereference' => 'test_site12345',
  'requesttypedescriptions' => array('RISKDEC'),
  'accounttypedescription' => 'FRAUDCONTROL',
  'currencyiso3a' => 'GBP',
  'baseamount' => '1011',
  'orderreference' => 'My_Order_123',
  'parenttransactionreference' => '1-2-3'
);

$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());

?>
curl --user [email protected]:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -d '{
"alias": "[email protected]",
"version": "1.00",
"request": [{
  "currencyiso3a": "GBP",
  "requesttypedescriptions": ["RISKDEC"],
  "sitereference": "test_site12345",
  "baseamount": "1011",
  "orderreference": "My_Order_123",
  "accounttypedescription": "FRAUDCONTROL",
  "parenttransactionreference": "1-2-3"
}]}'
{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"GBP","requesttypedescriptions":["RISKDEC"],"sitereference":"test_site12345","baseamount":"1011","orderreference":"My_Order_123","accounttypedescription":"FRAUDCONTROL","parenttransactionreference":"1-2-3"}]}
<?xml version="1.0" encoding="utf-8"?>
<requestblock version="3.67">
  <alias>[email protected]</alias>
  <request type="RISKDEC">
    <merchant>
      <orderreference>My_Order_123</orderreference>
    </merchant>
    <billing>
      <amount currencycode="GBP">1011</amount>       
    </billing>
    <operation>
      <parenttransactionreference>1-2-3</parenttransactionreference>
      <accounttypedescription>FRAUDCONTROL</accounttypedescription>
      <sitereference>test_site12345</sitereference>
    </operation>
  </request>
</requestblock>

Replace <DOMAIN> with a supported domain. Click here for a full list.

 

Response example

Here is an example of the associated RISKDEC response:

For the RISKDEC response field specification, scroll down to the “Interpreting the response” section.


{
  u 'requestreference': u 'Ad4ft45gp',
    u 'version': u '1.00',
    u 'response': [{
        u 'acquirerrecommendedaction': u 'C',
        u 'fraudcontrolresponsecode': u '0100',
        u 'paymenttypedescription': u 'VISA',
        u 'orderreference': u 'My_Order_123',
        u 'transactionstartedtimestamp': u '2016-12-07 16:25:19',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'parenttransactionreference': u '1-2-345678',
        u 'fraudcontrolreference': u 'TEST',
        u 'accounttypedescription': u 'FRAUDCONTROL',
        u 'errorcode': u '0',
        u 'transactionreference': u '1-2-345679',
        u 'maskedpan': u '411111######1111',
        u 'requesttypedescription': u 'RISKDEC',
        u 'fraudcontrolshieldstatuscode': u 'ACCEPT',
        u 'livestatus': u '0'
    }]
}
array(3) {
  ["requestreference"] => string(9) "A0bjmprty"
  ["version"] => string(4) "1.00"
  ["response"] => array(1) {
      [0] => array(16) {
        ["errorcode"] => string(1) "0"
        ["orderreference"] => string(12) "My_Order_123"
        ["fraudcontrolresponsecode"] => string(4) "0100"
        ["paymenttypedescription"] => string(4) "VISA"
        ["maskedpan"] => string(16) "411111######1111"
        ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:14:35"
        ["errormessage"] => string(2) "Ok"
        ["operatorname"] => string(23) "[email protected]"
        ["parenttransactionreference"] => string(10) "1-2-345678"
        ["accounttypedescription"] => string(12) "FRAUDCONTROL"
        ["acquirerrecommendedaction"] => string(1) "C"
        ["transactionreference"] => string(9) "1-2-345679"
        ["requesttypedescription"] => string(7) "RISKDEC"
        ["fraudcontrolreference"] => string(4) "TEST"
        ["fraudcontrolshieldstatuscode"] => string(6) "ACCEPT"
        ["livestatus"] => string(1) "0"
      }
  }
}
{"requestreference":"W23-eyqd5u3x","version":"1.00","response":[{"errorcode":"0","fraudcontrolresponsecode":"0150","paymenttypedescription":"VISA","orderreference":"My_Order_123","transactionstartedtimestamp":"2016-12-07 16:24:50","errormessage":"Ok","operatorname":"[email protected]","parenttransactionreference":"1-2-345678","accounttypedescription":"FRAUDCONTROL","acquirerrecommendedaction":"C","transactionreference":"1-2-345679","requesttypedescription":"RISKDEC","maskedpan":"411111######1111","fraudcontrolreference":"TEST","fraudcontrolshieldstatuscode":"ACCEPT","livestatus":"0"}],"secrand":"ft9j6l"}
<?xml version="1.0" encoding="utf-8"?>
<responseblock version="3.67">
  <requestreference>X336659733</requestreference>
  <response type="RISKDEC">
    <merchant>
      <orderreference>My_Order_123</orderreference>
      <operatorname>[email protected]</operatorname>
    </merchant>
    <transactionreference>18-65-2</transactionreference>
    <billing>
      <payment type="VISA">
        <pan>411111######1111</pan>
      </payment>
    </billing>
    <timestamp>2012-06-21 13:32:43</timestamp>
    <fraudcontrol>
      <shieldstatuscode>ACCEPT</shieldstatuscode>
      <reference>TEST</reference>
      <recommendedaction>C</recommendedaction>
      <responsecode>0150</responsecode>
    </fraudcontrol>
    <live>0</live>
    <error>
      <message>Ok</message>
      <code>0</code>
    </error>
    <operation>
      <parenttransactionreference>1-2-345679</parenttransactionreference>
      <accounttypedescription>FRAUDCONTROL</accounttypedescription>
    </operation>
  </response>
  <secrand>UIPGZ</secrand>
</responseblock>

 

Interpreting the response

Here is the field specification for a RISKDEC response:

 

Field Format Description
acquirerrecommendedaction
XPath: /fraudcontrol/recommendedaction
Char (1) Either:

  • “C” – Continue with the transaction.
  • “S” – Stop transaction.

Note that this is ONLY a recommendation. Protect Plus does not guarantee against fraud.

fraudcontrolreference
XPath: /fraudcontrol/reference
Alphanumeric (255) Unique reference to identify the Risk Decision check performed.
fraudcontrolresponsecode
XPath: /fraudcontrol/responsecode
Numeric (4) A numeric code that is mapped to a description of the results of the Risk Decision checks performed.
fraudcontrolshieldstatuscode
XPath: /fraudcontrol/shieldstatuscode
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.
requesttypedescription
XPath: /@type
Alpha (20) You will be returned “RISKDEC”.
rulecategoryflag
XPath: /fraudcontrol/categoryflag
Alphanumeric (255) Reference used to identify a condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode.
rulecategorymessage
XPath: /fraudcontrol/categorymessage
Text (undefined length) Condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode.

 

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.

 

Best practices

 

This section assumes you have already read our Getting started documentation and understand how to submit a basic request to us. If you haven’t already, we recommend reading this before you continue.

 

When receiving our response, your system will need to perform the following checks on the values returned (where applicable) to ensure the request was processed successfully.

 

Error code

The errorcode is a fundamentally important field as it displays the outcome of the submitted request. It is returned in every response from Trust Payments.

Status good

If the errorcode is “0”, this indicates the request was processed successfully.

 

It is imperative that you have a process in place to check the final status of the processed request, by looking at the values of the other fields returned. 

Status attention

If the errorcode is “30000”, this indicates a field error.

If you look at the errordata field returned, this typically contains the name of the field that was deemed invalid. You will need to retry the request, ensuring all required fields have been submitted, and that all submitted field values follow our specification.

Status attention

If the errorcode is “70000”, this indicates a payment was declined by your bank.

We recommend that you show an error message to the customer and allow them to try a different method of payment.

Status bad

If the errorcode is “60010”, “60034” or “99999”, there has been a problem processing the request and the final status is not known.

 

This can be due to a communication problem with a bank or third party. In such cases, we recommend informing the customer of the problem and to contact you to query the issue. You will need to contact our Support team, providing a copy of the entire request submitted and response returned, and we will contact the relevant parties to establish the status of the request. In the interest of security, ensure you omit or mask sensitive field values, such as card details.

If the errorcode is not listed above, please refer to our full list of errorcodes for assistance. If you need further help, please contact our Support team.

 

Settle status

It is important to check the value of the settlestatus when processing an AUTH or REFUND request, as this indicates if Settlement will be performed. Here are the basics:

Status good

If the settlestatus is “0”, “1” or “10”, you do not need to take any further actions.

The transaction is currently scheduled to settle.

Status good

If the settlestatus is “100”, the transaction has been settled.

You cannot perform any further updates to the transaction.

Status attention

If the settlestatus is “2”, the transaction has been suspended.

Funds will not be settled without your intervention. Please refer to our settlement documentation for further information.

Status bad

If the settlestatus is “3”, the transaction has been cancelled.

Funds will not be settled and you will need to investigate the problem and try again. In this scenario, it is useful to look at the accompanying errorcode as this will often inform you of the reason behind the transaction failing.

If you haven’t already, we recommend you read our settlement documentation for further detail on how settlement is performed.

 

Security response

If the AVS and Security Code Checks are performed as part of the request (as is the case for most AUTH and ACCOUNTCHECKs), you will need to check the three security response fields returned, which are defined as follows:

Status good

If the value is “2”, the customer entered the correct details.

If all values are “2”, there is no reason here to prevent the transaction from settling.

Status attention

If the value is “1”, the bank was unable to check the customer’s details.

This may be because the customer has a card issued by a foreign country, and your bank was therefore unable to check their address. You may need to consider suspending transactions that fall into this category to allow you to investigate before proceeding with the payment.

Status attention

If the value is “0”, the customer’s details were not sent to the bank.

This is because the customer didn’t enter any of the details at all, or that these details were not submitted in your request. You may need to consider suspending transactions that fall into this category to allow you to investigate before proceeding with the payment.

Status bad

If the value is “4”, the customer entered incorrect details.

By default, we will suspend transactions where the security code entered by the customer fails to match the value on their card. Depending on your preferences, you may also prefer to suspend transactions where the address details do not match (disabled by default).

You can request that Trust Payments automatically cancels transactions when the security response fields have a certain value. As mentioned above, we suspend all transactions where the security code entered by the customer fails to match the value on their card. You can specify the circumstances under which transactions are suspended to match your own preferences (you can even disable such checks entirely). This is achieved by modifying your Security Policy. To discuss changes to your account’s security policy, please contact our Support team.

 

Request type description

Each response will contain a requesttypedescription. The value of this field returned in the response should always match the value submitted in the request.

e.g. If you are sending an “AUTH” request, ensure the requesttypedescription returned is “AUTH”.

If you receive requesttypedescription with value “ERROR”, the request may not have been processed successfully and you will need to investigate.

 

Live status

Check the live status value returned is “0” while testing and “1” when processing live payments.

 

Amount & currency

When submitting an amount and currency, check that the same values are returned in the response.

 

Response site security

If you are processing transactions using our Payment Pages interface, and have configured URL notifications or redirects to be triggered upon transaction completion, you will need to re-calculate the site security hash using the fields returned and check it matches the corresponding hash returned from Trust Payments. This is to ensure the content returned hasn’t been modified by an unauthorised party. Click here to learn more.

 

Settlement

 

Info
The following procedure applies to card-based payment methods. Please be aware that the settlement process for certain APMs (Alternative Payment Methods) may deviate from the below. For this reason it is important that you read the relevant documentation when adding APMs to your solution.

 

Once a transaction has been authorised, the funds are then reserved against the customer’s account for 7 days. The instruction to transfer the funds is scheduled daily when we submit a batch of all pending transactions to your acquirer.

 

This process is called settlement and is outlined below:

1
The initial phase of the settlement process occurs when we submit a file to your acquirer. The file contains all transactions that are in status ‘pending settlement’, and this occurs daily.
2
When your acquirer has received the settlement file, they commence the process of physically settling the money into your nominated bank account. The time frame of this payment differs between banks, and is not determined by Trust Payments. If reserved funds are not settled, they are released back onto the customer’s card. We recommend that you regularly sign in to MyST to check the status of your payments.

 

Deferred settlement

Settlement can be deferred for certain transactions. You can request this by modifying the payment request, or transactions may be deferred by our internal fraud system. You should therefore sign in to MyST on a regular basis, to check the status of your transactions.

 

Settle status

Settle status 0

Settle status 0 – Pending settlement

Transaction that has been authorised by card issuer for payment.

  • Settles automatically.
  • Can be updated or cancelled.
  • Does not currently require action from the merchant.
  • May be suspended by future Fraud checks and Duplicate checks, if enabled.
Settle status 1

Settle status 1 – Pending settlement (manual override)

Transaction that has been authorised by card issuer for payment.

  • Settles automatically.
  • Can be updated or cancelled.
  • Does not require further action from merchant.
  • Bypasses fraud and duplicate checks, if enabled.
Settle status 10

Settle status 10 – Settling

Details of this transaction have been sent to the acquiring bank for settlement.

  • Does not require further action from merchant.
  • Settles automatically.
  • Cannot be updated or cancelled.
Settle status 100

Settle status 100 – Settled

Transaction has been settled into the merchant’s account.

  • Does not require further action from merchant.
  • Cannot be updated or cancelled.
  • Can be refunded (unless all funds have already been refunded).
Settle status 2
Settle status 2 – Suspended

Transaction has been suspended, and will not settle without action from the merchant.

  • Transactions can be suspended by merchants to prevent settlement, allowing for manual investigation.
  • Transactions can be suspended by Trust Payments if fraud or duplicate checks (if enabled) raise an issue.
  • If left in a suspended state for 7 days after the authorisation date, the transaction will be cancelled automatically (updated to settle status ‘3’). This limit is extended to 31 days for pre-authorisations.
  • The merchant can update transactions in settle status ‘2’ to the following states:
    ‘0’ – Allows settlement to occur, providing the transaction passes fraud checks.
    ‘1’ – Allows settlement to occur, bypassing fraud checks.
    ‘3’ – Manually cancels the transaction.
Settle status 3

Settle status 3 – Cancelled

Transaction has been cancelled and will not settle.

  • This can be due to an error or due to the transaction being declined.
  • If a transaction is left in a suspended state (settle status ‘2’) for 7 days after the authorisation date, the transaction will be cancelled automatically. This limit is extended to 31 days for pre-authorisations.
  • Merchants can also manually update transactions to settle status to ‘3’ to cancel them.
  • Cancelled transactions cannot be updated.

 


 

Additional resources

Protect Plus

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.

 

Process overview

Status good
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:

 

Warning
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 you submit a RISKDEC request. You can update a standard AUTH request to also include a RISKDEC in two different ways:

 

RISKDEC then AUTH request

Process overview

 

Info
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.

 

Request example

Here is an example of a combined RISKDEC then AUTH request. Notice how the structure is the same as a standard AUTH request, except “RISKDEC” is included in the requesttypedescriptions field before “AUTH”.


#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

auth= {
    "sitereference": "test_site12345",
    "requesttypedescriptions": ["RISKDEC","AUTH"],
    "accounttypedescription": "ECOM",
    "currencyiso3a": "GBP",
    "baseamount": "1011",
    "orderreference": "My_Order_123",
    "cachetoken": "token_posted_by_st.js"
}

strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php

if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
  throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);

$configData = array(
'username' => '[email protected]',
'password' => 'Password1^',
);

$requestData = array(
  'sitereference' => 'test_site12345',
  'requesttypedescriptions' => array('RISKDEC','AUTH'),
  'accounttypedescription' => 'ECOM',
  'currencyiso3a' => 'GBP',
  'baseamount' => '1011',
  'orderreference' => 'My_Order_123',
  'cachetoken' => 'token_posted_by_st.js'
);

$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());

?>
curl --user [email protected]:Password1^ https://webservices.securetrading.net/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias": "[email protected]",
"version": "1.00",
"request": [{
  "currencyiso3a": "GBP",
  "requesttypedescriptions": ["RISKDEC","AUTH"],
  "sitereference": "test_site12345",
  "baseamount": "1011",
  "orderreference": "My_Order_123",
  "accounttypedescription": "ECOM",
  "cachetoken": "token_posted_by_st.js"
}]}'

 

Response example

Here is an example of a combined RISKDEC then AUTH response. Notice how the response is divided into two parts; the first represents the “RISKDEC” response and the second represents the “AUTH” response (as indicated by the values of the requesttypedescription fields).

For the RISKDEC response field specification, scroll down to the “Interpreting the response” section.


{
  u 'requestreference': u 'A0dcb11e6',
    u 'version': u '1.00',
    u 'response': [{
      u 'acquirerrecommendedaction': u 'C',
        u 'fraudcontrolresponsecode': u '0100',
        u 'paymenttypedescription': u 'VISA',
        u 'orderreference': u 'My_Order_123',
        u 'transactionstartedtimestamp': u '2016-12-07 16:19:28',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'fraudcontrolreference': u 'TEST',
        u 'accounttypedescription': u 'FRAUDCONTROL',
        u 'errorcode': u '0',
        u 'transactionreference': u '1-2-345678',
        u 'maskedpan': u '411111######1111',
        u 'requesttypedescription': u 'RISKDEC',
        u 'fraudcontrolshieldstatuscode': u 'ACCEPT',
        u 'livestatus': u '0'
    }, {
      u 'transactionstartedtimestamp': u '2016-12-07 16:19:28',
        u 'parenttransactionreference': u '1-2-345678',
        u 'livestatus': u '0',
        u 'issuer': u 'SecureTrading Test Issuer1',
        u 'splitfinalnumber': u '1',
        u 'dccenabled': u '0',
        u 'settleduedate': u '2016-12-07',
        u 'errorcode': u '0',
        u 'orderreference': u 'My_Order_123',
        u 'tid': u '27882788',
        u 'merchantnumber': u '00000000',
        u 'merchantcountryiso2a': u 'GB',
        u 'transactionreference': u '1-2-345679',
        u 'merchantname': u 'Test Merchant',
        u 'paymenttypedescription': u 'VISA',
        u 'baseamount': u '1011',
        u 'accounttypedescription': u 'ECOM',
        u 'acquirerresponsecode': u '00',
        u 'requesttypedescription': u 'AUTH',
        u 'securityresponsesecuritycode': u '2',
        u 'currencyiso3a': u 'GBP',
        u 'authcode': u 'TEST19',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'securityresponsepostcode': u '0',
        u 'maskedpan': u '411111######1111',
        u 'securityresponseaddress': u '0',
        u 'issuercountryiso2a': u 'US',
        u 'settlestatus': u '0'
    }]
}
array(3) {
  ["requestreference"] => string(9) "A58cdfkpy"
  ["version"] => string(4) "1.00"
  ["response"] => array(2) {
    [0] => array(15) {
        ["errorcode"] => string(1) "0"
        ["orderreference"] => string(12) "My_Order_123"
        ["fraudcontrolresponsecode"] => string(4) "0100"
        ["paymenttypedescription"] => string(4) "VISA"
        ["maskedpan"] => string(16) "411111######1111"
        ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:12:39"
        ["errormessage"] => string(2) "Ok"
        ["operatorname"] => string(23) "[email protected]"
        ["accounttypedescription"] => string(12) "FRAUDCONTROL"
        ["acquirerrecommendedaction"] => string(1) "C"
        ["transactionreference"] => string(9) "1-2-345678"
        ["requesttypedescription"] => string(7) "RISKDEC"
        ["fraudcontrolreference"] => string(4) "TEST"
        ["fraudcontrolshieldstatuscode"] => string(6) "ACCEPT"
        ["livestatus"] => string(1) "0"
      }
      [1] =>array(29) {
        ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:12:39"
        ["parenttransactionreference"] => string(9) "1-2-345678"
        ["livestatus"] => string(1) "0"
        ["issuer"] => string(26) "SecureTrading Test Issuer1"
        ["splitfinalnumber"] => string(1) "1"
        ["dccenabled"] => string(1) "0"
        ["settleduedate"] => string(10) "2016-12-09"
        ["errorcode"] => string(1) "0"
        ["orderreference"] => string(12) "My_Order_123"
        ["tid"] => string(8) "27882788"
        ["merchantnumber"] => string(8) "00000000"
        ["merchantcountryiso2a"] => string(2) "GB"
        ["transactionreference"] => string(10) "1-2-345679"
        ["merchantname"] => string(13) "Test Merchant"
        ["paymenttypedescription"] => string(4) "VISA"
        ["baseamount"] => string(4) "1011"
        ["accounttypedescription"] => string(4) "ECOM"
        ["acquirerresponsecode"] => string(2) "00"
        ["requesttypedescription"] => string(4) "AUTH"
        ["securityresponsesecuritycode"] => string(1) "2"
        ["currencyiso3a"] => string(3) "GBP"
        ["authcode"] => string(6) "TEST53"
        ["errormessage"] => string(2) "Ok"
        ["operatorname"] => string(23) "[email protected]"
        ["securityresponsepostcode"] => string(1) "0"
        ["maskedpan"] => string(16) "411111######1111"
        ["securityresponseaddress"] => string(1) "0"
        ["issuercountryiso2a"] => string(2) "US"
        ["settlestatus"] => string(1) "0"
    }
  }
}
{"requestreference":"W23-wt77f0n8","version":"1.00","response":[{"errorcode":"0","fraudcontrolresponsecode":"0100","paymenttypedescription":"VISA","orderreference":"My_Order_123","transactionstartedtimestamp":"2016-12-07 16:23:03","errormessage":"Ok","operatorname":"[email protected]","accounttypedescription":"FRAUDCONTROL","acquirerrecommendedaction":"C","transactionreference":"1-2-345678","requesttypedescription":"RISKDEC","maskedpan":"411111######1111","fraudcontrolreference":"TEST","fraudcontrolshieldstatuscode":"ACCEPT","livestatus":"0"},{"transactionstartedtimestamp":"2016-12-07 16:23:03","parenttransactionreference":"1-2-345678","livestatus":"0","issuer":"SecureTrading Test Issuer1","splitfinalnumber":"1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","baseamount":"1011","tid":"27882788","merchantnumber":"00000000","merchantcountryiso2a":"GB","transactionreference":"1-2-345679","merchantname":"Test Merchant","paymenttypedescription":"VISA","orderreference":"My_Order_123","accounttypedescription":"ECOM","acquirerresponsecode":"00","requesttypedescription":"AUTH","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST14","errormessage":"Ok","operatorname":"[email protected]","securityresponsepostcode":"0","maskedpan":"411111######1111","securityresponseaddress":"0","issuercountryiso2a":"US","settlestatus":"0"}],"secrand":"E0ksvyuH5VKg"}

 

AUTH then RISKDEC request

Process overview

 

 

Info
Specifying for the RISKDEC to be performed after the AUTH allows Trust Payments to take into account the results of AVS, Security Code Checks and 3-D Secure checks performed when analysing the submitted details for fraud.

 

Request example

Here is an example of a combined AUTH then RISKDEC request. Notice how the structure is the same as a standard AUTH request, except “RISKDEC” is included in the requesttypedescriptions field after “AUTH”.


#!/usr/bin/python
import securetrading

stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)

auth= {
    "sitereference": "test_site12345",
    "requesttypedescriptions": ["AUTH","RISKDEC"],
    "accounttypedescription": "ECOM",
    "currencyiso3a": "GBP",
    "baseamount": "1011",
    "orderreference": "My_Order_123",
    "cachetoken": "token_posted_by_st.js"
}

strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php

if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
  throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);

$configData = array(
'username' => '[email protected]',
'password' => 'Password1^',
);

$requestData = array(
  'sitereference' => 'test_site12345',
  'requesttypedescriptions' => array('AUTH','RISKDEC'),
  'accounttypedescription' => 'ECOM',
  'currencyiso3a' => 'GBP',
  'baseamount' => '1011',
  'orderreference' => 'My_Order_123',
  'cachetoken' => 'token_posted_by_st.js'
);

$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());

?>
curl --user [email protected]:Password1^ https://webservices.securetrading.net/json/ -H "Content-type: application/json" -H "Accept: application/json" -d '{
"alias": "[email protected]",
"version": "1.00",
"request": [{
  "currencyiso3a": "GBP",
  "requesttypedescriptions": ["AUTH","RISKDEC"],
  "sitereference": "test_site12345",
  "baseamount": "1011",
  "orderreference": "My_Order_123",
  "accounttypedescription": "ECOM",
  "cachetoken": "token_posted_by_st.js"
}]}'

 

Response example

Here is an example of a combined AUTH then RISKDEC response. Notice how the response is divided into two parts; the first represents the “AUTH” response and the second represents the “RISKDEC” response (as indicated by the values of the requesttypedescription fields).

For the RISKDEC response field specification, scroll down to the “Interpreting the response” section.


{
  u 'requestreference': u 'Ad4ft45gp',
    u 'version': u '1.00',
    u 'response': [{
      u 'transactionstartedtimestamp': u '2016-12-07 16:25:19',
        u 'livestatus': u '0',
        u 'issuer': u 'SecureTrading Test Issuer1',
        u 'splitfinalnumber': u '1',
        u 'dccenabled': u '0',
        u 'settleduedate': u '2016-12-07',
        u 'errorcode': u '0',
        u 'orderreference': u 'My_Order_123',
        u 'tid': u '27882788',
        u 'merchantnumber': u '00000000',
        u 'merchantcountryiso2a': u 'GB',
        u 'transactionreference': u '1-2-345678',
        u 'merchantname': u 'Test Merchant',
        u 'paymenttypedescription': u 'VISA',
        u 'baseamount': u '1011',
        u 'accounttypedescription': u 'ECOM',
        u 'acquirerresponsecode': u '00',
        u 'requesttypedescription': u 'AUTH',
        u 'securityresponsesecuritycode': u '2',
        u 'currencyiso3a': u 'GBP',
        u 'authcode': u 'TEST57',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'securityresponsepostcode': u '0',
        u 'maskedpan': u '411111######1111',
        u 'securityresponseaddress': u '0',
        u 'issuercountryiso2a': u 'US',
        u 'settlestatus': u '0'
    }, {
      u 'acquirerrecommendedaction': u 'C',
        u 'fraudcontrolresponsecode': u '0100',
        u 'paymenttypedescription': u 'VISA',
        u 'orderreference': u 'My_Order_123',
        u 'transactionstartedtimestamp': u '2016-12-07 16:25:19',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'parenttransactionreference': u '1-2-345678',
        u 'fraudcontrolreference': u 'TEST',
        u 'accounttypedescription': u 'FRAUDCONTROL',
        u 'errorcode': u '0',
        u 'transactionreference': u '1-2-345679',
        u 'maskedpan': u '411111######1111',
        u 'requesttypedescription': u 'RISKDEC',
        u 'fraudcontrolshieldstatuscode': u 'ACCEPT',
        u 'livestatus': u '0'
    }]
}
array(3) {
  ["requestreference"] => string(9) "A0bjmprty"
  ["version"] => string(4) "1.00"
  ["response"] => array(2) {
    [0] => array(28) {
        ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:14:35"
        ["livestatus"] => string(1) "0"
        ["issuer"] => string(26) "SecureTrading Test Issuer1"
        ["splitfinalnumber"] => string(1) "1"
        ["dccenabled"] => string(1) "0"
        ["settleduedate"] => string(10) "2016-12-09"
        ["errorcode"] => string(1) "0"
        ["orderreference"] => string(12) "My_Order_123"
        ["tid"] => string(8) "27882788"
        ["merchantnumber"] => string(8) "00000000"
        ["securityresponsepostcode"] => string(1) "0"
        ["transactionreference"] => string(10) "1-2-345678"
        ["merchantname"] => string(13) "Test Merchant"
        ["paymenttypedescription"] => string(4) "VISA"
        ["baseamount"] => string(4) "1011"
        ["accounttypedescription"] => string(4) "ECOM"
        ["acquirerresponsecode"] => string(2) "00"
        ["requesttypedescription"] => string(4) "AUTH"
        ["securityresponsesecuritycode"] => string(1) "2"
        ["currencyiso3a"] => string(3) "GBP"
        ["authcode"] => string(6) "TEST01"
        ["errormessage"] => string(2) "Ok"
        ["operatorname"] => string(23) "[email protected]"
        ["merchantcountryiso2a"] => string(2) "GB"
        ["maskedpan"] => string(16) "411111######1111"
        ["securityresponseaddress"] => string(1) "0"
        ["issuercountryiso2a"] => string(2) "US"
        ["settlestatus"] => string(1) "0"
      }
      [1] => array(16) {
        ["errorcode"] => string(1) "0"
        ["orderreference"] => string(12) "My_Order_123"
        ["fraudcontrolresponsecode"] => string(4) "0100"
        ["paymenttypedescription"] => string(4) "VISA"
        ["maskedpan"] => string(16) "411111######1111"
        ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:14:35"
        ["errormessage"] => string(2) "Ok"
        ["operatorname"] => string(23) "[email protected]"
        ["parenttransactionreference"] => string(10) "1-2-345678"
        ["accounttypedescription"] => string(12) "FRAUDCONTROL"
        ["acquirerrecommendedaction"] => string(1) "C"
        ["transactionreference"] => string(9) "1-2-345679"
        ["requesttypedescription"] => string(7) "RISKDEC"
        ["fraudcontrolreference"] => string(4) "TEST"
        ["fraudcontrolshieldstatuscode"] => string(6) "ACCEPT"
        ["livestatus"] => string(1) "0"
      }
  }
}
{"requestreference":"W23-eyqd5u3x","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 16:24:50","livestatus":"0","issuer":"SecureTrading Test Issuer1","splitfinalnumber":"1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","baseamount":"1011","tid":"27882788","merchantnumber":"00000000","merchantcountryiso2a":"GB","transactionreference":"1-2-345678","merchantname":"Test Merchant","paymenttypedescription":"VISA","orderreference":"My_Order_123","accounttypedescription":"ECOM","acquirerresponsecode":"00","requesttypedescription":"AUTH","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST12","errormessage":"Ok","operatorname":"[email protected]","securityresponsepostcode":"0","maskedpan":"411111######1111","securityresponseaddress":"0","issuercountryiso2a":"US","settlestatus":"0"},{"errorcode":"0","fraudcontrolresponsecode":"0150","paymenttypedescription":"VISA","orderreference":"My_Order_123","transactionstartedtimestamp":"2016-12-07 16:24:50","errormessage":"Ok","operatorname":"[email protected]","parenttransactionreference":"1-2-345678","accounttypedescription":"FRAUDCONTROL","acquirerrecommendedaction":"C","transactionreference":"1-2-345679","requesttypedescription":"RISKDEC","maskedpan":"411111######1111","fraudcontrolreference":"TEST","fraudcontrolshieldstatuscode":"ACCEPT","livestatus":"0"}],"secrand":"ft9j6l"}

 

Interpreting the response

The AUTH part of the response follows the same structure as a standard AUTH response. The RISKDEC part of the response contains new fields that are described below:

 

Key

Field name Type Length Response Description
requesttypedescription Alpha 20 You will be returned “RISKDEC”.
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.
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.
acquirerrecommendedaction Char 1 Either:

  • “C” – Continue with the transaction.
  • “S” – Stop transaction.

Note that this ONLY a recommendation. Protect Plus does not guarantee against fraud.

rulecategoryflag Alphanumeric 255 Reference used to identify a condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode.
rulecategorymessage Alphanumeric Not defined Condition that was met to return the DENY or CHALLENGE fraudcontrolshieldstatuscode.

 

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.

 

Protect Plus with 3-D Secure

Protect Plus can be used in conjunction with 3-D Secure.

 

Method A – RISKDEC before THREEDQUERY and AUTH

When performing the RISKDEC request before the THREEDQUERY and AUTH, the RISKDEC response can assist you in deciding whether or not to proceed with the transaction. We automatically suspend transactions deemed suspicious by the Protect Plus system.

Here is the flow to follow:

  1. Your system submits a RISKDEC request.
  2. Your system submits a THREEDQUERY request, ensuring the transactionreference returned in the RISKDEC response is submitted in the parenttransactionreference field.
    Note: If the fraudcontrolshieldstatuscode is “CHALLENGE” or “DENY”, the THREEDQUERY will fail, returning the errorcode “60107”.
  3. You will need to redirect the customer’s browser to the ACS, and then process the AUTH (if the customer has been successfully authenticated).

 

Method B – THREEDQUERY and AUTH before RISKDEC

When performing the RISKDEC request after the THREEDQUERY and AUTH, information on whether or not the customer is enrolled in 3-D Secure (in addition to the results of the AVS and security code checks) can be used by the Protect Plus system to assist you in deciding whether or not to proceed with the transaction.

Here is the flow to follow:

  1. Your system submits a THREEDQUERY request.
  2. You will need to redirect the customer’s browser to the ACS, and then process the AUTH (if the customer has been successfully authenticated).
  3. Your system submits a RISKDEC request, ensuring the transactionreference returned in the AUTH response is submitted in the parenttransactionreference field.
    Note: If the fraudcontrolshieldstatuscode is “CHALLENGE” or “DENY”, we recommend that you suspend the transaction for review (update to settle status “2”).

 

investors in people logo   pci - security standards council logo

TRUST Payments LTD, No.1 Royal Exchange, London, EC3V 3DG.
A company registered in England and Wales with Company Number 04591066. VAT Number 756265116