card – Documentation

Account checks

An ACCOUNTCHECK request allows a card to be validated by checking the cardholder’s first line of address, the cardholder’s postcode and the security code, to ensure the details entered by the customer are valid. Click here to learn more about the checks performed.

Requirements

Account checks are only available for certain acquiring banks. Before you begin, please contact our Support Team and ensure your acquiring bank supports this functionality.
Account checks can only be performed for card-based payment methods.

In order to reduce fraud, Visa has mandated that all merchants with a Merchant Category Code (MCC) of 6012 are required to send additional fields in AUTH and ACCOUNTCHECK requests. Click here for further information.

Failure to submit these fields will result in a “60025” (Invalid request) error being returned in the response.

Update your payment form

You can update your payment form to instruct our JavaScript library to process an Account check prior to performing a standard transaction. This is done by specifying custom requestTypes, as shown in the example below:

HTML

<html>
<head>
</head>
<body>
  <div id="st-notification-frame"></div>
  <form id="st-form" action="https://www.example.com" method="POST">
    <div id="st-card-number" class="st-card-number"></div>
    <div id="st-expiration-date" class="st-expiration-date"></div>
    <div id="st-security-code" class="st-security-code"></div>
    <button type="submit" id="st-form__submit" class="st-form__submit">
      Pay securely
    </button>
  </form>
 <script src=<DOMAIN>/js/v2/st.js></script>
 <script> 
  (function() {
   var st = SecureTrading({  
    jwt: 'INSERT YOUR JWT HERE'
    });  
   st.Components({"requestTypes":["ACCOUNTCHECK","THREEDQUERY","AUTH"]}); 
  })(); 
 </script>
</body>
</html>

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

Alternative Payment Methods (API)

Testing

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	Security response	Security response caption
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

The procedure to follow when testing non-card payment methods will vary. For the most relevant testing information, please refer to the documentation provided for the specific payment method:
Link to Payment Pages docs / Link to Webservices API docs

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	Do not process further recurring transactions

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:

Using Account Check to verify customer’s details

Follow these instructions when using Account Checks to verify the customer’s details prior to processing a payment.

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

Prerequisites

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 Account Checks, as part of the PSD2 mandate.

To process an e-commerce Account Check 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 Account Checks that are Mail or Telephone Order (MOTO), Merchant Initiated Transactions (MIT), or using other workflows that are exempt from the PSD2 mandate.

In order to reduce fraud, Visa has mandated that all 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 will result in a “60025” (Invalid request) error being returned in the response. Click here for further information.

Account checks are only available for certain acquiring banks. Before you begin, please contact our Support Team and ensure your acquiring bank supports this functionality.
Account checks can only be performed for card-based payment methods.

Mandate considerations

Visa and Mastercard have mandated that you must obtain cardholder consent if storing card details for future use, and that these must be flagged at the time of the first authorisation, by submitting the credentialsonfile field in your requests. To do so, you will need to ensure the ACCOUNTCHECK request submitted includes the additional field credentialsonfile, with value set to “1”.

You must also flag any subsequent payments that are utilising previously-stored credentials, by including the credentialsonfile field in these requests with value set to “2”.

Click here to learn more about Credentials on File.

Checks performed

All Account Checks processed will perform checks on the cardholder’s first line of address, the cardholder’s postcode and the security code, to ensure the details entered by the customer are valid.

Click here to learn more about these checks.

Process overview

1. Merchant submits ACCOUNTCHECK request.
2. Trust Payments validates the request and contacts the bank.
3. The acquiring bank will contact the card issuer to perform AVS and security code checks.
4. Trust Payments receives results of the request and passes this back to the merchant.
5. Merchant receives and interprets this response.

No funds are reserved by ACCOUNTCHECK requests

The customer’s account is not debited when an ACCOUNTCHECK request is performed.

Similar to standard AUTH requests, AVS and Security Code Checks are performed on ACCOUNTCHECK requests. We recommend reading our documentation on these checks before proceeding.

ACCOUNTCHECK request

The fields required in an ACCOUNTCHECK request are the same as a standard AUTH request, except with the following differences:

The baseamount can be “0”. A non-zero amount can be submitted – this will be inherited in any subsequent requests that reference this Account check as its parent, unless overridden with a new amount.
Additional field credentialsonfile must be submitted with value “1”. (See below)

Field specification

	Field	Format	Description
	credentialsonfile XPath: /operation/credentialsonfile	Numeric (1)	This must be set to “1”, to indicate the customer agreed for the payment credentials to be stored for future transactions. See below for further information.

About inheritance

You can submit any field that you can submit in an AUTH request and these will be inherited by any subsequent child requests. Click here to learn more.

The following is an example of an ACCOUNTCHECK request:

Python
PHP
cURL
Raw JSON
Raw XML

#!/usr/bin/python
import securetrading

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

accountcheck= {
    "currencyiso3a": "GBP",
    "requesttypedescriptions": ["ACCOUNTCHECK"],
    "sitereference": "test_site12345",
    "baseamount": "0",
    "orderreference": "My_Order_123",
    "accounttypedescription": "MOTO",
    "pan": "4111111111111111",
    "expirydate": "12/2020",
    "securitycode": "123",
    "billingpremise": "789",
    "billingpostcode": "TE45 6ST",
    "credentialsonfile": "1"
}

strequest = securetrading.Request()
strequest.update(accountcheck)
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' => 'GBP',
'requesttypedescriptions' => array('ACCOUNTCHECK'),
'sitereference' => 'test_site12345',
'baseamount' => '0',
'orderreference' => 'My_Order_123',
'accounttypedescription' => 'MOTO',
'pan' => '4111111111111111',
'expirydate' => '12/2020',
'securitycode' => '123',
'billingpremise' => '789',
'billingpostcode' => 'TE45 6ST',
'credentialsonfile' => '1'
);

$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": ["ACCOUNTCHECK"],
  "sitereference": "test_site12345",
  "baseamount": "0",
  "orderreference": "My_Order_123",
  "accounttypedescription": "MOTO",
  "pan": "4111111111111111",
  "expirydate": "12/2020",
  "securitycode": "123",
  "billingpremise": "789",
  "billingpostcode": "TE45 6ST",
  "credentialsonfile": "1"
}]}'

{"alias":"[email protected]","version":"1.00","request":[{"currencyiso3a":"GBP","requesttypedescriptions":["ACCOUNTCHECK"],"sitereference":"test_site12345","baseamount":"0","orderreference":"My_Order_123","accounttypedescription":"MOTO","pan":"4111111111111111","expirydate":"12\/2020","securitycode":"123","billingpremise":"789","billingpostcode":"TE45 6ST","credentialsonfile":"1"}]}

<?xml version='1.0' encoding='utf-8'?>
<requestblock version="3.67">
  <alias>[email protected]</alias>
  <request type="ACCOUNTCHECK">
    <merchant>
      <orderreference>My_Order_123</orderreference>
    </merchant>
    <billing>
      <amount currencycode="GBP">0</amount>
      <postcode>TE45 6ST</postcode>
      <premise>789</premise>
      <payment>
        <pan>4111111111111111</pan>
        <securitycode>123</securitycode>
        <expirydate>12/2020</expirydate>
      </payment>
    </billing>
    <operation>
      <accounttypedescription>MOTO</accounttypedescription>
      <sitereference>test_site12345</sitereference>
      <credentialsonfile>1</credentialsonfile>
    </operation>
  </request>
</requestblock>

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

ACCOUNTCHECK response

After the request has been processed, you will receive a single response that contains the response to the ACCOUNTCHECK request:

Python
PHP
Raw JSON
Raw XML

{
  u 'requestreference': u 'Ar2xj1hjr',
    u 'version': u '1.00',
    u 'response': [{
      u 'transactionstartedtimestamp': u '2016-12-07 16:12:00',
        u 'livestatus': u '0',
        u 'issuer': u 'SecureTrading Test Issuer1',
        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-80023',
        u 'merchantname': u 'Test Merchant',
        u 'paymenttypedescription': u 'VISA',
        u 'baseamount': u '0',
        u 'accounttypedescription': u 'MOTO',
        u 'acquirerresponsecode': u '00',
        u 'requesttypedescription': u 'ACCOUNTCHECK',
        u 'securityresponsesecuritycode': u '2',
        u 'currencyiso3a': u 'GBP',
        u 'authcode': u 'TEST46',
        u 'errormessage': u 'Ok',
        u 'operatorname': u '[email protected]',
        u 'securityresponsepostcode': u '2',
        u 'maskedpan': u '411111######1111',
        u 'securityresponseaddress': u '2',
        u 'issuercountryiso2a': u 'US',
        u 'settlestatus': u '0',
        u 'credentialsonfile': u '1'
    }]
}

array(3) {
  ["requestreference"] => string(9) "A4cenptwx"
  ["version"] => string(4) "1.00"
  ["response"] => array(1) {
    [0] => array(28) {
      ["transactionstartedtimestamp"] => string(19) "2016-12-09 11:04:29"
      ["livestatus"] => string(1) "0"
      ["issuer"] => string(26) "SecureTrading Test Issuer1"
      ["dccenabled"] => string(1) "0"
      ["settleduedate"] => string(10) "2016-12-09"
      ["errorcode"] => string(1) "0"
      ["baseamount"] => string(1) "0"
      ["tid"] => string(8) "27882788"
      ["merchantnumber"] => string(8) "00000000"
      ["securityresponsepostcode"] => string(1) "2"
      ["transactionreference"] => string(10) "72-9-80018"
      ["merchantname"] => string(13) "Test Merchant"
      ["paymenttypedescription"] => string(4) "VISA"
      ["orderreference"] => string(12) "My_Order_123"
      ["accounttypedescription"] => string(4) "MOTO"
      ["acquirerresponsecode"] => string(2) "00"
      ["requesttypedescription"] => string(12) "ACCOUNTCHECK"
      ["securityresponsesecuritycode"] => string(1)"2"
      ["currencyiso3a"] => string(3) "GBP"
      ["authcode"] => string(6) "TEST39"
      ["errormessage"] => string(2) "Ok"
      ["operatorname"] => string(23) "[email protected]"
      ["merchantcountryiso2a"] => string(2) "GB"
      ["maskedpan"] => string(16) "411111######1111"
      ["securityresponseaddress"] => string(1) "2"
      ["issuercountryiso2a"] => string(2) "US"
      ["settlestatus"] => string(1) "0"
      ["credentialsonfile"] => string(1) "1"
    }
  }
}

{"requestreference":"W23-q3wa45ge","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 16:16:39","livestatus":"0","issuer":"SecureTrading Test Issuer1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","baseamount":"0","tid":"27882788","merchantnumber":"00000000","securityresponsepostcode":"2","transactionreference":"23-9-80024","merchantname":"Test Merchant","paymenttypedescription":"VISA","orderreference":"My_Order_123","accounttypedescription":"MOTO","acquirerresponsecode":"00","requesttypedescription":"ACCOUNTCHECK","securityresponsesecuritycode":"2","currencyiso3a":"GBP","authcode":"TEST53","errormessage":"Ok","operatorname":"[email protected]","merchantcountryiso2a":"GB","maskedpan":"411111######1111","securityresponseaddress":"2","issuercountryiso2a":"US","settlestatus":"0","credentialsonfile":"1"}],"secrand":"NunVEQ"}

<?xml version='1.0' encoding='utf-8'?>
<responseblock version="3.67">
  <requestreference>X575647667</requestreference>
  <response type="ACCOUNTCHECK">
    <merchant>
      <merchantname>Test Merchant</merchantname>
      <orderreference>My_Order_123</orderreference>
      <tid>27882788</tid>
      <merchantnumber>00000000</merchantnumber>
      <merchantcountryiso2a>GB</merchantcountryiso2a>
      <operatorname>[email protected]</operatorname>
    </merchant>
    <transactionreference>16-9-1</transactionreference>
    <billing>
      <amount currencycode="GBP">0</amount>
      <payment type="VISA">
        <issuer>SecureTrading Test Issuer1</issuer>
        <issuercountry>US</issuercountry>
        <pan>411111######1111</pan>
      </payment>
      <dcc enabled="0"/>
    </billing>
    <authcode>TEST53</authcode>
    <live>0</live>
    <error>
      <message>Ok</message>
      <code>0</code>
    </error>
    <timestamp>2013-01-16 10:48:17</timestamp>
    <acquirerresponsecode>00</acquirerresponsecode>
    <security>
      <address>2</address>
      <postcode>2</postcode>
      <securitycode>2</securitycode>
    </security>
    <settlement>
      <settleduedate>2013-01-16</settleduedate>
      <settlestatus>0</settlestatus>
    </settlement>
    <operation>
      <accounttypedescription>MOTO</accounttypedescription>
      <credentialsonfile>1</credentialsonfile>
    </operation>
  </response>
  <secrand>bByuPvGz9Hcm</secrand>
</responseblock>

Handling the response

Ensure that the errorcode value returned is “0”, indicating success. (You must not store credentials if an error has occurred)
Check the values returned in the securityresponseaddress, securityresponsepostcode and securityresponsesecuritycode fields and only proceed if business requirements have been satisfied. (More info provided below)

It is strongly recommended that you check the security fields returned in the response, and manually investigate transactions where the returned securityresponsesecuritycode is “4” (indicating the customer entered a security code that doesn’t match the value found on the back of the card).

Field	Format	Description
securityresponseaddress XPath: /security/address	Numeric (1)	“0” Not given – Your system did not provide the acquiring bank the information required to perform this check. “1” Not checked – The acquiring bank did not perform this check on the information you provided in the request. “2” Matched – The information you provided in the request matches the information obtained by the acquiring bank, from the customer’s payment issuer. “4” Not matched – The information you provided in the request does not match the information obtained by the acquiring bank, from the customer’s payment issuer.
securityresponsepostcode XPath: /security/postcode	Numeric (1)
securityresponsesecuritycode XPath: /security/securitycode	Numeric (1)

Payouts

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.

Payouts are similar to standard refunds, except they can be performed independently of other transactions. The benefits of performing payouts include:

The refund amount can be greater than the original payment, if required.
The refund can be processed before the original payment has been settled into your bank account.

Payouts are also known as Credit Fund Transfers (CFT) or Original Credit Transfers (OCT).

Payouts processed with Visa Direct are processed online, with the customer’s account typically being credited within 30 minutes.

Please contact your account manager to check if you are eligible to enable Visa Direct on your account.

Requirements

You will need to have a CFT Merchant Number associated with your Trust Payments account. If you are unsure if your merchant number supports this, we recommend contacting your bank for clarification. Additionally, please ensure you are following any guidelines outlined by your bank before proceeding.

Payout request

Using parent transaction

Payouts are performed by processing a REFUND request.
Like a standard REFUND request, the requesttypedescriptions needs to be “REFUND”.
The accounttypedescription submitted needs to be “CFT”.
In this example, the parenttransactionreference is included, which references the original AUTH. This will inherit the payment, billing and customer details from the parent, so your system does not need to submit them again.

The following is an example of such a request:

Ensure the submitted accounttypedescription is “CFT”, otherwise a regular REFUND will be processed instead of a payout.

Python
PHP
cURL
Raw JSON
Raw XML

#!/usr/bin/python
import securetrading
  
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
  
payout= {
  "requesttypedescriptions": ["REFUND"],
  "sitereference": "test_site12345",
  "accounttypedescription": "CFT",
  "parenttransactionreference": "1-2-345678"
}
  
strequest = securetrading.Request()
strequest.update(payout)
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('REFUND'),
'sitereference' => 'test_site12345',
'accounttypedescription' => 'CFT',
'parenttransactionreference' => '1-2-345678'
);

$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": [{
  "requesttypedescriptions": ["REFUND"],
  "sitereference": "test_site12345",
  "accounttypedescription": "CFT",
  "parenttransactionreference": "1-2-345678"
}]}'

{"alias":"[email protected]","version":"1.00","request":[{"requesttypedescriptions":["REFUND"],"sitereference":"test_site12345","accounttypedescription":"CFT","parenttransactionreference":"1-2-345678"}]}

<requestblock version="3.67">
  <alias>[email protected]</alias>
  <request type="REFUND">
    <operation>
      <sitereference>test_site12345</sitereference>
      <accounttypedescription>CFT</accounttypedescription>
      <parenttransactionreference>1-2-345678</parenttransactionreference>
    </operation>
  </request>
</requestblock>

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

Without parent

As an alternative to the above, you can also submit a payout request without reference to a parent transaction. In this scenario, you will instead need to submit the customer’s payment details in the payout request. Please see the following example:

Python
PHP
cURL
Raw JSON
Raw XML

#!/usr/bin/python
import securetrading
  
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
  
payout= {
        "requesttypedescriptions": ["REFUND"],
        "sitereference": "test_site12345",
        "accounttypedescription": "CFT",
        "baseamount": "1050",
        "currencyiso3a": "GBP",
        "pan": "4111111111111111",
        "expirydate": "12/2020",
        "securitycode": "123"
}
  
strequest = securetrading.Request()
strequest.update(payout)
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('REFUND'),
'sitereference' => 'test_site12345',
'accounttypedescription' => 'CFT',
'baseamount' => '1050',
'currencyiso3a' => 'GBP',
'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": [{
  "requesttypedescriptions": ["REFUND"],
  "sitereference": "test_site12345",
  "accounttypedescription": "CFT",
  "baseamount": "1050",
  "currencyiso3a": "GBP",
  "pan": "4111111111111111",
  "expirydate": "12/2020",
  "securitycode": "123"
}]}'

{"alias":"[email protected]","version":"1.00","request":[{"requesttypedescriptions":["REFUND"],"sitereference":"test_site12345","accounttypedescription":"CFT","baseamount":"1050","currencyiso3a":"GBP","pan":"4111111111111111","expirydate":"12\/2020","securitycode":"123"}]}

<requestblock version="3.67">
  <alias>[email protected]</alias>
  <request type="REFUND">
    <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>CFT</accounttypedescription>
    </operation>
  </request>
</requestblock>

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

Field specification

When reading the following specification, please ensure that you reference the relevant code examples for your chosen language.

Field	Format	Description
accounttypedescription XPath: /operation/accounttypedescription	Alpha (20)	Must be “CFT”.
baseamount XPath: /billing/amount	Numeric (13)	The refund amount in base units, with no commas or decimal points. e.g. £10.99 would be submitted as “1099” but ¥246 would be submitted as “246”. (Max length of amount may vary depending on your acquiring bank – Contact your bank for further info)
currencyiso3a XPath: /billing/amount/@currencycode	Alpha (3)	The currency that the transaction will be processed in. Click here for a full list of available currencies.
expirydate XPath: /billing/payment/expirydate	Date MM/YYYY	If you would like to process a refund with an updated expiry date, the new value is submitted in this field.
orderreference XPath: /merchant/orderreference	Alphanumeric including symbols (255)	Your unique order reference that can be stored on Trust Payments’s system. If this is not submitted, it is inherited from the parent AUTH request, provided a parenttransactionreference has been included.
pan XPath: /billing/payment/pan	Numeric (12-19)	This is the long number printed on the front of the customer’s card. We return a masked version of this PAN in the response, in the field maskedpan. e.g. “411111######1111”
parenttransactionreference XPath: /operation/parenttransactionreference	Alphanumeric & hyphens (25)	You can submit the transaction reference of the AUTH request that you would like to refund.
requesttypedescriptions XPath: /@type	Alphanumeric & hyphens (25)	The request type required is “REFUND”.
securitycode XPath: /security/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) We strongly recommend submitting this value for the processing of security code checks. Additionally, some banks may decline the payment if the security code is not present.
sitereference XPath: /operation/sitereference	Alphanumeric & underscore (50)	A unique reference that identifies your account. You receive this when you first sign up with us.

Payout response

The response returned has the same structure as a standard REFUND, except that the accounttypedescription returned is “CFT”:

Python
PHP
Raw JSON
Raw XML

{
  u 'requestreference': u 'Agv3epv31',
    u 'version': u '1.00',
    u 'response': [{
      u 'transactionstartedtimestamp': u '2016-12-07 15:44:33',
        u 'parenttransactionreference': u '1-2-345678',
        u 'livestatus': u '0',
        u 'issuer': u 'SecureTrading Test Issuer1',
        u 'dccenabled': u '0',
        u 'settleduedate': u '2016-12-07',
        u 'errorcode': u '0',
        u 'orderreference': u 'My_Order_123',
        u 'tid': u '27880001',
        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 'CFT',
        u 'acquirerresponsecode': u '00',
        u 'requesttypedescription': u 'REFUND',
        u 'securityresponsesecuritycode': u '0',
        u 'currencyiso3a': u 'GBP',
        u 'authcode': u 'TEST REFUND ACCEPTED',
        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) "A19beknpr"
  ["version"] => string(4) "1.00"
  ["response"] => array(1) {
    [0] => array(28) {
      ["transactionstartedtimestamp"] => string(19) "2016-12-09 10:21:13"
      ["parenttransactionreference"] => string(10) "1-2-345678"
      ["livestatus"] => string(1) "0"
      ["issuer"] => string(26) "SecureTrading Test Issuer1"
      ["dccenabled"] => string(1) "0"
      ["settleduedate"] => string(10) "2016-12-09"
      ["errorcode"] => string(1) "0"
      ["orderreference"] => string(12) "My_Order_123"
      ["tid"] => string(8) "27880001"
      ["merchantnumber"] => string(8) "00000000"
      ["securityresponsepostcode"] => string(1) "0"
      ["transactionreference"] => string(10) "1-2-345679"
      ["merchantname"] => string(13) "Test Merchant"
      ["paymenttypedescription"] => string(4) "VISA"
      ["baseamount"] => string(4) "1050"
      ["accounttypedescription"] => string(3) "CFT"
      ["acquirerresponsecode"] => string(2) "00"
      ["requesttypedescription"] => string(6) "REFUND"
      ["securityresponsesecuritycode"] => string(1) "0"
      ["currencyiso3a"] => string(3) "GBP"
      ["authcode"] => string(20) "TEST REFUND ACCEPTED"
      ["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-qc7t4h8a","version":"1.00","response":[{"transactionstartedtimestamp":"2016-12-07 15:50:37","parenttransactionreference":"1-2-345678","livestatus":"0","issuer":"SecureTrading Test Issuer1","dccenabled":"0","settleduedate":"2016-12-07","errorcode":"0","baseamount":"1050","tid":"27880001","merchantnumber":"00000000","merchantcountryiso2a":"GB","transactionreference":"1-2-345679","merchantname":"Test Merchant","paymenttypedescription":"VISA","orderreference":"My_Order_123","accounttypedescription":"CFT","acquirerresponsecode":"00","requesttypedescription":"REFUND","securityresponsesecuritycode":"0","currencyiso3a":"GBP","authcode":"TEST REFUND ACCEPTED","errormessage":"Ok","operatorname":"[email protected]","securityresponsepostcode":"0","maskedpan":"411111######1111","securityresponseaddress":"0","issuercountryiso2a":"US","settlestatus":"0"}],"secrand":"0V2j6j0kl2R1UU"}

<?xml version='1.0' encoding='utf-8'?>
<responseblock version="3.67">
  <requestreference>X1u3u92dg</requestreference>
  <response type="REFUND">
    <merchant>
      <tid>27880001</tid>
      <merchantnumber>00000000</merchantnumber>
      <merchantcountryiso2a>GB</merchantcountryiso2a>
      <merchantname>Test Merchant</merchantname>
      <orderreference>My_Order_123</orderreference>
      <operatorname>[email protected]</operatorname>
    </merchant>
    <transactionreference>1-2-345679</transactionreference>
    <billing>
      <amount currencycode="GBP">1050</amount>
      <payment type="VISA">
        <pan>411111######1111</pan>
        <issuercountry>US</issuercountry>
        <issuer>SecureTrading Test Issuer1</issuer>
      </payment>
      <dcc enabled="0"/>
    </billing>
    <timestamp>2019-12-17 11:16:05</timestamp>
    <error>
      <message>Ok</message>
      <code>0</code>
    </error>
    <acquirerresponsecode>00</acquirerresponsecode>
    <live>0</live>
    <authcode>TEST REFUND ACCEPTED</authcode>
    <operation>
      <parenttransactionreference>1-2-345678</parenttransactionreference>
      <accounttypedescription>CFT</accounttypedescription>
    </operation>
    <settlement>
      <settleduedate>2019-12-17</settleduedate>
      <settlestatus>0</settlestatus>
    </settlement>
    <security>
      <address>0</address>
      <postcode>0</postcode>
      <securitycode>0</securitycode>
    </security>
  </response>
  <secrand>V1utOQ5A</secrand>
</responseblock>

3-D Secure (version 1)

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:

PYTHON
PHP
CURL

#!/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

Field name	Type	Length	Request	Description
accept	Alphanumeric	1024		The exact content of the HTTP accept-header field as received from the cardholder’s user agent.
accounttypedescription	Alpha	20		This must be submitted as “ECOM” (e-commerce).
baseamount	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	Alpha	3		The currency that the transaction will be processed in. Click here for a full list of available currencies.
expirydate	Date MM/YYYY	7		The expiration date printed on the card.
pan	Numeric	12-19		This is the long number printed on the front of the customer’s card. We return a masked version of this PAN in the response, in the field maskedpan. e.g. “411111######1111”
requesttypedescriptions	Alpha	20		The request type required is “THREEDQUERY”.
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 field 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.
sitereference	Alphanumeric including underscore	50		The site reference relates to your individual account which you received on setup. If you do not know your site reference, please contact our Support team.
termurl	URL	1024 More info		This field value is a URL of a script/file located on your system that is able to manage customers who are returned to your system. It is used to instruct the card issuer where to send the customer’s browser after they have been authenticated on the card issuer’s ACS.
useragent	Alphanumeric	255		The exact content of the HTTP user-agent header field as received from the cardholder’s user agent. We strongly recommend you submit this field, as failure to do so may forfeit the liability shift.

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:

PYTHON
PHP
CURL

{
  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

Field name	Type	Length	Response	Description
requesttypedescription	Alpha	20		“THREEDQUERY” is always returned in the response.
xid	Alphanumeric	255		The unique identifier for the transaction, assigned by the MPI (Merchant Plug-In) (in this case, Trust Payments).
enrolled	Char	1		Determines if the cardholder is enrolled in a 3-D Secure scheme. “Y” – Card is enrolled. “N” – Card is not enrolled. “U” – Unable to determine if card is enrolled.
pareq	Alphanumeric including symbols	2048		The unique identifier for the transaction, assigned by the MPI (Merchant Plug-In) (in this case, Trust Payments).
md	Alphanumeric including symbols	1024		Returned if card is enrolled. The unique 3-D Secure reference for this transaction.
acsurl	URL	1024		Returned if card is enrolled. The URL of the Access Control Server (ACS) to be used in authenticating the cardholder.
threedversion	Numeric	6		Only returned for accounts with certain acquiring banks. The version of the 3-D Secure protocol.

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 :

HTML

<!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:

PYTHON
PHP
CURL

#!/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:

PYTHON
PHP
CURL

#!/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

PYTHON
PHP
CURL

{
  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

PYTHON
PHP
CURL

{
  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

PYTHON
PHP
CURL

{
  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

Field name	Type	Length	Response	Description
enrolled	Char	1		Indicates if the cardholder is enrolled in a 3-D Secure scheme: “Y” – Card is enrolled. “N” – Card is not enrolled. “U” – Unable to determine if card is enrolled.
xid	Alphanumeric	255		The unique identifier for the transaction, assigned by the MPI (Merchant Plug-In) (in this case, Trust Payments).
status	Char	1		Returned if card is enrolled. Indicates whether or not the customer was authenticated on the card issuer’s ACS: “Y” – Customer authenticated. “N” – Customer not authenticated. “A” – An authentication attempt occurred but could not be completed. “U” – Unable to perform authentication.
cavv	Alphanumeric	32		Returned if card is enrolled and authenticated. The unique Cardholder Authentication Verification Value (CAVV) associated with the transaction, provided by the card issuer.
eci	Alphanumeric	2		Returned if card is enrolled and authenticated. The ECI (E-Commerce Indicator) security level associated with the transaction.

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.

JavaScript Library (version 1)

This page documents how to integrate using our legacy JavaScript Library solution (verson 1)

If you are integrating with us for the first time, we strongly recommend using the latest version of our JavaScript Library.

Click here to get started >>>

Install a library

We provide libraries for the Python and PHP programming languages. Alternatively, it is possible to use cURL in a variety of other languages. These libraries consist of functions that can be referenced within your program body without defining them explicitly.

We recommend that you follow the instructions below to download and install your preferred library on your server.

Planning on using your own library?

If you plan on using your own library to process requests, you will need to read “Configuring your own library“.

Python

We support Python v2.7.9+ and v3.
We recommend that you use the latest version of Python v3.x available when integrating with us.
Python v2.7 reaches end of life in January 2020. As such, we strongly recommend against new integrations using this version.
Version “2.9” of the Python “requests” library is required to ensure that the latest certificates have been installed.

To install our Python library, you can use ‘pip‘, which is a package management system used to install and manage software packages written in Python.

Using pip

pip install securetrading

Alternatively, you can download the package from https://github.com/Secure-Trading/st-python-api and install the library manually.

PHP

You can use the following command to install our PHP library.

Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will install and update them for you.

Using composer

composer require securetrading/stpp_json

cURL

Provided your system already has cURL installed, no additional installation is required.

You must never log sensitive payment details on your server

Please ensure that any additional debugging enabled whilst testing your integration is disabled prior to going live. Failing to do so may contravene the requirements needed to maintain PCI compliance.

Summary

You have now installed a library on your server, and you can use this to send requests to our gateway.

Read on to learn how to process your first request.

Collecting payment details using Cachetoken

You can use our JavaScript Client SDK (“st.js”) to process payments without submitting the customer’s card details to your server, thereby simplifying the audit process for PCI DSS.

Your server-side payment form must assign all card details with the attribute “data-st-field”. During payment form submission, “st.js” will tokenise all fields with the attribute “data-st-field” to create a unique cachetoken.

This cachetoken is then submitted to your server, along with all other fields that do not have the attribute “data-st-field”.

Server-side payment form

The following is an example of a payment form:

Standard
Overriding id

<html>

<head>
    <style>
        #st-payment input.st-error {
            background-color: #ffc6c7;
            border: 2px solid #ffb5b5;
        }
        #st-message .st-error {
            background: #ffcdcd;
            border: 2px solid #ffb5b5;
            padding: 4px 4px 4px 28px !important;
        }
    </style>
</head>

<body>
    <div id="st-message"></div>
    <form id="st-payment" action="https://www.example.com">
    <!--Ensure all payment details use the data-st-field attribute.-->
        Pan: 
        <input type="text" data-st-field="pan" autocomplete="off" /></br>
        Expiry Month: 
        <input type="text" data-st-field="expirymonth" autocomplete="off" /></br>
        Expiry Year: 
        <input type="text" data-st-field="expiryyear" autocomplete="off" /></br>
        Security Code: 
        <input type="text" data-st-field="securitycode" autocomplete="off" /></br>
    <!--You can submit your own custom fields within this form, e.g. discount code-->
        Discount Code: 
        <input type="text" name="discountcode" autocomplete="off" /></br>
        <input type="submit" name="mybtn" />
    </form>
    <script src="https://webservices.securetrading.net/js/st.js"></script>
    <script>
        new SecureTrading.Standard({
            sitereference: "test_site12345", locale: "en_gb"
        });
    </script>
</body>
</html>

<html>

<!-- If you need to change the names of the identifiers “st-message” and “st-payment”, -->
<!-- because your application doesn’t support the naming convention used -->
<!-- (e.g. no hyphen support), you can use the markup found here to override them. -->

<head>
    <style>
        #st-payment input.st-error {
            background-color: #ffc6c7;
            border: 2px solid #ffb5b5;
        }
        #st-message .st-error {
            background: #ffcdcd;
            border: 2px solid #ffb5b5;
            padding: 4px 4px 4px 28px !important;
        }
    </style>
</head>

<body>
    <div id="stmessage"></div>
    <form id="stpayment" action="https://www.example.com">
    <!--Ensure all payment details use the data-st-field attribute.-->
        Pan: 
        <input type="text" data-st-field="pan" autocomplete="off" /></br>
        Expiry Month: 
        <input type="text" data-st-field="expirymonth" autocomplete="off" /></br>
        Expiry Year: 
        <input type="text" data-st-field="expiryyear" autocomplete="off" /></br>
        Security Code: 
        <input type="text" data-st-field="securitycode" autocomplete="off" /></br>
    <!--You can submit your own custom fields within this form, e.g. discount code-->
        Discount Code: 
        <input type="text" name="discountcode" autocomplete="off" /></br>
        <input type="submit" name="mybtn" />
    </form>
    <script src="https://webservices.securetrading.net/js/st.js"></script>
    <script>
        new SecureTrading.Standard({
            sitereference: "test_site12345",
            locale: "en_gb",
            messageId: "stmessage",
            formId: "stpayment",
        });
    </script>
</body>
</html>

To use the Client SDK, reference our “st.js” in your webpage’s HTML mark-up, as demonstrated in the payment form example above.

You must ensure that your payment form has been assigned the id “st-payment”. The following are required fields and must be included in the payment form:

The card number: data-st-field=”pan”
The card expiry month: data-st-field=”expirymonth”
The card expiry year: data-st-field=”expiryyear”
The card security code: data-st-field=”securitycode”

After the customer clicks “Pay”, these fields are used to generate a unique cachetoken that will later be posted to your server, for the purpose of processing requests.

The cachetoken will expire 15 minutes after being generated.

You must ensure that the PAN, expiry date and security code use the “data-st-field” attribute and NOT the “name” attribute. Failing to do so may lead to sensitive data being posted directly to your server.

Any input fields that have the attribute “data-st-field” are transmitted directly to Trust Payments from the customer’s browser session in a secure manner. This means that these sensitive payment details are never submitted to your server.

A “div” element with attribute id=”st-message” is required, in order for invalid field and connection errors to be displayed, in cases when ‘st.js’ fails to generate a cachetoken.

If there is an error during the cachetoken generation process, the optional CSS included in the server-side payment form example will highlight any invalid input fields on the form and style the error message returned.

This library supports the AMD (Asynchronous Module Definition) API. This allows it to be loaded using RequireJS, CommonJS or through a normal <script> element inside your webpage’s HTML markup.

Ensure the action in the server-side payment form is a valid URL address hosted on your server. The address specified must be able to take the generated cachetoken and all fields without the “data-st-field” attribute, which are submitted to the Server SDK as a JSON request.

Callback prior to processing a payment

If you need to perform additional tasks after the cachetoken has been passed to the customer’s browser session, but before the payment form details are submitted to your server, you can do so by passing the submitFormCallback parameter to the SecureTrading.Standard library.

Callback function

new SecureTrading.Standard({
    sitereference: "test_site12345",
    submitFormCallback: function(responseObj){
    var cachetoken = responseObj['response'][0]['cachetoken']; <!-- Grab token -->
    console.log(cachetoken); <!-- Logs the token to the console (Additional steps can be performed here before submitting to your server) -->
    document.getElementById(‘st-payment’).submit(); <!-- Submit the form -->
}

Language support

The response messages can be returned to the customer in the following languages:

English
French
German

By default, the response is returned in English. In order to change the default language, simply change the locale value in the payment form example above.

To return the response in the English language, set the locale to ‘en_gb’.
To return the response in the French language, set the locale to ‘fr_fr’.
To return the response in the German language, set the locale to ‘de_de’.

An example of a message returned to the customer – “There has been a problem with your payment, please verify your details and try again.”

Test credentials

You can process successful transactions by submitting the following test card numbers:

Payment type	Test PAN	Expiry date	Security code
Visa	4111111111111111	12/2030	123
Mastercard	5100000000000511	12/2030	123

Note: Any expiry date submitted to our test bank is valid, providing the date is in the future.

Other cards are supported. Click here for further testing credentials.

Summary

You should now have a basic form that can be used to collect the customer’s payment details and send a cachetoken to your server.
The cachetoken can be used in conjunction with your installed library to process a request.

Process requests using our Webservices API

The following describes how you can reference the SDK functions within your program body to submit a request to our servers.

Before you get started, you will need a Web Services username and password to allow us to authenticate your requests.

You can create a Web Services user using our MyST interface. Your system will need to submit this username in every request, along with the password. In our request examples we use a placeholder username and password, which you will need to replace with your own credentials before testing.

If you don’t already have Web Services credentials, click here to learn how to configure this.

You may need to open your firewall to our Web Services IPs.

Click here for a full list.

Your server will now need to generate a request. For example:

REQUEST

"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"accounttypedescription": "ECOM",
"currencyiso3a": "GBP",
"baseamount": "1050",
"orderreference": "My_Order_123",
"cachetoken": "<INSERT TOKEN HERE>"

We will accept any Unicode characters in your JSON request. The encoding used is UTF-8, which is a multi-byte encoding scheme. All responses from us are encoded using UTF-8. Your system must be prepared to accept any valid JSON responses encoded this way.

In order to meet strict security requirements we are unable to accept an origin of https://localhost when using our Cross-origin resource sharing (CORS) services.

You must use a valid domain that is accessible by Trust Payments.

You will need to submit the generated request to the Trust Payments library installed above.

The following are examples of how to perform a request for each tool and programming language we currently support.

PYTHON
PHP
CURL

#!/usr/bin/python
import securetrading
 
stconfig = securetrading.Config()
stconfig.username = "[email protected]"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
#Replace the example Web Services username and password above with your own
 
request = {
  "sitereference": "test_site12345",
  "requesttypedescriptions": ["AUTH"],
  "accounttypedescription": "ECOM",
  "currencyiso3a": "GBP",
  "baseamount": "1050",
  "orderreference": "My_Order_123",
  "cachetoken": "<INSERT TOKEN HERE>"
}
 
strequest = securetrading.Request()
strequest.update(request)
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^',
);
//Replace the example Web Services username and password above with your own
 
$requestData = array(
  'sitereference' => 'test_site12345',
  'requesttypedescriptions' => array('AUTH'),
  'accounttypedescription' => 'ECOM',
  'currencyiso3a' => 'GBP',
  'baseamount' => '1050',
  'orderreference' => 'My_Order_123',
  'cachetoken' => '<INSERT TOKEN HERE>'
);
 
$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": ["AUTH"],
    "sitereference": "test_site12345",
    "baseamount": "1050",
    "orderreference": "My_Order_123",
    "accounttypedescription": "ECOM",
    "cachetoken": "<INSERT TOKEN HERE>"
  }]
}'

For the purpose of these examples, we have hard-coded the request fields. In your implementation, you would need to have an automated process that updates each request before being submitted by the library.

Handling the response

Your system will be returned numerous fields in the response object. You will need to interpret the contents of these fields to ensure they are the values expected.

The following is an example of an AUTH response:

PYTHON
PHP
CURL

{
  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 '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 '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######0021',
        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) "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) "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":"SecureTrading Test Issuer1","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"}

It is especially important to check the Error Code and settle status values returned in the response.

In addition to processing authorisations, Trust Payments supports numerous other request types. For further information on these request types, please refer to the other pages within our online documents.

Summary

At this point, you should be able to process a basic request using our Webservices API.

Next steps

We recommend reading our Best practices in order to learn how to best handle the fields returned in the response.
You can refer to our additional documents to learn about other features that can be configured as part of your implementation.
Once you have tested your solution thoroughly, you can request to go live and begin to process live payments!

We’re here to help

We hope that you find our online help resource to be useful. If you are experiencing issues with your configuration, please visit our Troubleshooting page.