Contents

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.

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

Info

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.

Warning
Do not use these credentials when processing transactions on your live site reference.
Info
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.

 

 

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.

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

 

 

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

Info
Only the billing premise, billing postcode and security code field values dictate the outcome of the AVS and security code checks performed. As such, entering any details into the other address fields will not affect the outcome of these checks.

 

Premise

Billing premise Security response Security response caption
No 789 2 Matched
No 123 4 Not Matched
No 333 1 Not Checked
Leave blank 0 Not Given

 

Postcode / ZIP code

Billing postcode Security response Security response caption
UK US
TE45 6ST 55555 2 Matched
TE12 3ST 12345 4 Not Matched
TE33 3ST 33333 1 Not Checked
Leave blank Leave blank 0 Not Given

 

Security code

Security code AMEX security code Security response Security response
123 1234 2 Matched
214 2144 4 Not Matched
333 3333 1 Not Checked
Leave blank Leave blank 0 Not Given

 

 


 

Testing non-card payment methods

URL
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

 

Where to find the acquirer advice code

 

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

 

PAYMENT MASTERCARD
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:

 

JavaScript Library (version 1)

 

Warning
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

 

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


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.


composer require securetrading/stpp_json

 


cURL

 

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

 


 

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

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


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

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.

 

Clock
The cachetoken will expire 15 minutes after being generated.
Warning
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.

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


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:

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.

 


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

 

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

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


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

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


#!/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>"
  }]
}'

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


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

 


 

Status good

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!

 

Life ring

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.

investors in people logo   pci - security standards council logo

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