The following documentation explains how to manually submit an AUTH request using our Webservices API.
If you are already processing e-commerce payments using our JavaScript Library (using 3-D Secure v2), you no longer need to manually perform the AUTH request described herein (as the JavaScript Library will automatically perform the authorisation).
Requirements

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.

All businesses within the EEA (European Economic Area) are mandated to use 3-D Secure when processing e-commerce transactions, as part of the PSD2 mandate.
To process an e-commerce transaction that is authenticated with 3-D Secure, you will need to utilise our JavaScript Library instead of the solution described below. Click here to get started.
The following content should only be utilised by merchants processing Mail or Telephone Order (MOTO) payments, Merchant Initiated Transactions (MIT), or other workflows that are exempt from the PSD2 mandate.

ECOM (e-Commerce) Maestro transactions require the implementation of 3-D Secure in order to be processed successfully.
To perform 3-D Secure, you will need to utilise our JavaScript Library. Click here to get started.

In order to reduce fraud, Visa has mandated that all UK-based merchants with a
Merchant Category Code (MCC) of 6012 are required to send additional fields in AUTH and ACCOUNTCHECK requests.
Failure to submit these fields may prevent the transaction from being processed successfully, with a “60025” errorcode being returned in the response.
Click here for further information.
AUTH request
Example
To successfully process an AUTH request, you must follow the specification below:
#!/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"],
"accounttypedescription": "ECOM",
"currencyiso3a": "GBP",
"baseamount": "1050",
"orderreference": "My_Order_123",
"pan": "4111111111111111",
"expirydate": "12/2020",
"securitycode": "123"
}
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'),
'accounttypedescription' => 'ECOM',
'currencyiso3a' => 'GBP',
'baseamount' => '1050',
'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": ["AUTH"],
"sitereference": "test_site12345",
"baseamount": "1050",
"orderreference": "My_Order_123",
"accounttypedescription": "ECOM",
"pan": "4111111111111111",
"expirydate": "12/2020",
"securitycode": "123"
}]}'
{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"GBP","requesttypedescriptions":["AUTH"],"sitereference":"test_site12345","baseamount":"1050","orderreference":"My_Order_123","accounttypedescription":"ECOM","pan":"4111111111111111","expirydate":"12\/2020","securitycode":"123"}]}
<requestblock version="3.67">
<alias>[email protected]</alias>
<request type="AUTH">
<merchant>
<orderreference>My_Order_123</orderreference>
</merchant>
<billing>
<payment>
<expirydate>12/2020</expirydate>
<pan>4111111111111111</pan>
<securitycode>123</securitycode>
</payment>
<amount currencycode="GBP">1050</amount>
</billing>
<operation>
<sitereference>test_site12345</sitereference>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
</request>
</requestblock>
Replace <DOMAIN> with a supported domain. Click here for a full list.
Field specification
Operation
The following fields relate to the type of request submitted:
|
Field |
Format |
Description |
 |
accounttypedescription
XPath: /operation/accounttypedescription |
Alpha (20) |
The type of account to be used:
- “ECOM” – E-commerce
- “MOTO” – Mail or Telephone Order
- “RECUR” – Recurring transactions
|
 |
authmethod
XPath: /operation/authmethod |
Alpha (11) |
Auth methods are used to specify how a transaction is to be processed by the card issuer. Each authmethod has a different set of requirements.
Click here for further information. |
|
credentialsonfile
XPath: /operation/credentialsonfile |
Numeric (1) |
The allowed values for this field are 0, 1 and 2.
- “0” – Not eligible for CoF, or no intention of re-using credentials at a later time.
- “1” – Transaction credentials flagged as available for future use.
- “2” – Payment using previously-stored credentials.
|
|
initiationreason
XPath: /operation/initiationreason |
Char (1) |
Allows you to assign a reason for a Merchant Initiated Transaction (MIT).
Do not submit when processing a Customer Initiated Transaction (CIT).The allowed values for this field are “A”, “C”, “D”, “S” and “X”.
- “A” – Reauthorisation
- “C” – Unscheduled payment
- “D” – Delayed Charges
- “S” – Resubmission
- “X” – No-show (for a hotel booking)
Click here for further information on the different initiationreason values.
Note: You must ensure the initiationreason submitted in the request correctly represents the reason for the new payment. Visa may introduce new values to this list in the future. Please refer to Visa’s own documentation for further information. |
 |
parenttransactionreference
XPath: /operation/parenttransactionreference |
Alphanumeric
& hyphens (25) |
Allows you to specify the transactionreference of a previous request. Key details are inherited from this request. |
 |
requesttypedescriptions
XPath: /@type |
Alpha (20) |
You must submit “AUTH”, as shown in the request example. |
 |
sitereference
XPath: /operation/sitereference |
Alphanumeric
& underscore (50) |
Identifies your site on the Trust Payments system.
If you do not know your site reference, please contact our Support Team. |
Payment
The following fields contain the customer’s payment details:
|
Field |
Format |
Description |
 |
baseamount
XPath: /billing/amount |
Numeric (13) |
The amount of the transaction in base units, with no commas or decimal points, so £10 is submitted as 1000. This value must be greater than zero. (Max length may vary depending on your acquiring bank – Contact your bank for further info) |
 |
currencyiso3a
XPath: /billing/amount/@currencycode |
Alpha (3) |
The currency of the transaction. Click here for a full list of available currencies.
If the currency is submitted in a child request, it must be the same value as the parent transaction. |
 |
expirydate
XPath: /billing/payment/expirydate |
Date MM/YYYY |
The expiry date printed on the card. |
 |
pan
XPath: /billing/payment/pan |
Numeric (12-19) |
This is the long number printed on the front of the customer’s card. |
 |
paymenttypedescription
XPath: /billing/payment/@type |
Alpha (20) |
Payment method (e.g. “VISA” or “MASTERCARD”). |
 |
securitycode
XPath: /billing/payment/securitycode |
Numeric (3-4) |
This is the three digit security code printed on the back of the card.
(For AMEX cards, this is a 4 digit code found on the front of the card)
This field is not strictly required by Trust Payments, but it is highly recommended for the processing of security code checks.
Additionally, some banks may decline the payment if the security code is not present. |
Merchant
The following fields relate to your account configuration and allow you to configure custom unique references for your request:
|
Field |
Format |
Description |
 |
chargedescription
XPath: /merchant/chargedescription |
Alphanumeric including
symbols (25) |
This is a description of the payment that appears on the customer’s bank statement. Only supported by certain acquiring banks.
Specification of this field will depend on your acquiring bank. Click here for further information.
Valid characters:
- Uppercase/lowercase A-Z
- Numbers 0-9
- Spaces
- Punctuation: + – _ . @ ( )
|
 |
merchantemail
XPath: /merchant/email |
Email (255) |
The merchant’s email address. Maximum length of 255 (maximum of 64 characters before the ”@” symbol). |
 |
operatorname
XPath: /merchant/operatorname |
Alphanumeric (255) |
The value of this field contains the name of the user that processed the request. By default, this is the Web Services username included in the request. This can be overridden with a custom value by passing through this field in the request (optional). |
 |
orderreference
XPath: /merchant/orderreference |
Alphanumeric including
symbols (255) |
Your unique order reference that can be stored on the Trust Payments system.
Note: This can be updated at a later time (only if transaction is pending settlement). |
Billing
The following fields contain the customer’s billing details:
Customer and delivery
The following fields contain the customer’s delivery details:
Settlement
The following fields contain the Settlement details:
|
Field |
Format |
Description |
 |
settleduedate
XPath: /settlement/settleduedate |
Date YYYY-MM-DD |
You can submit this field in the request to specify the date you would like your transaction to settle. This must be within 7 days of the authorisation date. |
 |
settlestatus
XPath: /settlement/settlestatus |
Numeric (3) |
A numeric value used to define the settlement instruction. If you do not submit a value here, the settlestatus defaults to “0”.
Click here for a full list of settlestatus values. |
AUTH response
The following is an example of an AUTH response indicating the request was processed successfully.
{
u 'requestreference': u 'A0bxh87wt',
u 'version': u '1.00',
u 'response': [{
u 'transactionstartedtimestamp': u '2016-12-07 11:32:44',
u 'livestatus': u '0',
u 'issuer': u 'Test Issuer',
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 '23-9-80001',
u 'merchantname': u 'Test Merchant',
u 'paymenttypedescription': u 'VISA',
u 'baseamount': u '1050',
u 'accounttypedescription': u 'ECOM',
u 'acquirerresponsecode': u '00',
u 'requesttypedescription': u 'AUTH',
u 'securityresponsesecuritycode': u '2',
u 'currencyiso3a': u 'GBP',
u 'authcode': u 'TEST36',
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) "A3579dkvx"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(28) {
["transactionstartedtimestamp"] => string(19) "2016-12-09 09:52:19"
["livestatus"] => string(1) "0"
["issuer"] => string(26) "Test Issuer"
["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) "72-9-80003"
["merchantname"] => string(13) "Test Merchant"
["paymenttypedescription"] => string(4) "VISA"
["baseamount"] => string(4) "1050"
["accounttypedescription"] => string(4) "ECOM"
["acquirerresponsecode"] => string(2) "00"
["requesttypedescription"] => string(4) "AUTH"
["securityresponsesecuritycode"] => string(1) "2"
["currencyiso3a"] => string(3) "GBP"
["authcode"] => string(6) "TEST31"
["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"
}
}
}
{"requestreference":"W23-fjgvn3d8","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 15:08:47","livestatus":"0","issuer":"Test Issuer","splitfinalnumber":"1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","baseamount":"1050","tid":"27882788","merchantnumber":"00000000","merchantcountryiso2a":"GB","transactionreference":"23-9-80006","merchantname":"Test Merchant","paymenttypedescription":"VISA","orderreference":"My_Order_123","accounttypedescription":"ECOM","acquirerresponsecode":"00","requesttypedescription":"AUTH","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST96","errormessage":"Ok","operatorname":"[email protected]","securityresponsepostcode":"0","maskedpan":"411111######1111","securityresponseaddress":"0","issuercountryiso2a":"US","settlestatus":"0"}],"secrand":"zO9"}
<responseblock version="3.67">
<requestreference>A3579dkvx</requestreference>
<response type="AUTH">
<merchant>
<merchantname>Test Merchant</merchantname>
<orderreference>MyOrder123</orderreference>
<tid>27882788</tid>
<merchantnumber>00000000</merchantnumber>
<merchantcountryiso2a>GB</merchantcountryiso2a>
<operatorname>[email protected]</operatorname>
</merchant>
<transactionreference>23-9-80006</transactionreference>
<security>
<postcode>2</postcode>
<securitycode>2</securitycode>
<address>2</address>
</security>
<billing>
<amount currencycode="GBP">1050</amount>
<payment type="VISA">
<issuer>Test Issuer</issuer>
<issuercountry>ZZ</issuercountry>
<pan>411111######1111</pan>
</payment>
<dcc enabled="0"/>
</billing>
<authcode>TEST96</authcode>
<timestamp>2012-10-08 12:46:02</timestamp>
<settlement>
<settleduedate>2012-10-08</settleduedate>
<settlestatus>0</settlestatus>
</settlement>
<live>0</live>
<error>
<message>Ok</message>
<code>0</code>
</error>
<acquirerresponsecode>00</acquirerresponsecode>
<operation>
<splitfinalnumber>1</splitfinalnumber>
<authmethod>PRE</authmethod>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
</response>
<secrand>hYWFMkiiAZ0wKHFZ</secrand>
</responseblock>
When you receive an AUTH response, you must check the field values, to ensure the request was processed successfully.
Please refer to our “Best practices” for further information.
Field specification
Operation
Billing
Merchant
The following fields relate to your account configuration:
|
Field |
Format |
Description |
 |
chargedescription
XPath: /merchant/chargedescription |
Alphanumeric including
symbols (25) |
This is a description of the payment that appears on the customer’s bank statement.
Only supported by certain acquiring banks.
Specification of this field will depend on your acquiring bank. Click here for further information.
Valid characters:
- Uppercase/lowercase A-Z
- Numbers 0-9
- Spaces
- Punctuation: + – _ . @ ( )
|
 |
merchantnumber
XPath: /merchant/merchantnumber |
Alphanumeric (32) |
The merchant number that was used to process the transaction. Provided by the acquiring bank. |
 |
merchantcategorycode
XPath: /merchant/merchantcategorycode |
Alphanumeric (255) |
These are details associated with the account used to process the transaction.To amend these fields, please contact our Support Team.
|
merchantcity
XPath: /merchant/merchantcity |
Alphanumeric (127) |
merchantcountryiso2a
XPath: /merchant/merchantcountryiso2a |
Alpha (2) |
merchantname
XPath: /merchant/merchantname |
Alphanumeric (255) |
merchantstatecode
XPath: /merchant/merchantstatecode |
Alphanumeric (127) |
merchantzipcode
XPath: /merchant/merchantzipcode |
Alphanumeric (10) |
 |
operatorname
XPath: /merchant/operatorname |
Alphanumeric (255) |
The value of this field contains the name of the user that processed the request. |
 |
orderreference
XPath: /merchant/orderreference |
Alphanumeric including
symbols (255) |
Your unique order reference that can be stored on the Trust Payments system.
Note: This can be updated at a later time (only if transaction is pending settlement). |
 |
tid
XPath: /merchant/tid |
Alphanumeric (255) |
The terminal ID used to process the transaction. This is accredited to your merchant number when we setup your account in our systems. |
Settlement
The following fields contain the Settlement details:
|
Field |
Format |
Description |
 |
settleduedate
XPath: /settlement/settleduedate |
Date YYYY-MM-DD |
The date on which the transaction will be settled. |
 |
settlestatus
XPath: /settlement/settlestatus |
Numeric (3) |
A numeric value used to indicate the progress of settlement regarding this transaction.
Click here for a full list of settlestatus values. |
Transaction status
The following fields returned in the response indicate the outcome of the request:
In addition to the
response object, two additional fields are also returned in the response:
|
Field |
Format |
Description |
 |
requestreference |
Alphanumeric (25) |
This is an internal field generated by Trust Payments. It must not be validated. If problems are experienced with the request this field may be requested by Trust Payments support to aid in determining the cause. |
 |
secrand |
Alphanumeric (16) |
Random string of characters, returned in the response of non-API-based libraries developed by Trust Payments. |
The requests outlined in this document will need to be processed manually using our Webservices API.

MyBank is a real-time bank transfer system that operates in Italy. When processing a payment with MyBank, customers will be prompted to select their bank and then to sign in to their online banking account. After reviewing the pre-filled payment details, they can agree to the payment, before being redirected back to your website. Once completed, you will receive confirmation via a URL notification.
Features
Configuration
To enable MyBank on your account, please get in touch with your account manager.
A test sandbox account will be provided, which you will need when testing your implementation.
Process overview

Initiate the customer
- Customer agrees to a payment using MyBank on the merchant’s website.
- Merchant submits AUTH request to initiate the session, including the successfulurlredirect and errorurlredirect.
- Merchant receives AUTH response, including redirecturl.

Redirect to MyBank
- Merchant redirects the customer’s browser to the redirecturl.
- Customer follows instructions on MyBank’s hosted pages to authorise the payment.
- If successful, the browser is redirected to the successfulurlredirect, a page hosted by the merchant that displays confirmation of payment.
- If there has been a problem with the payment, the browser is redirected to the errorurlredirect, a page hosted by the merchant that displays an error to the customer.

Payment completion
- At a later time, MyBank will contact Trust Payments with confirmation that funds have been settled.
- Trust Payments will submit a URL notification to the merchant’s system to confirm funds have settled.
- Merchant receives the notification and responds to inform Trust Payments the notification was received successfully.
1. Initiate the customer
When the customer chooses to pay with MyBank, your system will need to perform an AUTH request and, if successful, redirect the customer’s browser to the URL returned in the response.
AUTH request
The example request below is for a MyBank AUTH request:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
auth = {
"currencyiso3a": "EUR",
"requesttypedescription": "AUTH",
"accounttypedescription": "ECOM",
"sitereference": "test_site12345",
"baseamount": "1050",
"paymenttypedescription": "MYBANK",
"successfulurlredirect": "https://yourwebsite.com",
"errorurlredirect": "https://yourwebsite.com",
"billingfirstname": "Joe",
"billinglastname": "Bloggs",
"billingcountryiso2a": "IT"
}
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(
'currencyiso3a' => 'EUR',
'requesttypedescription' => 'AUTH',
'accounttypedescription' => 'ECOM',
'sitereference' => 'test_site12345',
'baseamount' => '1050',
'paymenttypedescription' => 'MYBANK',
'successfulurlredirect' => 'https://yourwebsite.com',
'errorurlredirect' => 'https://yourwebsite.com',
'billingfirstname' => 'Joe',
'billinglastname' => 'Bloggs',
'billingcountryiso2a' => 'IT'
);
$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": "EUR",
"requesttypedescription": "AUTH",
"accounttypedescription": "ECOM",
"sitereference": "test_site12345",
"baseamount": "1050",
"paymenttypedescription": "MYBANK",
"successfulurlredirect": "https://www.example.com/success",
"errorurlredirect": "https://www.example.com/error",
"billingfirstname": "Joe",
"billinglastname": "Bloggs",
"billingcountryiso2a": "IT"
}]}'
{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"EUR","requesttypedescription":"AUTH","accounttypedescription":"ECOM","sitereference":"test_site12345","baseamount":"1050","paymenttypedescription":"MYBANK","successfulurlredirect":"https:\/\/www.example.com\/success","errorurlredirect":"https:\/\/www.example.com\/error","billingfirstname":"Joe","billinglastname":"Bloggs","billingcountryiso2a":"IT"}]}
<?xml version='1.0' encoding='utf-8'?>
<requestblock version="3.67">
<alias>[email protected]</alias>
<request type="AUTH">
<merchant>
<successfulurlredirect>https://www.example.com/success</successfulurlredirect>
<errorurlredirect>https://www.example.com/error</errorurlredirect>
</merchant>
<billing>
<name>
<first>Joe</first>
<last>Bloggs</last>
</name>
<country>IT</country>
<amount currencycode="EUR">1050</amount>
<payment type="MYBANK"/>
</billing>
<operation>
<sitereference>test_site12345</sitereference>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
</request>
</requestblock>
Replace <DOMAIN> with a supported domain. Click here for a full list.
Field specification
AUTH response
{
u'requestreference': u'An3ug1kap',
u'version': u'1.00',
u'response': [{
u'transactionreference': u'23-86-113',
u'merchantname': u'Test Merchant',
u'paymenttypedescription': u'MYBANK',
u'settleduedate': u'2017-03-16',
u'baseamount': u'1050',
u'transactionstartedtimestamp': u'2017-03-16 16:25:08',
u'errormessage': u'Ok',
u'settlestatus': u'10',
u'accounttypedescription': u'ECOM',
u'errorcode': u'0',
u'redirecturl': u'https://example.com',
u'acquirertransactionreference': u'12',
u'acquirersecret': u'q9gy5ppgdyd5fh60kfe2j0f26peu2xww',
u'requesttypedescription': u'AUTH',
u'acquirerresponsemessage': u'PENDING',
u'operatorname': u'[email protected]',
u'livestatus': u'0',
u'currencyiso3a': u'EUR'
}]
}
array(3) {
["requestreference"] => string(9) "A0345jmuw"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(18) {
["transactionreference"] => string(9) "23-86-113"
["merchantname"] => string(4) "Test Merchant"
["paymenttypedescription"] => string(10) "MYBANK"
["settleduedate"] => string(10) "2017-03-16"
["baseamount"] => string(4) "1050"
["transactionstartedtimestamp"] => string(19) "2017-03-16 16:25:08"
["errormessage"] => string(2) "Ok"
["settlestatus"] => string(2) "10"
["accounttypedescription"] => string(4) "ECOM"
["errorcode"] => string(1) "0"
["redirecturl"] => string(107) "https://example.com"
["acquirertransactionreference"] => string(2) "12"
["acquirersecret"] => string(32) "q9gy5ppgdyd5fh60kfe2j0f26peu2xww"
["requesttypedescription"] => string(4) "AUTH"
["acquirerresponsemessage"] => string(7) "PENDING"
["operatorname"] => string(11) "[email protected]"
["livestatus"] => string(1) "0"
["currencyiso3a"] => string(3) "EUR"
}
}
}
{"requestreference":"W23-fjgvn3d9","version":"1.00","response":[{"transactionreference":"23-86-113","merchantname":"Test Merchant","paymenttypedescription":"MYBANK","settleduedate":"2017-03-16","baseamount":"1050","transactionstartedtimestamp":"2017-03-16 16:25:08","errormessage":"Ok","settlestatus":"10","accounttypedescription":"ECOM","errorcode":"0","redirecturl":"https:\/\/example.com","acquirertransactionreference":"12","acquirersecret":"q9gy5ppgdyd5fh60kfe2j0f26peu2xww","requesttypedescription":"AUTH","acquirerresponsemessage":"PENDING","operatorname":"[email protected]","livestatus":"0","currencyiso3a":"EUR"}]}
<?xml version='1.0' encoding='utf-8'?>
<responseblock version="3.67">
<requestreference>Xd4nk260v</requestreference>
<response type="AUTH">
<merchant>
<merchantname>Test Merchant</merchantname>
<operatorname>[email protected]</operatorname>
</merchant>
<transactionreference>44-86-102</transactionreference>
<timestamp>2017-03-16 17:34:16</timestamp>
<acquirersecret>gfc8mx0p2fx26f1n5tpy6mtk21naap8c</acquirersecret>
<operation>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
<settlement>
<settleduedate>2017-03-16</settleduedate>
<settlestatus>10</settlestatus>
</settlement>
<acquirerresponsemessage>PENDING</acquirerresponsemessage>
<billing>
<amount currencycode="EUR">1050</amount>
<payment type="MYBANK"/>
</billing>
<live>0</live>
<other>
<redirecturl>https://example.com</redirecturl>
</other>
<acquirertransactionreference>4</acquirertransactionreference>
<error>
<message>Ok</message>
<code>0</code>
</error>
</response>
<secrand>Z1W</secrand>
</responseblock>
Field specification
Handling the response
The settlestatus returned in the AUTH response is used to determine the status of the MyBank payment:

If the settlestatus is “10”, the payment is pending settlement.
- The funds have not yet been settled into your bank account.
- The next step is to redirect the customer’s browser to the redirecturl to complete the payment.
Funds will not be settled into your account until the customer is redirected to MyBank’s pages, in order to complete the payment. Read on for further information.
- When there is an update to the settle status of the AUTH, you will receive a URL notification to inform you that the settlestatus has been updated to either “3” or “100”.
- Further information on the notifications can be found below.

If the settlestatus is “3”, the payment has been cancelled.
- The payment has been declined, or has encountered an error.
- To learn more about why the payment was unsuccessful, you will need to look at the errorcode. e.g. “70000” indicates that the payment was declined. Click here for a full list of error codes.
In addition to the above, we also recommend following our Best practices.
2. Redirect to MyBank
Your system will need to redirect the customer’s browser to the redirecturl, which is a page hosted by MyBank, in order to process the payment. At a later time, the customer will be redirected back to either the successfulurlredirect or the errorurlredirect provided in the AUTH request.

If the customer is redirected to the successfulurlredirect:
The customer successfully completed the required steps on MyBank’s pages.
Recommended actions: Display confirmation that the payment was successful.

If the customer is redirected to the errorurlredirect:
The customer encountered a problem that has prevented them from completing the payment.
Recommended actions: Inform the customer that there was a problem with the payment, displaying sufficient transaction details for the customer to query the payment attempt.

When testing, you will be displayed the sandbox as provided by MyBank. To complete a test transaction, you will need to follow the instructions displayed on screen. Please contact your account manager for test credentials to enter while on the sandbox.
3. Payment completion
Once the customer returns from the MyBank hosted page to either the successfulurlredirect or errorurlredirect hosted on your site, you will need to display either a confirmation or error message respectively.

The settlement process for MyBank differs from the standard process followed with card-based payment methods.
Once a payment has been authorised, funds will be settled at a later time, as determined by MyBank.

The settlement notification may not be sent immediately after processing the AUTH.
In the unlikely event that payment is still pending settlement after 7 days (settlestatus “10”), this will be scheduled for investigation and we will contact you with further information.
Before you begin testing, we recommend that you contact our Support team and request that rules are enabled on your account, which submit URL notifications to your system in the following scenarios:
- When a payment is authorised.
- When funds have been settled.
Configuring the authorisation notification
We recommend including at least the following fields in your authorisation notification:
- Acquirer Response Message (acquirerresponsemessage)
- Base Amount (baseamount) (e.g. £10.50 is “1050”)*
- Main Amount (mainamount) (e.g. £10.50 is “10.50”)*
- Billing Country (billingcountryiso2a)
- Currency (currencyiso3a)
- Error Code (errorcode)
- Live Status (livestatus)
- Order Reference (orderreference)
- Payment Type (paymenttypedescription)
- Request Type (requesttypedescription)
- Settle Status (settlestatus)
- Site Reference (sitereference)
- Transaction Reference (transactionreference)
- Transaction Started Timestamp (transactionstartedtimestamp)
*Please choose your preferred format.
Configuring the settlement notification
We recommend including the following fields in your settlement notification:
- Settle Status (settlestatus)
- Site Reference (sitereference)
- Transaction Reference (transactionreference)
Check the notification
You will need to check the contents of each notification received and respond accordingly by following the processes outlined in the “URL notifications” section of our Action types page. In particular, you will need to look at the updated settlestatus value:
- On authorisation: If the settlestatus is “0”, “1” or “10”, the payment has been authorised and you are not required to take further action at this time. However, values of “2” or “3” indicate funds are not scheduled for settlement (suspended and cancelled, respectively).
- On settlement: If the settlestatus has been updated to “100”, this indicates that the funds have been settled. Alternatively, if this has been updated to “3”, this indicates there has been a problem and the payment was subsequently cancelled.

Cancelled transactions (
settlestatus “3”) may be settled at a later time. In situations where the customer has completed the steps required to fulfil the payment, the
settlestatus is updated to “100” to indicate the funds have been transferred to your account.
If you have contacted the Support Team to configure settlement notifications (as described above), you will be notified when this occurs.
Testing
You will need to test your solution before you can begin processing live payments. Test transactions are processed through your test Site Reference.

Requirements
You will need to contact our Support team, providing your MyBank test account details. We will then configure your test site reference to connect directly to the MyBank testing environment.
When performing test transactions, the redirect URL returned in the AUTH response will redirect your browser to the MyBank testing environment to simulate a payment. Other than this, the process will be exactly the same as processing live payments.
Refunds
After processing a payment with MyBank, it is possible to pay the customer back by submitting a REFUND request.

Refunds for MyBank are settled immediately (settlestatus “100”).
Requirements
- You cannot refund a payment until the AUTH has been settled (settlestatus is “100”).
- You cannot refund a greater amount than was originally settled.
- Partial refunds are not supported for MyBank payments.
The REFUND request and response for MyBank payments follow the same field specification as outlined in our standard REFUND documentation. Click here for further information.
Use the credentials provided on this page to test your solution.
When you sign up, you will be provided with a “live” account and a “test” account (the latter is prefixed with “test_”).
When testing, ensure requests submitted to Trust Payments reference your test sitereference.

It is important to thoroughly test your integration using your test sitereference before processing live payments.

Before you begin testing…
Please be aware of the following notes:
- Most fields submitted to our test system will be accepted. Any data breaching its defined specification will return an error message.
- Any test data that generates a successful response when submitted while a merchant is in test mode, will produce a declined response when a merchant is switched into live mode. In some cases, the test data may return an error response.
- Our test system attempts to simulate responses in a similar fashion to the live system. However, depending on your acquirer you may find some responses differ slightly from those given by the test system.
- In the interest of security, we recommend against using real payment details when using your test account.
- We recommend specifying the main amount “10.50” when testing. Other amounts can be used but may return unexpected responses.
- For those using Payment Pages, if you’re unsure where to start with your testing, you may find this resource helpful.
Test card details
The table below lists test card numbers and customer information that can be submitted to our test bank, along with the responses that should be expected in return.

Do not use these credentials when processing transactions on your live site reference.

While testing, all card types are supported, but when using your live account, you will receive an error if you do not have a valid merchant number for the payment type submitted.
- A baseamount of 70000 (£700.00) will always return a declined response from the test bank.
- A baseamount of 60010 (£600.10) will always return a bank system error from the test bank.
- Using baseamount 1050 (£10.50) will not generate an error.
3-D Secure v2
The following payment credentials can be used for testing 3-D Secure v2 (a form of SCA):
(3DSv2) Test Case 1: Successful Frictionless 3-D Secure Authentication & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001007 |
THREEDQUERY
Enrolled: Y
Status: Y
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001002 |
JCB |
3337000000000008 |
MASTERCARD |
5200000000001005 |
VISA (3-D Secure v2.1.0) |
4000000000001000 |
VISA (3-D Secure v2.2.0) |
4000000000002701 |
(3DSv2) Test Case 2: Failed Frictionless 3-D Secure Authentication & Failed Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001015 |
THREEDQUERY
Enrolled: Y
Status: N
AUTH
Error code: 60022 – Unauthenticated |
DINERS / DISCOVER |
6011000000001010 |
JCB |
3337000000000990 |
MASTERCARD |
5200000000001013 |
VISA (3-D Secure v2.1.0) |
4000000000001018 |
VISA (3-D Secure v2.2.0) |
4000000000002925 |
(3DSv2) Test Case 3: Attempts Stand-In Frictionless 3-D Secure Authentication & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001023 |
THREEDQUERY
Enrolled: Y
Status: A
AUTH
Error code: 0 -Ok |
DINERS / DISCOVER |
6011000000001028 |
JCB |
3337000000007045 |
MASTERCARD |
5200000000001021 |
VISA (3-D Secure v2.1.0) |
4000000000001026 |
VISA (3-D Secure v2.2.0) |
4000000000002719 |
(3DSv2) Test Case 4: Unavailable Frictionless 3-D Secure Authentication from the Issuer & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001031 |
THREEDQUERY
Enrolled: Y
Status: U
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001036 |
JCB |
3337000000000735 |
MASTERCARD |
5200000000001039 |
VISA (3-D Secure v2.1.0) |
4000000000001034 |
VISA (3-D Secure v2.2.0) |
4000000000002313 |
(3DSv2) Test Case 5: Rejected Frictionless 3-D Secure Authentication by the Issuer & Failed Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001049 |
THREEDQUERY
Enrolled: Y
Status: R
AUTH
Error code: 60022 – Unauthenticated |
DINERS / DISCOVER |
6011000000001044 |
JCB |
3337000000000321 |
MASTERCARD |
5200000000001047 |
VISA (3-D Secure v2.1.0) |
4000000000001042 |
VISA (3-D Secure v2.2.0) |
4000000000002537 |
(3DSv2) Test Case 6: 3-D Secure Authentication Not Available on Lookup & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001056 |
THREEDQUERY
Enrolled: U
Status: None
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001051 |
JCB |
3337000000006765 |
MASTERCARD |
5200000000001054 |
VISA (3-D Secure v2.1.0) |
4000000000001059 |
VISA (3-D Secure v2.2.0) |
4000000000002990 |
(3DSv2) Test Case 7: Error on Lookup & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001064 |
THREEDQUERY
Enrolled: U
Status: None
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001069 |
JCB |
3337000000000016 |
MASTERCARD |
5200000000001062 |
VISA (3-D Secure v2.1.0) |
4000000000001067 |
VISA (3-D Secure v2.2.0) |
4000000000002446 |
(3DSv2) Test Case 8: Timeout on cmpi_lookup Transaction & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001072 |
THREEDQUERY
Enrolled: U
Status: None
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001077 |
JCB |
3337000000000081 |
MASTERCARD |
5200000000001070 |
VISA (3-D Secure v2.1.0) |
4000000000001075 |
VISA (3-D Secure v2.2.0) |
4000000000002354 |
(3DSv2) Test Case 9: Successful Step Up 3-D Secure Authentication & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001098 |
THREEDQUERY
Enrolled: Y
Status: C
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001093 |
JCB |
3337000000200004 |
MASTERCARD |
5200000000001096 |
VISA (3-D Secure v2.1.0) |
4000000000001091 |
VISA (3-D Secure v2.2.0) |
4000000000002503 |
(3DSv2) Test Case 10: Failed Step Up 3-D Secure Authentication & No Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001106 |
THREEDQUERY
Enrolled: Y
Status: C
AUTH
Not performed |
DINERS / DISCOVER |
6011000000001101 |
JCB |
3337000000200087 |
MASTERCARD |
5200000000001104 |
VISA (3-D Secure v2.1.0) |
4000000000001109 |
VISA (3-D Secure v2.2.0) |
4000000000002370 |
(3DSv2) Test Case 11: Step Up 3-D Secure Authentication is Unavailable & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001114 |
THREEDQUERY
Enrolled: Y
Status: C
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001119 |
JCB |
3337000000200079 |
MASTERCARD |
5200000000001112 |
VISA (3-D Secure v2.1.0) |
4000000000001117 |
VISA (3-D Secure v2.2.0) |
4000000000002420 |
(3DSv2) Test Case 12: Error on 3-D Secure Authentication & No Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001122 |
THREEDQUERY
Enrolled: Y
Status: C
AUTH
Not performed |
DINERS / DISCOVER |
6011000000001127 |
JCB |
3337000000200046 |
MASTERCARD |
5200000000001120 |
VISA (3-D Secure v2.1.0) |
4000000000001125 |
VISA (3-D Secure v2.2.0) |
4000000000002644 |
(3DSv2) Test Case 13: Bypassed 3-D Secure Authentication & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000001080 |
THREEDQUERY
Enrolled: B
Status: None
AUTH
Error code: 0 – Ok |
DINERS / DISCOVER |
6011000000001085 |
JCB |
3337000000000537 |
MASTERCARD |
5200000000001088 |
VISA (3-D Secure v2.1.0) |
4000000000001083 |
VISA (3-D Secure v2.2.0) |
4000000000002560 |
3-D Secure v1
The following payment credentials can be used for testing 3-D Secure v1 (a form of SCA):
(3DSv1) Test Case 1: Successful 3-D Secure Authentication & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000003961 |
THREEDQUERY
Enrolled: Y
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3005000000006246 |
DISCOVER |
6011000000000004 |
JCB |
3520000000000922 |
MASTERCARD |
5200000000000007 |
VISA |
4000000000000002 |
(3DSv1) Test Case 2: Failed Signature & No Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000006022 |
THREEDQUERY
Enrolled: Y
Status: None
AUTH
Not performed |
DINERS |
3005000000004373 |
DISCOVER |
6011000000000012 |
JCB |
3520000000002811 |
MASTERCARD |
5200000000000015 |
VISA |
4000000000000010 |
(3DSv1) Test Case 3: Failed Authentication & No Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000000033 |
THREEDQUERY
Enrolled: Y
Status: None
AUTH
Not performed |
DINERS |
3005000000005925 |
DISCOVER |
6011000000000020 |
JCB |
3520000000009931 |
MASTERCARD |
5200000000000023 |
VISA |
4000000000000028 |
(3DSv1) Test Case 4: Attempts/Non-Participating & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000003391 |
THREEDQUERY
Enrolled: Y
Status: A
AUTH
Error code: 0 – Ok |
DINERS |
3005000000005271 |
DISCOVER |
6011000000000038 |
JCB |
3520000000004767 |
MASTERCARD |
5200000000000908 |
VISA |
4000000000000101 |
(3DSv1) Test Case 6: Not Enrolled & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000008135 |
THREEDQUERY
Enrolled: N
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3005000000007269 |
DISCOVER |
6011000000000053 |
JCB |
3520000000006903 |
MASTERCARD |
5200000000000056 |
VISA |
4000000000000051 |
(3DSv1) Test Case 7: Unavailable & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000007780 |
THREEDQUERY
Enrolled: U
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3005000000006030 |
DISCOVER |
6011000000000061 |
JCB |
3520000000002423 |
MASTERCARD |
5200000000000064 |
VISA |
4000000000000069 |
(3DSv1) Test Case 8: Merchant Not Active & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000008416 |
THREEDQUERY
Enrolled: U
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3005000000004837 |
DISCOVER |
6011000000000079 |
JCB |
3520000000006549 |
MASTERCARD |
5200000000000072 |
VISA |
4000000000000077 |
(3DSv1) Test Case 9: cmpi_lookup error & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000006337 |
THREEDQUERY
Enrolled: U
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3005000000009877 |
DISCOVER |
6011000000000087 |
JCB |
3520000000002175 |
MASTERCARD |
5200000000000080 |
VISA |
4000000000000085 |
(3DSv1) Test Case 10: cmpi_authenticate error & No Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000009299 |
THREEDQUERY
Enrolled: Y
Status: None
AUTH
Not performed |
DINERS |
3005000000005602 |
DISCOVER |
6011000000000095 |
JCB |
3520000000006861 |
MASTERCARD |
5200000000000098 |
VISA |
4000000000000093 |
(3DSv1) Test Case 11: Authentication Unavailable & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340000000000116 |
THREEDQUERY
Enrolled: Y
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3005000000007376 |
DISCOVER |
6011000000000103 |
JCB |
3520000000005780 |
MASTERCARD |
5200000000000031 |
VISA |
4000000000000036 |
(3DSv1) Test Case 12: Bypassed Authentication & Successful Authorisation
|
Card type |
PAN |
Handling the response |
AMEX |
340099000000001 |
THREEDQUERY
Enrolled: B
Status: None
AUTH
Error code: 0 – Ok |
DINERS |
3000990000000006 |
DISCOVER |
6011990000000006 |
JCB |
3500990000000001 |
MASTERCARD |
5200990000000009 |
VISA |
4000990000000004 |
3-D Secure status testing
To test for different 3-D Secure status values, follow the instructions displayed in the authentication prompt shown on the page (an example is shown below). In the textbox provided, you can enter different PIN values to test for different cases.

Displaying the test ACS page
For Payment Pages:
With 3-D Secure enabled on your site reference, process a payment using one of the card numbers listed above and your browser will display an authentication prompt with instructions.
For JavaScript Library implementations:
After your payment form has been updated to reference our JavaScript library, process a payment using one of the card numbers listed above and your browser will display an authentication prompt with instructions.
For Mobile SDK implementations:
After your Android or iOS app has been updated to utilise our Mobile SDK, process a payment using one of the card numbers listed above and your app will display an authentication prompt with instructions.
The authentication prompt will only be displayed for non-frictionless test card details.
Frictionless cards will bypass authentication. In this case, the payment will be processed immediately (without being prompted by the browser for information).
Follow the instructions displayed within the authentication prompt to complete the payment:


When the status is “N”, indicating the customer failed authentication, the errorcode “60022” will be returned.
Testing AVS and security code checks
If you haven’t already, please read our AVS and Security code documentation before testing:
Link to Payment Pages docs / Link to API docs
The following tables list test details that can be submitted to obtain different responses from the AVS and Security Code Checks. These details can be used with most major payment types.

Only the billing premise, billing postcode and security code field values dictate the outcome of the AVS and security code checks performed. As such, entering any details into the other address fields will not affect the outcome of these checks.
Premise
Billing premise |
Security response |
Security response caption |
No 789 |
2 |
Matched |
No 123 |
4 |
Not Matched |
No 333 |
1 |
Not Checked |
Leave blank |
0 |
Not Given |
Postcode / ZIP code
Billing postcode |
Security response |
Security response caption |
UK |
US |
TE45 6ST |
55555 |
2 |
Matched |
TE12 3ST |
12345 |
4 |
Not Matched |
TE33 3ST |
33333 |
1 |
Not Checked |
Leave blank |
Leave blank |
0 |
Not Given |
Security code
Security code |
AMEX security code |
Security response |
Security response
|
123 |
1234 |
2 |
Matched |
214 |
2144 |
4 |
Not Matched |
333 |
3333 |
1 |
Not Checked |
Leave blank |
Leave blank |
0 |
Not Given |
Testing non-card payment methods
Testing recurring payments
Testing for the acquirer advice code
When processing recurring payments, some acquirers may return an acquirer advice code in the response. The acquirer advice code is a numeric value used to indicate if further recurring payments can be processed for the given card.
Code |
Description |
Action |
0 |
N/A |
No action required |
1 |
New account information available (Mastercard only) |
Query customer for updated payment details |
2 |
Cannot approve at this time |
Try again later. If you are continuing to have difficulties, please contact your acquiring bank |
4 |
Do not try again |
Do not process further recurring transactions |
8 |
Payment blocked by card scheme |
Where to find the acquirer advice code
- This code is returned in your daily subscription email report.
- It’s viewable within MyST by selecting the additional field to be displayed on the transaction search page. It can also be viewed on the single transaction view.
- Additionally, for those who have processed a recurring AUTH transaction using the API, the code is returned in the acquireradvicecode field in the response.
How to test for different acquirer advice codes
You can test that your system responds appropriately to different acquirer advice codes by processing transactions with the following attributes:
Visa |
Acquirer advice code returned |
Card number |
Base amount |
0 |
4111111111111111 |
1050 |
2 |
4000000000000671 |
1002 |
4 |
4000000000000671 |
1004 |
8 |
4000000000000671 |
1008 |

Acquirer advice code ‘1’ can only be returned for recurring Mastercard transactions.
Mastercard |
Acquirer advice code returned |
Card number |
Base amount |
0 |
5100000000000511 |
1050 |
1 |
5100000000000271 |
1001 |
2 |
5100000000000271 |
1002 |
4 |
5100000000000271 |
1004 |
8 |
5100000000000271 |
1008 |
Testing Protect Plus
Please refer to the following resources when testing Protect Plus:
Testing DCC
Please refer to the following resources when testing DCC:

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.
The following documentation explains how to manually perform 3-D Secure using version 1 through our Webservices API.
The process described below only supports 3-D Secure version 1.
We recommend all merchants utilise 3-D Secure version 2 by using our JavaScript Library.
If you are already processing e-commerce payments using our JavaScript Library, you do not need to follow the process described below, as the JavaScript Library will handle the 3-D Secure process automatically.
3-D Secure is a protocol designed to reduce fraud and chargebacks during e-commerce transactions. It allows Mastercard and Visa card issuers to provide an extra level of protection, by authenticating the customer’s identity at the point of sale, sometimes by prompting for a previously-agreed PIN and/or password.

For a fully authenticated 3-D Secure transaction, in the event of a dispute at a later date the card issuer will usually take responsibility of the chargeback instead of the merchant. The liability issues involved with 3-D Secure transactions can be found in this
FAQ.
.
Process overview

Check customer enrolment
- Your system will need to send a THREEDQUERY request using our Webservices API (including the customer’s card details) and interpret the response returned.
- Trust Payments will check whether the customer’s card is enrolled in 3-D Secure.

Authenticate the customer
If the customer is enrolled in 3-D Secure, your system will need to redirect the customer to the card issuer’s server (ACS URL) and handle the customer being redirected to your server (Term URL).

Authorisation
Your system will need to send an AUTH request using our Webservices API and interpret the response returned.
1. Check customer enrolment
To determine whether or not the customer’s card is enrolled in the 3-D Secure scheme, you need to manually submit a THREEDQUERY request using our Webservices API.
THREEDQUERY Request
The following example demonstrates how to structure a THREEDQUERY request:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
threedquery= {
"termurl":"https://termurl.com",
"accept":"text/html,*/*",
"pan": "4111111111111111",
"expirydate": "12/2020",
"securitycode": "123",
"currencyiso3a":"GBP",
"requesttypedescriptions": ["THREEDQUERY"],
"accounttypedescription":"ECOM",
"sitereference": "test_site12345",
"baseamount": "1050"
}
strequest = securetrading.Request()
strequest.update(threedquery)
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(
'termurl' => 'https://termurl.com',
'accept' => 'text/html,*/*',
'pan' => '4111111111111111',
'expirydate' => '12/2020',
'securitycode' => '123',
'currencyiso3a' => 'GBP',
'requesttypedescriptions' => array('THREEDQUERY'),
'accounttypedescription' => 'ECOM',
'sitereference' => 'test_site12345',
'baseamount' => '1050'
);
$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": [{
"termurl":"https://termurl.com",
"accept":"text/html,*/*",
"pan": "4111111111111111",
"expirydate": "12/2020",
"securitycode": "123",
"currencyiso3a":"GBP",
"requesttypedescriptions": ["THREEDQUERY"],
"accounttypedescription":"ECOM",
"sitereference": "test_site12345",
"baseamount": "1050"
}]}'
Here is the specification of the fields included in the THREEDQUERY request described above:

When reading the field specifications included on this page, please ensure that you reference the relevant code examples for your chosen language.
Key


THREEDQUERY Response
This section documents how to interpret a THREEDQUERY response, which is used to indicate whether or not the customer’s card is enrolled in the card issuer’s 3-D Secure scheme.

The acsurl, md and pareq fields are only returned in a THREEDQUERY response for enrolled cards.
The example below demonstrates the structure of a THREEDQUERY response, indicating that the customer’s card is enrolled in a 3-D Secure scheme:
{
u 'requestreference': u 'Aw5mpjtv6',
u 'version': u '1.00',
u 'response': [{
u 'transactionstartedtimestamp': u '2016-12-07 16:55:47',
u 'livestatus': u '0',
u 'issuer': u 'SecureTrading Test Issuer1',
u 'xid': u 'amh1OCtINGpuemJaVmQreU5YT2Y=',
u 'pareq': u 'eJxVUmFPw9C12xiQowlCopiIqGji5Yqj25lPCwOutoQKHZzxqOQgF5soqzk=',
u 'dccenabled': u '0',
u 'settleduedate': u '2016-12-07',
u 'errorcode': u '0',
u 'threedversion': u '1.0.2',
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 'acsurl': u 'https://webapp.securetrading.net/acs/visa.cgi',
u 'accounttypedescription': u 'ECOM',
u 'requesttypedescription': u 'THREEDQUERY',
u 'md': u 'UEZOVVBqeE5SRDQ4VFVSSVBucE9abUp5WWtTlDR0NLaFVSZUV5aStFPQ==',
u 'maskedpan': u '411111######0211',
u 'errormessage': u 'Ok',
u 'operatorname': u '[email protected]',
u 'enrolled': u 'Y',
u 'issuercountryiso2a': u 'US',
u 'settlestatus': u '0'
}]
}
array(3) {
["requestreference"] => string(9) "A2cjnruwy"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(25) {
["transactionstartedtimestamp"] => string(19) "2016-12-09 11:25:36"
["livestatus"] => string(1) "0"
["issuer"] => string(26) "SecureTrading Test Issuer1"
["xid"] => string(28) "ZlcyU1hQcUhmaEtzd2I1SmkrMnM="
["pareq"] => string(27) "eJxVUstuwjAQ/BXEHZxjoOrXA=="
["dccenabled"] => string(1) "0"
["settleduedate"] => string(10) "2016-12-09"
["errorcode"] => string(1) "0"
["threedversion"] => string(5) "1.0.2"
["tid"] => string(8) 27882788"
["merchantnumber"] => string(8) "00000000"
["merchantcountryiso2a"] => string(2) "GB"
["transactionreference"] => string(10) "1-2-345678"
["merchantname"] => string(13) "Test Merchant"
["paymenttypedescription"] => string(4) "VISA"
["acsurl"] => string(45) "https://webapp.securetrading.net/acs/visa.cgi"
["accounttypedescription"] => string(4) "ECOM"
["requesttypedescription"] => string(11) "THREEDQUERY"
["md"] => string(72) "UEZOVVBqeVQand2VTFRKzptZGY2RXZXOGQrS2V5Tko5cEk9"
["maskedpan"] => string(16) "411111######0211"
["errormessage"] => string(2) "Ok"
["operatorname"] => string(23) "[email protected]"
["enrolled"] => string(1) "Y"
["issuercountryiso2a"] => string(2) "US"
["settlestatus"] => string(1) "0"
}
}
}
{"requestreference":"W23-08yvq0db","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 16:57:44","livestatus":"0","issuer":"SecureTrading Test Issuer1","xid":"KzRLRmhSUEZ0OWZJSkJIMDU1dDk=","pareq":"eJxVUu9PwjAQ\/NtY9ts6tP8Ac1Rqq+","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","threedversion":"1.0.2","tid":"27882788","merchantnumber":"00000000","merchantcountryiso2a":"GB","transactionreference":"1-2-345678","merchantname":"Test Merchant","paymenttypedescription":"VISA","acsurl":"https:\/\/webapp.securetrading.net\/acs\/visa.cgi","accounttypedescription":"ECOM","requesttypedescription":"THREEDQUERY","md":"UEZOVVBqeE5SRD06bWRzS1dBbnFZY01JRjEwZGOWhrPQ==","maskedpan":"411111######0211","errormessage":"Ok","operatorname":"[email protected]","enrolled":"Y","issuercountryiso2a":"US","settlestatus":"0"}],"secrand":"0gqEPDTnCWlvTr6G"}

The md and pareq typically contain values far longer than displayed in the example above and therefore have been abbreviated, for your convenience.
Check the error code field value
If the errorcode value returned in the response is not ‘0’, an error has occurred. If an errorcode other than ‘0’ is returned, please consult the table below and attempt to resolve the issue:
Error code |
Description |
0 |
Request was successful. |
30000 |
Invalid field. |
60031 |
The THREEDQUERY request used a payment type that is not supported by Trust Payments 3-D Secure. |
other |
Other errors will require further investigation. Click here for a full list of possible error codes. |
If you were unable to resolve the issue, you can instruct your system to perform a standard AUTH without using 3-D Secure.

When performing an AUTH request without 3-D Secure, this will result in forfeiting the liability shift.
Check the enrolled field value
If the enrolled value returned in the response is “Y”, the customer’s card is enrolled in 3-D secure. Please refer to the following table for enrolled values:
Enrolled |
Description |
Action |
Y |
The card is enrolled in the card issuer’s 3-D Secure scheme. |
Send the customer to the card issuer’s Access Control Server (ACS). The URL for the ACS is provided in the acsurl of the THREEDQUERY response. |
N |
The card is not enrolled in the card issuer’s 3-D Secure scheme. |
Perform an AUTH Request, including the transactionreference returned in the THREEDQUERY response (example can be found below). |
U |
The card’s enrolment in the card issuer’s 3-D Secure scheme could not be determined. |
This typically indicates a temporary problem with the card issuer’s systems. You can configure your system to resubmit the same THREEDQUERY request. If this continues to fail, submit a standard AUTH request using our Webservices API, including the transactionreference returned in the THREEDQUERY response. |
Here is the specification of the fields included in the THREEDQUERY response described above:
Key



Your progress
Following the instructions above, your system should now be able to determine whether or not a customer’s card is enrolled in a 3-D Secure scheme. If the customer’s card is enrolled, follow the “Authenticate the customer” section below, otherwise skip ahead to the “Authorisation” section.
2. Authenticate the customer

Only attempt to authenticate the customer if their card is confirmed to be enrolled in a 3-D Secure scheme.
If the card is not enrolled, skip ahead to the “Authorisation” section.
If the customer is enrolled in the card issuer’s 3-D Secure scheme, your system must send the customer’s browser to the card issuer-hosted Access Control Server (ACS) using an HTTPS POST. The URL for the ACS can be found in the acsurl field of the THREEDQUERY response.
On the ACS, the customer will be authenticated, sometimes by prompting for a previously-agreed PIN and/or password. The browser must send data from the termurl, pareq and md in HTML fields ‘TermUrl’, ‘PaReq’ and ‘MD’, respectively (These field names are case sensitive).

The size of the ACS page displayed in the customer’s browser is controlled by the ACS provider (cannot be modified by merchants or Trust Payments). As a guideline,
Visa and
Mastercard both state that the Verified by Visa authentication window should be
390×400 pixels in size
Following authentication, the customer will be returned to your servers using an HTTPS POST. You will need to parse this response, as it will contain the ‘PaRes’ and ‘MD’ fields, for constructing the subsequent AUTH Request needed to process the payment.

When the customer’s browser is redirected to your server from the ACS, please be aware that some ACS will also include a field called “realPan”, which contains the customer’s card number in plain text. It is imperative that you do not store the value of realPan on your own server.
The following is an example of how to redirect the cardholder to the card issuer’s ACS :
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01//EN'>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<title>Processing payment</title>
<style type="text/css">
h3,h3,h4 { font-family: verdana, arial, sans-serif;
font-weight: normal;}
#logo {float: left;}
</style>
</head>
<body OnLoad="document.form.submit();" >
<form name="form" id="form" action="$acsurl" method="POST">
<div>
<input type="hidden" name="PaReq" value="$pareq" />
<input type="hidden" name="TermUrl" value="$termurl" />
<input type="hidden" name="MD" value="$md" />
</div>
<noscript>
<div>
<h3>JavaScript is currently disabled or is not supported by your browser.</h3>
<h4>Please click Submit to continue processing your 3-D Secure transaction.</h4>
<input type="submit" value="Submit">
</div>
</noscript>
</form>
</body>
</html>
Referencing 3-D Secure transactions
In most circumstances, your system will need to store data about the transaction in your database while the customer is being authenticated on the card issuer’s ACS, to be retrieved when the customer returns to your system via the termurl. As the 3-D Secure specification requires that only the md and pares fields are returned to your system, it is recommended that the md field is used to look up any corresponding customer session to complete the transaction.
Waiting for the customer to return from the ACS
Your system will need to consider the length of time it may take for the customer to enter their details on the card issuer’s ACS. The time the customer will spend on the ACS will depend on a number of factors. Longer wait times may occur when the customer is signing up to a 3-D Secure scheme for the first time, or recovering a forgotten password. While your system needs to allow time for the customer to return, it is entirely possible for the customer to close their browser on the card issuer’s ACS and not return at all. There are no specific regulations as to how long your system must wait for the customer to be redirected from the ACS to your Term URL, but we recommend waiting for no more than two hours.

Your progress
Following the instructions above, your system should now be able to redirect the browsers of customers with cards enrolled in a 3-D Secure scheme to the ACS for authentication. Your system can now proceed and submit an AUTH request using our Webservices API to process the payment, by following the instructions below.
3. Authorisation
3-D authorisations are used to seek authorisation for authenticated transactions from your acquiring bank. This is performed by manually submitting an AUTH Request using our Webservices API and interpreting the response returned.
AUTH Request
For enrolled cards only
The following example demonstrates how to structure a 3-D AUTH request when the card is enrolled in a 3-D Secure scheme:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
auth= {
"requesttypedescriptions": ["AUTH"],
"md":"UEZOVVBqeE5SRDQ4VFVSSVBrRjVXSGhOZFZReVUzVlalBVeE",
"pares":"eJzVWFmzosgSfudXdPQ8Gt1sbkzYRhQ7KCjI/sYOsimgoL/+lp7Tp5"
}
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(
'requesttypedescriptions' => array('AUTH'),
'md' => 'UEZOVVBqeE5SRDQ4VFVSSVBtSllOVTlMYVdaUlJXWnZVRTA0UVdwVlJXZFpRo5cEk9',
'pares' => 'eJztWEnTqsi2nfMrKqqGxik6UajwJFCOxLb5BNvgHdPneIihB/fq2eNv777/BdaScGg='
);
$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": [{
"requesttypedescriptions": ["AUTH"],
"md":"UEZOVVBqeE5SRDVS1FLVG9aenQrRGhaNk1NPQ==",
"pares":"eJztWMmyq7iynfMVFVVDxyk6Y0OX0U1wTQ=="
}]}'

The md and pares fields typically contain values far longer than displayed in the example above and therefore have been abbreviated for your convenience. When submitting these fields, your system must submit their full values, unmodified.
For non-enrolled cards only
For cards that are NOT enrolled in the card issuer’s 3-D Secure scheme (or have unknown enrolment), you will need to submit the following fields in order to inherit transaction information needed to perform the authorisation:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
auth= {
"requesttypedescriptions": ["AUTH"],
"sitereference": "test_site12345",
"parenttransactionreference": "1-2-345678"
}
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(
'requesttypedescriptions' => array('AUTH'),
'sitereference' => 'test_site12345',
'parenttransactionreference' => '1-2-345678'
);
$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": [{
"requesttypedescriptions": ["AUTH"],
"sitereference": "test_site12345",
"parenttransactionreference": "1-2-345678"
}]}'
Inheritance
The example AUTH requests shown above (both enrolled and not-enrolled) contain all the fields that are required for submission. All other information required to seek authorisation will be inherited from the previous THREEDQUERY request stored on our system.
We allow the submission of additional fields in the AUTH request that have not been submitted in the THREEDQUERY request (e.g. the customer name, if omitted in the query).
Click here for a full list of fields that can be submitted in an AUTH request.
Here is the specification of the fields included in the AUTH requests described above:
Key


Field name |
Type |
Length |
Request |
Description |
pares |
Alphanumeric including symbols |
1024 |
 |
Only send if card is enrolled.
Must be the value returned in the pares field of the HTTPS POST from the card issuer’s ACS, otherwise this may forfeit the liability shift. |
md |
Alphanumeric including symbols |
65536 |
 |
Only send if card is enrolled.
The unique 3-D Secure reference for this transaction. Supplied if enrolled is “Y” |
parenttransactionreference |
Alphanumeric including hyphens |
25 |
 |
Only send if card is NOT enrolled.
Unique reference of the parent THREEDQUERY request. |
sitereference |
Alphanumeric including underscore |
50 |
 |
Only send if card is NOT enrolled.
The site reference processing the transaction. |
AUTH Response
The data returned in the AUTH response will depend on both the card enrollment status, and whether or not the customer was successfully authenticated on the card issuer’s ACS.
Your system should be able to interpret the response data in each of the following scenarios.
Enrolled and authenticated
{
u 'requestreference': u 'Av87m7xq9',
u 'version': u '1.00',
u 'response': [{
u 'transactionstartedtimestamp': u '2016-12-08 08:34:48',
u 'parenttransactionreference': u '1-2-345678',
u 'livestatus': u '0',
u 'issuer': u 'SecureTrading Test Issuer1',
u 'splitfinalnumber': u '1',
u 'xid': u 'amh1OCtINGpuemJaVmQreU5YT2Y=',
u 'dccenabled': u '0',
u 'settleduedate': u '2016-12-07',
u 'errorcode': u '0',
u 'cavv': u 'Q0FWVkNBVlZDQVZWQ0FWVkNBVlY=',
u 'merchantnumber': u '00000000',
u 'merchantcountryiso2a': u 'GB',
u 'status': u 'Y',
u 'transactionreference': u '1-2-345679',
u 'merchantname': u 'Test Merchant',
u 'paymenttypedescription': u 'VISA',
u 'baseamount': u '1050',
u 'eci': u '05',
u 'accounttypedescription': u 'ECOM',
u 'tid': u '27882788',
u 'acquirerresponsecode': u '00',
u 'requesttypedescription': u 'AUTH',
u 'securityresponsesecuritycode': u '2',
u 'currencyiso3a': u 'GBP',
u 'authcode': u 'TEST40',
u 'errormessage': u 'Ok',
u 'operatorname': u '[email protected]',
u 'maskedpan': u '411111######0211',
u 'securityresponsepostcode': u '0',
u 'enrolled': u 'Y',
u 'securityresponseaddress': u '0',
u 'issuercountryiso2a': u 'US',
u 'settlestatus': u '0'
}]
}
array(3) {
["requestreference"] => string(9) "A278afgrx"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(33) {
["transactionstartedtimestamp"] => string(19) "2016-12-09 11:46:34"
["parenttransactionreference"] => string(10) "1-2-345678"
["livestatus"] => string(1) "0"
["issuer"] => string(26) "SecureTrading Test Issuer1"
["splitfinalnumber"] => string(1) "1"
["xid"] => string(28) "ZlcyU1hQcUhmaEtzd2I1SmkrMnM="
["dccenabled"] => string(1) "0"
["settleduedate"] => string(10) "2016-12-09"
["errorcode"] => string(1) "0"
["tid"] => string(8) "27882788"
["merchantnumber"] => string(8) "00000000"
["merchantcountryiso2a"] => string(2) "GB"
["status"] => string(1) "Y"
["transactionreference"] => string(10) "1-2-345679"
["merchantname"] => string(13) "Test Merchant"
["paymenttypedescription"] => string(4) "VISA"
["baseamount"] => string(4) "1050"
["enrolled"] => string(1) "Y"
["eci"] => string(2) "05"
["accounttypedescription"] => string(4) "ECOM"
["cavv"] => string(28) "Q0FWVkNBVlZDQVZWQ0FWVkNBVlY="
["acquirerresponsecode"] => string(2) "00"
["requesttypedescription"] => string(4) "AUTH"
["securityresponsesecuritycode"] => string(1) "2"
["currencyiso3a"] => string(3) "GBP"
["authcode"] => string(6) "TEST30"
["errormessage"] => string(2) "Ok"
["operatorname"] => string(23) "[email protected]"
["securityresponsepostcode"] => string(1) "0"
["maskedpan"] => string(16) "411111######0211"
["securityresponseaddress"] => string(1) "0"
["issuercountryiso2a"] => string(2) "US"
["settlestatus"] => string(1) "0"
}
}
}
{"requestreference":"W23-n68rw97k","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 17:21:59","parenttransactionreference":"1-2-345678","livestatus":"0","issuer":"SecureTrading Test Issuer1","splitfinalnumber":"1","xid":"ZldiREFPMW5HYi90UDhxMDJTV2Q=","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","tid":"27882788","merchantnumber":"00000000","merchantcountryiso2a":"GB","status":"Y","transactionreference":"1-2-345679","merchantname":"Test Merchant","paymenttypedescription":"VISA","baseamount":"1050","enrolled":"Y","eci":"05","accounttypedescription":"ECOM","cavv":"Q0FWVkNBVlZDQVZWQ0FWVkNBVlY=","acquirerresponsecode":"00","requesttypedescription":"AUTH","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST05","errormessage":"Ok","operatorname":"[email protected]","securityresponsepostcode":"0","maskedpan":"411111######0211","securityresponseaddress":"0","issuercountryiso2a":"US","settlestatus":"0"}],"secrand":"bsZP"}
Enrolled but NOT authenticated
{
u 'requestreference': u 'Aq2qmp0j3',
u 'version': u '1.00',
u 'response': [{
u 'transactionstartedtimestamp': u '2016-12-13 11:11:58',
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-13',
u 'errorcode': u '60022',
u 'tid': u '27882788',
u 'merchantnumber': u '00000000',
u 'merchantcountryiso2a': u 'GB',
u 'status': u 'N',
u 'transactionreference': u '1-2-345679',
u 'merchantname': u 'Test Merchant',
u 'paymenttypedescription': u 'VISA',
u 'baseamount': u '1050',
u 'accounttypedescription': u 'ECOM',
u 'requesttypedescription': u 'AUTH',
u 'currencyiso3a': u 'GBP',
u 'maskedpan': u '411111######0211',
u 'errormessage': u 'Unauthenticated',
u 'operatorname': u '[email protected]',
u 'enrolled': u 'Y',
u 'issuercountryiso2a': u 'US',
u 'settlestatus': u '3'
}]
}
array(3) {
["requestreference"] => string(9) "A35ahjnwx"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(25) {
["transactionstartedtimestamp"] => string(19) "2016-12-13 10:41:57"
["parenttransactionreference"] => string(10) "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-13"
["errorcode"] => string(5) "60022"
["tid"] => string(8) "27882788"
["merchantnumber"] => string(8) "00000000"
["merchantcountryiso2a"] => string(2) "GB"
["status"] => string(1) "N"
["transactionreference"] => string(10) "1-2-345679"
["merchantname"] => string(13) "Test Merchant"
["paymenttypedescription"] => string(4) "VISA"
["baseamount"] => string(3) "1050"
["accounttypedescription"] => string(4) "ECOM"
["requesttypedescription"] => string(4) "AUTH"
["currencyiso3a"] => string(3) "GBP"
["maskedpan"] => string(16) "411111######0211"
["errormessage"] => string(15) "Unauthenticated"
["operatorname"] => string(23) "[email protected]"
["enrolled"] => string(1) "Y"
["issuercountryiso2a"] => string(2) "US"
["settlestatus"] => string(1) "3"
}
}
}
{
"requestreference": "W23-mjuwx1f5",
"version": "1.00",
"response": [{
"transactionstartedtimestamp": "2016-12-13 11:00:44",
"parenttransactionreference": "1-2-345678",
"livestatus": "0",
"issuer": "SecureTrading Test Issuer1",
"splitfinalnumber": "1",
"dccenabled": "0",
"settleduedate": "2016-12-13",
"errorcode": "60022",
"tid": "27882788",
"merchantnumber": "00000000",
"merchantcountryiso2a": "GB",
"status": "N",
"transactionreference": "1-2-345679",
"merchantname": "Test Merchant",
"paymenttypedescription": "VISA",
"baseamount": "1050",
"accounttypedescription": "ECOM",
"requesttypedescription": "AUTH",
"currencyiso3a": "GBP",
"maskedpan": "411111######0211",
"errormessage": "Unauthenticated",
"operatorname": "[email protected]",
"enrolled": "Y",
"issuercountryiso2a": "US",
"settlestatus": "3"
}],
"secrand": "3J"
Not enrolled
{
u 'requestreference': u 'Adyw3fdbw',
u 'version': u '1.00',
u 'response': [{
u 'transactionstartedtimestamp': u '2016-12-07 16:47:39',
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 '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 '1050',
u 'accounttypedescription': u 'ECOM',
u 'acquirerresponsecode': u '00',
u 'requesttypedescription': u 'AUTH',
u 'securityresponsesecuritycode': u '2',
u 'currencyiso3a': u 'GBP',
u 'authcode': u 'TEST23',
u 'errormessage': u 'Ok',
u 'operatorname': u '[email protected]',
u 'maskedpan': u '411111######0021',
u 'securityresponsepostcode': u '0',
u 'enrolled': u 'N',
u 'securityresponseaddress': u '0',
u 'issuercountryiso2a': u 'US',
u 'settlestatus': u '0'
}]
}
array(3) {
["requestreference"] => string(9) "A256agnuw"
["version"] => string(4) "1.00"
["response"] => array(1) {
[0] => array(29) {
["transactionstartedtimestamp"] => string(19) "2016-12-09 11:53:36"
["parenttransactionreference"] => string(10) "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"
["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) "1050"
["enrolled"] => string(1) "N"
["accounttypedescription"] => string(4) "ECOM"
["acquirerresponsecode"] => string(2) "00"
["requesttypedescription"] => string(4) "AUTH"
["securityresponsesecuritycode"] => string(1) "2"
["currencyiso3a"] => string(3) "GBP"
["authcode"] => string(6) "TEST08"
["errormessage"] => string(2) "Ok"
["operatorname"] => string(23) "[email protected]"
["securityresponsepostcode"] => string(1) "0"
["maskedpan"] => string(16) "411111######0021"
["securityresponseaddress"] => string(1) "0"
["issuercountryiso2a"] => string(2) "US"
["settlestatus"] => string(1) "0"
}
}
}
{"requestreference":"W23-fwpp74eu","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 17:24:51","parenttransactionreference":"1-2-345678","livestatus":"0","issuer":"SecureTrading Test Issuer1","splitfinalnumber":"1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","tid":"27882788","merchantnumber":"00000000","merchantcountryiso2a":"GB","transactionreference":"1-2-345679","merchantname":"Test Merchant","paymenttypedescription":"VISA","baseamount":"1050","enrolled":"N","accounttypedescription":"ECOM","acquirerresponsecode":"00","requesttypedescription":"AUTH","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST42","errormessage":"Ok","operatorname":"[email protected]","securityresponsepostcode":"0","maskedpan":"411111######0021","securityresponseaddress":"0","issuercountryiso2a":"US","settlestatus":"0"}],"secrand":"O3L"}
Managing authorisation response
Your system will need to interpret the AUTH response in order to determine if the transaction was successful. The most important field to check in the response is the errorcode.
Error code |
Description |
0 |
Cardholder was successfully authenticated on the card issuer’s ACS.
Customer’s bank authorised the transaction.
Funds will be transferred. |
70000 |
Cardholder was successfully authenticated on the card issuer’s ACS.
Customer’s bank declined the transaction.
Funds will NOT be transferred. |
60022 |
Cardholder was NOT successfully authenticated on the card issuer’s ACS.
Trust Payments did not contact the acquiring bank to seek authorisation.
Funds will NOT be transferred. |
99999 |
An error code of ‘99999’ indicates an unknown error occurred, which requires manual inspection.
We recommend contacting our Support Team for assistance, providing a copy of the entire request submitted and the response returned.
In the interest of security, ensure you omit or mask sensitive field values, such as card details. |
other |
Click here for a full list of error codes used by Trust Payments. |
Regardless of the errorcode returned in the response, we strongly recommend that you refer to our best practices and configure your system to perform all of the checks outlined.
Here is the specification of the fields that are included in the AUTH responses described above, which are specific to 3-D Secure:

Please note that other fields that can be returned are documented on our page covering
AUTH requests.
Key



The above fields may be requested by a card issuer in the event of a disputed transaction and are included in the response for your reference.
Testing
We recommend that you thoroughly test your solution before processing live payments.
Click here for test card details that you can submit when testing.