1. finance
2. personal finance
3. lending
4. credit cards

XML Specification
This document is to be used as a reference when viewing any XML
throughout Secure Trading’s documentation. The conventions used to
describe XML Requests and Responses are outlined.
Version: 2.10
Published: 15 October 2014
XML Specification
About this Document
This document is a supplement to the STPP documentation. It outlines the process of
performing XML Authorisations, Refunds and other requests through Secure Trading.
Conventions
Terminology conventions on “merchant” and “customer”
The supplier-customer chain within Secure Trading’s systems has two levels of customer,
Secure Trading therefore make a clear definition between the two:
Merchant relates to a customer of Secure Trading that uses the system to process
requests, such as those for online payments.
Customer relates to a customer of the merchant.
Naming conventions of XML through Secure Trading
Whenever a field used through Secure Trading’s systems is noted within this document, it will
be written in Courier font. If there is a large amount of code or XML to be included as an
example, then it will be included in a box such as the following.
<?xml version="1.0" encoding="utf-8"?>
<requestblock version="3.67">
…
</request>
</requestblock>
All fields that are processed through Secure Trading’s systems are lower case, and there is no
space or hyphen between words in order to avoid any confusion when programming. For
example, the field for submitting a field including a merchant’s Site Reference through the
system is called sitereference.
Note on bulleting conventions
There are two forms of bulleting conventions to be included within this document.
Notes with useful but not Mandatory information for your consideration, these are
displayed using the following:
Please note that…
Notes that are requirements and need to be followed in order to prevent future issues
with your code are indicated with an exclamation mark and are outlined in bold.
It is imperative that…
© Secure Trading Limited 2014
15 October 2014
Page 2 / 61
XML Specification
Legend
All XML Requests outlined within Secure Trading’s documentation are outlined both in
parameter tables, and diagrammatically. The purpose of the diagrams is to provide the user with
an overview of the XML that needs to be generated. All diagrams follow the same legend which
is outlined below.
Elements
Each XML request will have a parent element, and underneath child elements. Some child
elements will then have child elements themselves. For all elements of XML that are mandatory,
they are displayed with a solid line around the field name.
example
In contrast, if an element is optional, then it is displayed with a dotted line around the field
name.
example
A field may be required for one request type, but not for another, it is therefore
outlined in the specific document for that request if a field is mandatory or not.
Parent and Child Elements
Elements can have child elements, for example a <payment> tag will have child tags such as
the <pan> for the card number and <expirydate> for the expiry date. If a element has a child
element however they are not displayed on the diagram you are looking at as they are not
relevant to the section being described, they will have a + symbol next to the element displayed.
example
+
Blocks
Within each XML Specification, there will be a need to display the chain of child elements of the
main request. These are outlined as a further level of blocks in an additional diagram. Please
view the XML below:
<xml version="1.0" encoding="utf-8"?>
<request>
<tag1>
<child1></child1>
<child2></child2>
</tag1>
<tag2>
<child3></child3>
</tag2>
</request>
</xml>
The child elements for tag1 would then be diagrammatically represented as follows:
© Secure Trading Limited 2014
15 October 2014
Page 3 / 61
XML Specification
child1
request
tag1
+
child2
For the diagram above, although the XML <tag2> has child elements, they are
not included within this diagram as they are not relevant when describing the child
elements of <tag1>.
Character Encoding
The STPP system will accept any Unicode characters.
The default encoding used for XML is UTF-8 which is a multi-byte encoding scheme. Most XML
parsers will automatically handle this.
A request that is not properly encoded may receive the following response:
“XML: Invalid byte 1 of 1-byte UTF-8 sequence”
In order to avoid this, either encode the XML request using UTF-8, or specify the encoding in
the first line of the request.
Any request must be correctly encoded according to the character encoding specified in the
XML header:
<?xml version=”1.0” encoding=”iso-8859-1”?>
All responses from Secure Trading are encoded using UTF-8. Your system must be prepared to
accept any valid XML encoded this way even if the request uses a different encoding.
Most XML parsers will handle this automatically as it is part of the XML Specification.
Escaping Characters
The data submitted within the XML <tags> must be correctly escaped. Most XML parsers will
automatically do this.
For example:
The character '&' MUST be escaped as '&amp;'
The character '<' MUST be escaped as '&lt;'
Failure to properly escape characters can lead to Malformed XML and may lead to security
problems with malicious users.
Explanations on the parameter tables
For each section of XML that is outlined within the STPP documentation, there will be a
parameter table. The purpose of the table is to provide the reader with more information
regarding the individual element which should be noted when developing your system. Please
find below an extract for the payment type tags.
© Secure Trading Limited 2014
15 October 2014
Page 4 / 61
XML Specification
Tag
Type
Length
Required
an
20
Y
pan
n
12-19
Y
expirydate
an
7
Y
payment type
Comment
The customer’s card type, for
example VISA or MASTERCARD.
This is the card number printed on the
front of the customer’s card.
The expiry date printed on the card.
This needs to be submitted in the
format MM/YYYY.
Below is a description of the data to be found in each field in the table above.
Tag
The Tags column represents each element which is being described. Each child element is
indented slightly underneath the parent element. Within this field will be the name of the
element, which will always be lower case.
For long field names, in the table the tag field will have a line break. However, within the XML,
there are no spaces or line breaks, therefore, if you have a field name as detailed in the table
below, ignore any line breaks when building your XML.
parent
transaction
reference
an
25
N
Here would be the reference of a
previous transaction.
Data Type
The entries may either be alphanumeric, numeric or consist of only one letter:
The abbreviation of alphanumeric inputs is “an”.
The abbreviation for numeric inputs is “n”.
The abbreviation for single letters is “char”.
Field Length
The field length defines the maximum number of characters allowed for that element.
Mandatory Field
This field will either be a Yes or No indicating whether it is mandatory or not in relation to the
request outlined.
If the field is mandatory depending on the value of other fields then it is Conditional.
Comment
Included in the comment field will be additional information relating to the field. Providing the
reader with a clearer understanding of what should be included. In addition if a field needs to be
submitted in a specific format, then this is included here.
System Time
Secure Trading’s System Time is in Greenwich Mean Time (GMT).
© Secure Trading Limited 2014
15 October 2014
Page 5 / 61
XML Specification
Table of Contents
1
Introduction ...................................................................................................................................... 7
1.1
1.2
2
Authorisation .................................................................................................................................... 8
2.1
2.2
2.3
3
Testing Authorisation ............................................................................................................... 53
Testing Security Code and Address Verification Process ....................................................... 54
Testing Refunds ....................................................................................................................... 54
Testing Account Check ............................................................................................................ 55
Further Information and Support ................................................................................................. 56
8.1
8.2
8.3
8.4
9
Invalid or incomplete XML Request ......................................................................................... 52
Testing............................................................................................................................................. 53
7.1
7.2
7.3
7.4
8
Transaction Reference ............................................................................................................. 50
Response Type ........................................................................................................................ 50
Error Code ................................................................................................................................ 50
Live Status................................................................................................................................ 50
Additional checks ..................................................................................................................... 51
Troubleshooting ............................................................................................................................. 52
6.1
7
Process Overview .................................................................................................................... 43
ACCOUNTCHECK XML Request ............................................................................................ 45
ACCOUNTCHECK XML Response ......................................................................................... 47
Best Practices ................................................................................................................................ 50
5.1
5.2
5.3
5.4
5.5
6
Process Overview .................................................................................................................... 31
REFUND XML Request ........................................................................................................... 33
REFUND XML Response......................................................................................................... 37
Account Check ............................................................................................................................... 43
4.1
4.2
4.3
5
Process Overview ...................................................................................................................... 8
AUTH XML Request ................................................................................................................. 10
AUTH XML Response .............................................................................................................. 23
Refund ............................................................................................................................................. 31
3.1
3.2
3.3
4
Parties Participating ................................................................................................................... 7
Pre-requisites ............................................................................................................................. 7
Secure Trading Support ........................................................................................................... 56
Secure Trading Sales ............................................................................................................... 56
Useful Documents .................................................................................................................... 56
Frequently Asked Questions .................................................................................................... 56
Appendix ......................................................................................................................................... 57
9.1
9.2
9.3
Pre-Authorisations and Final Authorisations MasterCard Europe Mandate ............................ 57
VISA Additional Authorisation Data Merchant Category Code (MCC 6012) ........................... 59
Settle Statuses ......................................................................................................................... 61
© Secure Trading Limited 2014
15 October 2014
Page 6 / 61
XML Specification
1
Introduction
This document describes the structure of XML Authorisation, Refund and Account Check
Requests to be sent through STPP, in order to process transactions with Secure Trading. Most
other request types that can be sent through the STPP share similarities with Authorisation,
Refund and Account Check Requests.
Of the fields outlined within this document, Secure Trading may add
additional fields and tags in the future; we would therefore recommend that
you do not build your application to only accept these tags.
Please note that the order of the tags cannot be guaranteed. Some tags may be
returned in a different order to the examples in this document.
1.1
Parties Participating
There are a number of participating parties when performing XML Requests through STPP.
These parties are listed below:
The Customer - The purchaser of goods or services.
The Merchant – Seller of goods or services.
Secure Trading – Facilitates the transaction.
The Acquiring Bank – Authorises and processes transactions on behalf of the merchant.
1.2
Pre-requisites
The pre-requisites that you will need to complete in order to begin processing payments through
STPP are outlined in this section of the document.
1.2.1
Internet Merchant Account
An Internet Merchant Account is required if you would like to process online e-commerce
transactions. Secure Trading have relationships in place with certain acquirers and will therefore
be able to assist you. For contact details of our sales team, please refer to section 8.1 Secure
Trading Support on page 56.
1.2.2
Secure Trading Account
In order to be able to set up your system around the XML Requests and Responses outlined
within this or any of the Secure Trading technical specifications, you will need to have an
account with Secure Trading. If you do not have an account, please contact our Sales team
(see section 8.2 Secure Trading Sales on page 56) who will inform you of the benefits of
setting up a Secure Trading account.
© Secure Trading Limited 2014
15 October 2014
Page 7 / 61
XML Specification
2
Authorisation
2.1
Process Overview
This section of the document will provide an overview of the process of performing an
authorisation and a breakdown of the parties affected.
If you wish to process an authorisation through Secure Trading’s systems,
then you will need to have a merchant account with an acquiring bank. If
you are unsure of this, please contact our support team (see section 8.1
Secure Trading Support on page 56).
The following is an overview of performing an Authorisation (AUTH) through STPP:
MERCHANT
SECURE TRADING
ACQUIRING BANK
CARD ISSUER
Step 1) The Merchant
submits an “AUTH” XML
Request to Secure
Trading.
Step 2) Secure Trading
validates the Request
and forwards details to
the Acquiring Bank using
a secure connection.
Step 3) The Acquiring
Bank will contact the
Card Issuer to perform
checks on the customer’s
payment details.
Step 4) The Card Issuer
performs various checks,
including AVS and CVV2
and decides to either
authorise or decline the
transaction.
Step 5) The Acquiring
Bank retrieves the
information from the Card
Issuer, and returns this to
Secure Trading.
Step 7) Merchant
receives an “AUTH” XML
Response from Secure
Trading and interprets
this Response.
MERCHANT
Step 6) Secure Trading
interprets response from
the Acquiring Bank.
Returns XML Response
to Merchant.
SECURE TRADING
© Secure Trading Limited 2014
ACQUIRING BANK
15 October 2014
CARD ISSUER
Page 8 / 61
XML Specification
Step 1 – Merchant submits XML Request to Secure Trading
The customer opts to make a payment. The merchant will submit an AUTH XML Request to
Secure Trading’s system with details of the transaction, such as the customer’s card details and
the amount.
Step 2 - Secure Trading contacts Acquiring Bank
Once the merchant’s XML Request has been validated, Secure Trading will securely contact the
merchant’s acquiring bank with details of the transaction.
Step 3 – Acquiring Bank contacts Card Issuer
The acquiring bank will then contact the customer’s card issuer to perform certain checks.
Step 4 – Card Issuer performs checks
The address and security code details provided by the customer are checked to see whether or
not they match those held by the card issuer (see section 2.3.5 for further details). The card
issuer then decides to either authorise or decline the transaction, and sends the results to the
Acquiring Bank.
Step 5 – Acquiring Bank returns response to Secure Trading
The acquiring bank retrieves the result from the card issuer and returns this to Secure Trading.
This includes details of whether the transaction was authorised or not by the card issuer.
Step 6 – Secure Trading returns XML Response to Merchant
Secure Trading will then interpret the response from the acquiring bank, and return an XML
Response to the merchant.
Step 7 – Merchant interprets XML Response
The merchant receives an XML Response from Secure Trading. This response will include a
transactionreference which relates to the individual authorisation. This should be retained
by the merchant as the transactionreference field is used to query, update and refund
authorised transactions. Please refer to section 5 Best Practices for checks you should
perform on XML Responses returned from Secure Trading.
© Secure Trading Limited 2014
15 October 2014
Page 9 / 61
XML Specification
2.2
AUTH XML Request
In order to successfully process an Authorisation Request, the XML submitted by the merchant
to Secure Trading must follow the formatting outlined in this section of the document.
2.2.1
AUTH XML Request Overview
The following diagram shows a standard e-commerce authorisation. Each child element is
outlined in greater detail within this section of the document.
alias
request type = “AUTH”
operation
merchant
billing
customer
settlement
+
+
+
+
+
An <alias> tag is included for each request. The value is dependent on how the
merchant has integrated with Secure Trading. For more information, refer to the
setup guide of the solution used (see section 8.3 Useful Documents on page
56).
Please note that elements submitted in the XML Request must have a value
length less than or equal to the length assigned in the parameter tables. Longer
field submissions will either be processed in a truncated form or cause an invalid
field error (‘30000’).
© Secure Trading Limited 2014
15 October 2014
Page 10 / 61
XML Specification
2.2.2
<operation>
request type = “AUTH”
+
operation
+
accounttypedescription
authmethod
parenttransactionreference
sitereference
The <operation> tag contains two mandatory elements, both of which are outlined in the
following table.
You can use the parenttransactionreference element to perform an
authorisation with a card that has previously been processed through your system
(for more information, see section 2.2.8 on page 20).
Tag
operation
accounttype
description
Type
an
Length
20
Required
Y
Y
authmethod
an
5
N
parent
transaction
reference
an
25
N
sitereference
an
50
Y
© Secure Trading Limited 2014
15 October 2014
Comment
The source of the transaction.
For an e-commerce AUTH Request,
the value should be “ECOM”.
For Mail Order or Telephone Order
(MOTO) requests, the value should
be “MOTO”.
For a recurring transaction, the value
should be “RECUR”.
Either “PRE” or “FINAL”.
See section 9.1 for further details.
Here would be the reference of a
previous transaction.
If the currency is submitted in a
child XML Request, it must be the
same value as the parent
transaction.
The site reference relates to your
individual account which you
received on setup. If you do not know
your Site Reference, please contact
Support (see section 8.1).
Page 11 / 61
XML Specification
2.2.3
<merchant>
request type = “AUTH”
+
merchant
+
email
orderreference
As the <merchant> tag is not mandatory for a standard e-commerce Authorisation request,
both its child elements are also optional.
Tag
merchant
Type
Length
Required
N
email
an
255
N
order
reference
an
255
N
© Secure Trading Limited 2014
15 October 2014
Comment
The merchant’s email address.
Maximum length of 255 (maximum of
64 characters before the”@” symbol).
Your unique order reference that can
be stored on Secure Trading’s
system.
Note: This can be updated at a later
time (only if transaction is pending
settlement). Please refer to the
Transaction Update document.
Page 12 / 61
XML Specification
2.2.4
<billing>
The <billing> tag has two child tags in addition to nine elements. The child elements are
<name> and <payment> and are outlined in sections 2.2.4.1 <name> on page 15 and 2.2.4.2
<payment> on page 16.
The following diagram provides an overview of the <billing> tags:
request type = “AUTH”
+
billing
+
premise
street
county
country
email
name
payment
+
+
postcode
town
amount currencycode=””
telephone type=””
Secure Trading recommends that you submit the <premise> and the
<postcode> in the AUTH Request, as these fields are forwarded onto your
acquiring bank to check that they match those that the card is registered against.
Please refer to the STPP AVS & CVV2 document (see section 8.3 Useful
Documents on page 56) for more information.
© Secure Trading Limited 2014
15 October 2014
Page 13 / 61
XML Specification
The fields included within the <billing> tags are outlined in the following table:
Tag
billing
Type
Length
Required
Y
premise
an
25
N
street
an
127
N
town
an
127
N
county
an
127
N
country
an
2
N
postcode
an
25
N
email
an
255
N
amount
currencycode=
””
an
3
Y
amount
n
11
Y
telephone
type=””
an
1
C
telephone
an
15
C
© Secure Trading Limited 2014
15 October 2014
Comment
The house number or first line of the
customer’s billing address.
The street entered for the customer’s
billing address.
The town entered for the customer’s
billing address.
The county entered for the
customer’s billing address (see
section 2.2.7 Additional Validation
on page 20).
The country for the customer’s billing
address.
This will need to be in ISO2A format.
For a list of country codes, see
http://webapp.securetrading.net/coun
trycodes.html
The postcode entered for the
customer’s billing address (see
section 2.2.7 Additional Validation
on page 20).
The customer’s billing email address.
Maximum length of 255 (maximum of
64 characters before the”@” symbol).
The currency that the transaction will
be processed in. There is a list of
available currencies on our website
(http://webapp.securetrading.net/curr
encycodes.html).
The amount of the transaction should
be in base units, with no commas or
decimal points, so £10 would be
1000. This value must be greater
than zero.
The type of telephone number. The
options available are:
H = Home
M = Mobile
W = Work
Only required if telephone is
included.
The customer’s telephone number.
Valid characters:
Numbers 0-9
Spaces
Special characters: + - ( )
Only required if telephone type is
included.
Page 14 / 61
XML Specification
2.2.4.1 <name>
request type = “AUTH”
+
billing
+
name
prefix
first
middle
last
suffix
All elements within the <name> tag are optional. The table below contains more information
regarding the data that can be contained within these elements.
It is imperative that the name details should match those on the card.
Tag
billing
name
Type
Length
Required
Y
N
prefix
an
25
N
The prefix of the customer’s billing
name (e.g. Mr,Miss,Dr).
first
an
127
N
The customer’s billing first name.
middle
an
127
N
The customer’s billing middle
name(s).
last
an
127
N
The customer’s billing last name.
suffix
an
25
N
The customer’s suffix of the billing
name (e.g. Bsc).
© Secure Trading Limited 2014
15 October 2014
Comment
Page 15 / 61
XML Specification
2.2.4.2 <payment>
request type = “AUTH”
+
+
billing
payment
+
pan
expirydate
securitycode
The following table includes a breakdown of all the fields that are or can be included within the
<payment> tags.
Tag
billing
payment
type = “”
Type
Length
Required
Y
an
20
Y
pan
n
12-19
Y
expirydate
an
7
Y
security
code
n
4
N
Comment
The customer’s card type, for
example VISA or MASTERCARD.
This is the card number printed on
the front of the customer’s card.
The expiry date printed on the card.
This needs to be submitted in the
format MM/YYYY.
These relate to the three (four for
AMEX) digit security code, printed on
the back of the card.
This field is not a required field by
STPP, although some banks do
require it.
Secure Trading recommends that you include the <securitycode> as it is
submitted to your acquiring bank and then checked against the actual security
code of the card to help prevent fraud. The result of this check is then returned to
you in the XML Response (see section 2.3.5).
Please refer to the STPP AVS & CVV2 document (see section 8.3 Useful
Documents on page 56) for more information.
Please note that Secure Trading will determine the payment type based on the
pan.
© Secure Trading Limited 2014
15 October 2014
Page 16 / 61
XML Specification
2.2.5
<customer>
request type=”AUTH”
+
customer
+
telephone type=””
email
forwardedip
ip
premise
street
county
country
postcode
town
name
+
The <billing> tags include information on whoever is paying for the goods, while the
<customer> tags are optional and include information of whoever is receiving the goods. In
many cases, these are the same person, but not always.
The <billing> tags are important because the address details are checked against the details
of the card on authorisation, but the <customer> tags can also be used in additional fraud
checks.
The <customer> tag has a child <name> tag. The <name> tag contains elements in exactly the
same format as those found in the <billing> tag, explained in section 2.2.4.1.
In order to reduce fraud, VISA has mandated that UK-based merchants with
a Merchant Category Code (MCC) of 6012 are required to send additional
fields in the <customer> tag of AUTH XML Requests, if provided by the
customer making the payment.
Your MCC is a four-digit number assigned to you by your acquirer. It is used to
classify the business by the type of products or services it provides. If you are
unsure of the value of your merchant category code, please contact Secure
Trading Support (section 8.1).
Please refer to section 9.2 for further details and a full XML example.
© Secure Trading Limited 2014
15 October 2014
Page 17 / 61
XML Specification
Tag
customer
telephone
type=””
Type
Length
Required
Comment
N
an
1
C
telephone
an
15
C
email
an
255
N
forwardedip
an
15
N
ip
an
15
N
premise
an
25
N
street
town
an
an
127
127
N
N
county
an
127
N
country
an
2
C
The type of telephone number. The
options available are:
H = Home
M = Mobile
W = Work
Only required if telephone number is
included.
The customer’s telephone number.
Requires telephone type if included.
Valid characters:
Numbers 0-9
Spaces
Special characters: + - ( )
Required if telephone type is
included.
The customer’s email address.
Maximum length of 255 (maximum of
64 characters before the”@” symbol).
Customer Forwarded IP address, as
provided by a proxy server if
available.
The IP of the customer.
The customer address premise
(house name or number).
The customer address street name.
The town of the customer address.
The customer county (see section
2.2.7 Additional Validation on page
20).
The country for the customer’s billing
address.
This will need to be in ISO2A format.
For a list of Country Codes, see
http://webapp.securetrading.net/coun
trycodes.html
Only required if Merchant Category
Code (MCC) is 6012 and payment
type is VISA. See section 9.2 for
more information.
Customer address postcode (see
section 2.2.7 Additional Validation
on page 20).
postcode
© Secure Trading Limited 2014
an
25
C
15 October 2014
Only required if Merchant Category
Code (MCC) is 6012 and payment
type is VISA. See section 9.2 for
more information.
Page 18 / 61
XML Specification
2.2.6
<settlement>
request type = “AUTH”
+
settlement
+
settlestatus
settleduedate
Settlement is a process that follows authorisation. Secure Trading submit a file to the acquiring
bank, requesting that authorised funds are transferred into your bank account. You can defer
these transactions if you wish by submitting a specific date in the settleduedate field.
Please note that although you can specify when a payment is to be taken, (for
example, 3 days after submitting the request), you cannot specify a date that is
more than 7 days in the future. The reason for this is that the authorisation for a
transaction is no longer valid after seven days.
Tag
settlement
settleduedate
settlestatus
© Secure Trading Limited 2014
Type
an
n
Length
10
3
Required
N
Comment
N
Here you can set which day in the
future you wish for your transaction
to settle.
It must be in the format YYYY-MMDD.
N
This value relates to the status you
would like to set the transaction.
The possible values are:
0 – Pending Settlement
2 – Suspended.
100 – Settled (this is only available
for certain acquirers).
If this is not set, status is
automatically set to 0.
15 October 2014
Page 19 / 61
XML Specification
2.2.7
Additional Validation
2.2.7.1 <postcode>
If included within the request, validation is performed on the postcode.
Please note that postcode validation is dependent on the country supplied. If
no country is supplied, then no additional validation is performed.
The following table outlines the format the postcode needs to be in when it is submitted to
Secure Trading.
T represents Text (A-Z or a-z) and N represents Number (0-9):
Country
United States
(US)
Great Britain
(GB)
Canada (CA)
Other
Validation
Needs to be a 5 or 9 digit zip code.
Needs to be between 6 and 8 characters long, including spaces.
Can be one of the following formats:
TN NTT
TNT NTT
TNN NTT
TTN NTT
TTNN NTT
TTNT NTT
Needs to be 6 or 7 digits long, including spaces.
Can be one of the following formats:
TNT NTN
TNTNTN
The format of postcodes for other countries is not validated by
Secure Trading.
2.2.7.2 <county>
If the country is entered and is United States (US), the county field needs to be a valid twodigit state code (e.g. “NY” for New York). For a list of US state codes, see:
http://webapp.securetrading.net/usstatecodes.html
© Secure Trading Limited 2014
15 October 2014
Page 20 / 61
XML Specification
2.2.8
Repeat Payments (Tokenisation)
You are able to re-use details of a previous transaction through Secure Trading’s servers to
perform subsequent requests. You do not need to store any card details on your system, if you
would like to take multiple payments from a customer.
Secure Trading refers to the initial transaction as the parent transaction. Subsequently,
transactions that refer to the parent are called child transactions.
The XML for the child request follows the same specification as a standard Authorisation.
However, the parenttransactionreference tag is now mandatory:
request type = “AUTH”
+
operation
+
accounttypedescription
authmethod
parenttransactionreference
sitereference
Within the parenttransactionreference tag will be the reference to the parent
transaction. As the parenttransactionreference is used to inherit details from the
previous transaction, the <billing> tags are no longer mandatory. However, tags can be
included if the merchant wishes to override any of the stored data (e.g. updating the expiry date
or address details).
Please note that the address details for the parent will only be referred to if no
address details are included within the child request. If one address field is
included within the child request, all address details of the parent are ignored.
Please note that child transactions cannot override the currency of a parent.
© Secure Trading Limited 2014
15 October 2014
Page 21 / 61
XML Specification
2.2.9
AUTH XML Request Example
The following is an example of an AUTH XML Request.
<requestblock version="3.67">
<alias>site12345</alias>
<request type="AUTH">
<merchant>
<orderreference>AUTH_VISA</orderreference>
</merchant>
<customer>
<town>Bangor</town>
<name>
<middle>Mary</middle>
<prefix>Miss</prefix>
<last>Smith</last>
<first>Joanne</first>
</name>
<ip>1.2.3.4</ip>
<telephone type="H">1111111111</telephone>
<street>Second Street</street>
<postcode>CU888ST</postcode>
<premise>111</premise>
</customer>
<billing>
<telephone type="M">0777777777</telephone>
<county>Gwynedd</county>
<street>Test Street</street>
<postcode>TE45 6ST</postcode>
<premise>789</premise>
<payment type="VISA">
<expirydate>10/2031</expirydate>
<pan>4111110000000211</pan>
<securitycode>123</securitycode>
</payment>
<town>Bangor</town>
<name>
<middle>joe</middle>
<prefix>Dr</prefix>
<last>bloggs</last>
<suffix>Jr.</suffix>
<first>fred</first>
</name>
<country>GB</country>
<amount currencycode="GBP">100</amount>
<email>[email protected]</email>
</billing>
<operation>
<sitereference>site12345</sitereference>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
</request>
</requestblock>
© Secure Trading Limited 2014
15 October 2014
Page 22 / 61
XML Specification
2.3
AUTH XML Response
Following processing an Authorisation (AUTH) XML Request, Secure Trading will return an
AUTH XML Response. The XML will be made up of the tags outlined within this section of the
document. The fields are based on that of a successful response, not an error or a decline.
2.3.1
AUTH XML Response Overview
requestreference
response type = “AUTH”
+
authcode
timestamp
live
transactionreference
merchant
security
settlement
billing
operation
+
+
+
+
+
error
+
acquirerresponsecode
acquirerresponsemessage
The responseblock returned will contain a unique element called a requestreference and
a response type = “AUTH” tag.
2.3.2
<requestreference>
This is an internal field generated by Secure Trading. It must not be validated. If problems are
experienced with the request this field may be requested by Secure Trading support to aid in
determining the cause.
© Secure Trading Limited 2014
15 October 2014
Page 23 / 61
XML Specification
2.3.3
<response type = “AUTH”>
This tag contains six elements (without child tags), the details of which are in the following table.
There are also an additional six tags that contain further child tags, outlined in greater detail
after the table.
Tag
Type
Length
Required
authcode
an
255
Y
timestamp
an
19
Y
live
n
1
Y
transaction
reference
an
25
Y
acquirerresponse
code
an
255
C
acquirerresponse
message
an
255
C
© Secure Trading Limited 2014
15 October 2014
Comment
The authorisation code provided by
the Issuing Bank, this is generated by
the Issuing Bank, and will differ
pending on which bank you use.
The timestamp relates to the time of
the individual transaction. It will be in
the format:
“0000-00-00 00:00:00”
This will indicate if the account is live
or in test. If the transaction was a live
one, it will return a 1, whereas for test
transactions the value will be a 0.
A unique Secure Trading reference
for the transaction.
You will need to store this if you wish
to perform any additional request
such as a refund on the transaction.
Additionally, it can then be used for
any future correspondence with
Secure Trading.
This will only be returned if supplied
by the merchant’s Acquirer.
The corresponding message to the
above code.
Will only be returned if supplied by
the merchant’s acquirer.
Page 24 / 61
XML Specification
2.3.4
<merchant>
response type = “AUTH”
+
merchant
+
merchantnumber
orderreference
tid
merchantcategorycode
merchantname
merchantcity
merchantstatecode
merchantzipcode
merchantcountryiso2a
The following fields can be returned in the <merchant> tag:
Tag
merchant
Type
Length
Required
Y
merchant
number
an
10
Y
order
reference
an
255
N
tid
an
255
N
an
255
N
an
255
N
an
127
N
an
127
N
merchant
zipcode
an
10
N
merchant
countryiso2a
an
2
N
merchant
categorycode
merchant
name
merchant
city
merchant
state
code
© Secure Trading Limited 2014
15 October 2014
Comment
The Merchant Number that was used
to process the transaction. Provided
by the acquiring bank.
This will match the order reference
supplied within your initial request.
The Terminal ID used to process the
transaction, this is accredited to your
merchant number when we setup
your account in our systems.
The merchant category code that
was used to process the AUTH.
The merchant name that was used to
process the AUTH.
The merchant city that was used to
process the AUTH (if applicable).
The merchant state code that was
used to process the AUTH (if
applicable).
The merchant zip/post code that was
used to process the AUTH (if
applicable).
The merchant country that was used
to process the AUTH (if applicable).
Page 25 / 61
XML Specification
2.3.5
<security>
response type = “AUTH”
+
security
address
postcode
securitycode
The <security> tags within an XML Response provide the results of checks performed by
your acquiring bank on the customer’s address and security code. Please refer to the STPP
AVS & CVV2 document (see section 8.3 Useful Documents on page 56) for more information.
The responses follow this key:
Security responses
Description
0
“Not Given”
1
“Not Checked”
2
“Matched”
4
“Not Matched”
Comment
You did not provide the acquiring bank the
information required to perform this check, in the
XML Request.
The acquiring bank did not perform this check on
the information you provided in the XML Request.
The information you provided in the XML Request,
matches the information obtained by the acquiring
bank, from the customer’s payment issuer.
The information you provided in the XML Request,
does not match the information obtained by the
acquiring bank, from the customer’s payment
issuer.
These are the child elements returned in the <security> tag, in the XML Response:
Tag
security
Type
Length
Required
Y
address
n
1
Y
postcode
n
1
Y
securitycode
n
1
Y
2.3.6
Comment
The result of the Address Verification
System checks performed on
authorisation.
The result of the postcode check
performed on authorisation.
The result of the security code check
performed on authorisation.
<settlement>
+
response type = “AUTH”
settlement
+
settleduedate
settlestatus
The <settlement> tag will contain information detailing the status of a transaction with the
settlement date.
© Secure Trading Limited 2014
15 October 2014
Page 26 / 61
XML Specification
Tag
settlement
Type
Length
Required
Y
settleduedate
an
10
Y
settlestatus
n
3
Y
2.3.7
Comment
The date the transaction is due to
settle. This is only relevant if the
settlestatus is 0 or 1. Will be in
the format YYYY-MM-DD.
The current status of transaction at
the end of the request.
<billing>
response type = “AUTH”
+
+
billing
payment type=””
issuercountry
pan
amount currencycode=””
issuer
The billing tags returned will include the transaction type supplied within the original
authorisation.
Tag
billing
payment
type=””
Type
Length
Required
Y
an
20
Y
an
2
Y
an
255
C
an
12-19
Y
amount
currencycode=
””
an
3
Y
amount
n
11
Y
issuer
country
issuer
pan
© Secure Trading Limited 2014
15 October 2014
Comment
The type of payment processed, for
example “VISA” or “MASTERCARD”.
The country for the customer’s card
issuer.
This will be in ISO2A format. For a
list of Country Codes, see
http://webapp.securetrading.net/coun
trycodes.html.
This will be returned if the data is
available.
The customer’s card issuer.
This will be returned if the data is
available.
The first six and last four digits of the
card. The rest of the card details are
not shown and obscured with #.
For example 411111######0211.
The currency that the transaction
was processed in. There is a list of
available currencies on our website
(http://webapp.securetrading.net/curr
encycodes.html)
The amount of the transaction in
base units, with no commas or
decimal points, so £10 would be
1000.
Page 27 / 61
XML Specification
2.3.8
<operation>
response type = “AUTH”
+
operation
accounttypedescription
authmethod
For a standard e-commerce authorisation, the operation tags returned will include the
account type specified in the Authorisation Response.
Tag
operation
Type
Length
Required
Y
accounttype
description
an
20
Y
authmethod
an
5
N
© Secure Trading Limited 2014
15 October 2014
Comment
This will match the account type
description supplied within the
request (e.g. “ECOM”).
Either “PRE” or “FINAL”. See section
9.1 for further information. Only
returned if a value was sent to the
acquirer by Secure Trading during
authorisation.
Page 28 / 61
XML Specification
2.3.9
<error>
response type = “AUTH”
+
error
+
code
message
The error code should be used to determine if the request was successful or not.
If the error code is 0 then the transaction was successful.
If the error code is not 0 then the transaction was not successful.
An error code of 99999 represents an unknown error that can happen during
a request and requires manual investigation to determine the state of the
transaction. Please contact support (see section 8.1 Secure Trading
Support).
For a full list of error codes and error messages please see:
http://webapp.securetrading.net/errorcodes.html
Tag
error
Type
Length
Required
Y
code
n
5
Y
message
an
255
Y
data
an
255
N
Comment
The code will be 0 if the transaction
was successful.
This is the corresponding message to
the above code.
Additional information to help
troubleshoot the error.
This tag contains one or more child
elements.
If the error code is ‘30000’ (Field
Error) then this field will contain the
field (or fields) which caused the
error.
2.3.10
<other>
The <other> tag may appear in the XML Response. The contents of the <other> tag are
undefined and can be ignored unless specified otherwise by Secure Trading and your acquirer,
for a specific reason.
Please allow for any number of elements to be returned in the <other> tag,
containing any length of data.
© Secure Trading Limited 2014
15 October 2014
Page 29 / 61
XML Specification
2.3.11
AUTH XML Response Example
The following is an example of an AUTH XML Response.
<responseblock version="3.67">
<requestreference>X6mh36u8g</requestreference>
<response type="AUTH">
<merchant>
<merchantname>example UNICODE merchantname</merchantname>
<orderreference>AUTH_VISA</orderreference>
<tid>27882788</tid>
<merchantnumber>00000000</merchantnumber>
<merchantcountryiso2a>GB</merchantcountryiso2a>
</merchant>
<transactionreference>17-9-5</transactionreference>
<security>
<postcode>2</postcode>
<securitycode>2</securitycode>
<address>2</address>
</security>
<billing>
<amount currencycode="GBP">100</amount>
<payment type="VISA">
<issuer>Test Issuer</issuer>
<issuercountry>ZZ</issuercountry>
<pan>411111######0211</pan>
</payment>
<dcc enabled="0"/>
</billing>
<authcode>TEST</authcode>
<timestamp>2012-10-08 12:46:02</timestamp>
<settlement>
<settleduedate>2012-10-08</settleduedate>
<settlestatus>0</settlestatus>
</settlement>
<live>0</live>
<error>
<message>Ok</message>
<code>0</code>
</error>
<acquirerresponsecode>00</acquirerresponsecode>
<operation>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
</response>
</responseblock>
© Secure Trading Limited 2014
15 October 2014
Page 30 / 61
XML Specification
3
Refund
3.1
Process Overview
This section of the document will provide an overview of the process of performing a refund and
a breakdown of the parties affected.
3.1.1
CFT Refunds
If enabled on your Secure Trading account, CFT (Cardholder Funds Transfer) refunds allow for
refunding transactions for greater than the original amount authorised against the card.
Please note that in order to process CFT refunds on your account, you will need to
have a CFT merchant number present.
For more information, please contact your acquiring bank.
Please note that for CFT refunds, the <accounttypedescription> field
under <operation> will always be “CFT”.
CFT Refunds can also be used to refund onto cards without an original authorisation. This can
be achieved by submitting a refund as outlined in this section of the document, including the
card details within the <billing> tags.
In order to successfully refund onto a card that has not been previously
processed on your account, please ensure you are following the correct
guidelines outlined by the card issuer and your acquiring bank. You will
need to contact your acquirer in order to clarify this.
3.1.2
Process Overview
The following is an overview of performing a Refund through STPP.
© Secure Trading Limited 2014
15 October 2014
Page 31 / 61
XML Specification
MERCHANT
SECURE TRADING
ACQUIRING BANK
CARD ISSUER
Step 1) The Merchant
submits a “REFUND”
XML Request to Secure
Trading.
Step 2) Secure Trading
validates the Request
and forwards details to
the Acquiring Bank using
a secure connection.
Step 3) The Acquiring
Bank will contact the
Card Issuer.
Step 4) The Customer’s
Card Issuer receives the
request. A decision is
made to issue a refund
and submit a response to
the Acquiring Bank
Step 5) The Acquiring
Bank will respond to
SecureTrading with
details of the refund.
Step 6) Secure Trading
interprets response from
the Acquiring Bank.
Returns XML Response
to Merchant.
Step 7) Merchant
receives a “REFUND”
XML Response from
Secure Trading and
interprets this Response.
MERCHANT
SECURE TRADING
© Secure Trading Limited 2014
ACQUIRING BANK
15 October 2014
CARD ISSUER
Page 32 / 61
XML Specification
Step 1 - Merchant Submits XML Request
Once the merchant determines that they wish to perform a refund back onto their customer’s
card, they will submit a REFUND XML Request to Secure Trading. The XML Request will
contain the transaction reference of a previous authorisation, this will be within the
<parenttransactionreference> tag.
If the currency is submitted in a child transaction, it must be the same value
as the parent transaction.
Step 2 - Secure Trading contacts Acquirer
Secure Trading will receive a REFUND Request from the merchant. It will be validated against
the original authorisation before submitting to the acquirer for authorisation.
Step 3 – Acquirer contacts Card Issuer
The acquirer contacts the card issuer to request a refund to be processed.
Step 4 – Card Issuer receives the request and processes a refund
The card issuer receives the request and decides to issue a refund. A response is returned to
the acquiring bank with the result of the refund request.
Step 5 – Acquiring Bank responds to Secure Trading
The acquiring bank returns the result of the refund request to Secure Trading.
Step 6 – Secure Trading returns XML Response to Merchant
Secure Trading interprets the response and submits the refund XML response to the merchant.
Step 7 – Merchant receives response from Secure Trading
The merchant interprets the response received and stores it in their system for future reference.
3.2
REFUND XML Request
In order to successfully process a Refund Request, the XML submitted by the merchant to the
Secure Trading must follow the formatting outlined in this section of the document.
3.2.1
REFUND XML Request Overview
The following is an overview of an XML Refund Request:
alias
request type = “REFUND”
operation
merchant
+
+
billing currencycode = ””
© Secure Trading Limited 2014
15 October 2014
+
Page 33 / 61
XML Specification
3.2.2
<merchant>
+
request type = “REFUND”
merchant
+
email
orderreference
Tag
merchant
Type
Length
Required
N
email
an
255
N
order
reference
an
255
N
Comment
The merchant’s email address.
Maximum length of 255 (maximum of
64 characters before the”@” symbol).
Your unique order reference that can
be stored on Secure Trading’s
system.
If this is not submitted, it is inherited
from the initial authorisation.
Note: This can be updated at a later
time (only if transaction is pending
settlement). Please refer to the
Transaction Update document.
© Secure Trading Limited 2014
15 October 2014
Page 34 / 61
XML Specification
3.2.3
<operation>
+
request type = “REFUND”
operation
+
accounttypedescription
parenttransactionreference
sitereference
Tag
operation
Type
Length
Required
Y
accounttype
description
an
20
Y
parent
transaction
reference
an
25
Y
sitereference
an
50
Y
© Secure Trading Limited 2014
15 October 2014
Comment
This will match the account type
description supplied within the
request – ECOM.
For CFT refunds, this value will be
CFT.
This field must contain the
transaction reference of the
authorised transaction that you wish
to Refund.
For CFT refunds where there is no
previous authorisation, this field can
be omitted.
The site reference relates to your
individual account which you will
receive on setup. If you do not know
your Site Reference, please contact
support (see section 8.1 Secure
Trading Support on page 56).
Page 35 / 61
XML Specification
3.2.4
<billing>
+
request type = “REFUND”
Tag
billing
currencycode=””
amount
billing currencycode = ””
Type
Length
Required
an
3
Y
n
11
Y
+
amount
Comment
The currency you wish to perform the
refund in. There is a list of available
currencies on our website
(http://webapp.securetrading.net/curr
encycodes.html)
The amount of the transaction in
base units, with no commas or
decimal points. For example, £10
needs to be set as 1000.
If this field is not present then the full
amount of the transaction will be
refunded.
Please note that for CFT refunds where there has been no previous transaction,
the merchant can submit the details of the card they wish to pay onto in these
<billing> tags. The fields to be included are the same as those outlined in
section 2.2.4.2 <payment> on page 16.
3.2.5
REFUND XML Request Example
The following is an example XML of a REFUND Request:
<requestblock version="3.67">
<alias>site12345</alias>
<request type="REFUND">
<merchant>
<orderreference>REFUND_VISA</orderreference>
</merchant>
<operation>
<sitereference>site12345</sitereference>
<parenttransactionreference>17-9-5</parenttransactionreference>
</operation>
</request>
</requestblock>
© Secure Trading Limited 2014
15 October 2014
Page 36 / 61
XML Specification
3.3
REFUND XML Response
In this section of the document is a breakdown of the XML Response for a Refund Request that
will be received by the merchant. The fields are based on that of a successful response, not an
error or a declined refund.
3.3.1
REFUND XML Response Overview
The following is a diagrammatic representation of the XML Response to a REFUND Request.
requestreference
response type =
“REFUND”
+
authcode
timestamp
live
transactionreference
merchant
security
settlement
billing
operation
error
+
+
+
+
+
+
The responseblock returned will contain a unique element called a requestreference and
a response type = “REFUND” tag.
3.3.2
<requestreference>
This is an internal field generated by Secure Trading. It must not be validated. If problems are
experienced with the request this field may be requested by Secure Trading support to aid in
determining the cause.
© Secure Trading Limited 2014
15 October 2014
Page 37 / 61
XML Specification
3.3.3
<response type = “REFUND”>
This tag contains four elements (without child tags), the details of which are in the following
table. There are also an additional six tags that contain further child tags, outlined in greater
detail after the table.
Tag
Type
Length
Required
authcode
an
255
Y
timestamp
an
19
Y
live
n
1
Y
transaction
reference
an
25
Y
3.3.4
Comment
Authorisation code if provided by the
acquirer.
The timestamp relates to the time of
the individual transaction.
It will be in the format:
“0000-00-00 00:00:00”
0 equals test transaction, 1 equals
live transaction.
A unique Secure Trading reference
for the transaction.
<merchant>
response type =
“REFUND”
+
merchant
+
merchantnumber
orderreference
tid
The following fields can be returned within the merchant tag:
Tag
merchant
Type
Length
Required
Y
merchant
number
an
10
Y
order
reference
an
255
N
tid
an
255
N
© Secure Trading Limited 2014
15 October 2014
Comment
This will be the merchant number
that has been provided to Secure
Trading to process on-line
transactions on your account.
This will match the order reference
supplied within your initial request.
The Terminal ID used to process the
transaction. This is accredited to your
merchant number when we setup
your account in our systems.
Page 38 / 61
XML Specification
3.3.5
<billing>
response type =
“REFUND”
+
billing
+
payment type=””
issuercountry
pan
amount currencycode=””
issuer
The <billing> tags returned will include the transaction type supplied within the original
authorisation.
Tag
billing
payment
type=””
Type
Length
Required
Y
an
20
Y
an
2
Y
an
255
C
an
12-19
Y
amount
currencycode=
””
an
3
Y
amount
n
11
Y
issuer
country
issuer
pan
3.3.6
Comment
The type of payment processed, for
example “VISA” or “MASTERCARD”.
The country for the customer’s card
issuer address.
This will need to be in ISO2A format.
For a list of Country Codes, see
http://webapp.securetrading.net/coun
trycodes.html.
This will be returned if the data is
available.
The issuer for the customer’s card.
This will be returned if the data is
available.
The first six and last four digits of the
card that was refunded. The rest of
the card details are not shown and
obscured with #.
For example
411111######0211.
The currency that the refund was
processed in. There is a list of
available currencies on our website
(http://webapp.securetrading.net/curr
encycodes.html)
The amount refunded in base units,
with no commas or decimal points,
so £10 would be 1000.
<security>
These tags follow the same convention as those outlined in section 2.3.5 <security>. For
refunds, they will most likely be a 0 for each check as the details aren’t usually submitted for
refunds.
© Secure Trading Limited 2014
15 October 2014
Page 39 / 61
XML Specification
3.3.7
<settlement>
response type =
“REFUND”
+
settlement
+
settleduedate
settlestatus
Tag
settlement
Type
Length
Required
Y
settleduedate
an
10
Y
settlestatus
an
3
Y
3.3.8
Comment
The date that the transaction is due
to settle. Will be in the format
YYYY-MM-DD.
The current settle status of
transaction at the end of the request.
<operation>
response type =
“REFUND”
+
operation
+
accounttypedescription
parenttransactionreference
Tag
operation
Type
Length
Required
Y
accounttype
description
an
20
Y
parent
transaction
reference
an
25
Y
© Secure Trading Limited 2014
15 October 2014
Comment
This will match the account type
description supplied within the
request – ECOM.
A unique Secure Trading reference
for the parent transaction. Within a
Refund Response, this relates to the
transaction you have refunded.
Page 40 / 61
XML Specification
3.3.9
<error>
response type =
“REFUND”
+
error
+
code
message
The error code should be used to determine if the individual requests were successful or not.
If the error code is 0 then the transaction was successful.
If the error code is not 0 then the transaction was not successful.
An error code of 99999 represents an unknown error that can happen during
a request and requires manual investigation to determine the state of the
transaction. Please contact support (see section 8.1 Secure Trading
Support).
For a full list of error codes and error messages please see:
http://webapp.securetrading.net/errorcodes.html
Tag
error
Type
Length
Required
Y
code
n
5
Y
message
an
255
Y
data
an
255
N
Comment
The code will be 0 if the refund was
processed successfully.
This is the corresponding message
to the above code.
Additional information to help
troubleshoot the error.
This tag contains one or more child
elements.
If the error code is ‘30000’ (Field
Error) then this field will contain the
field (or fields) which caused the
error.
© Secure Trading Limited 2014
15 October 2014
Page 41 / 61
XML Specification
3.3.10
REFUND XML Response Example
The following is an example XML of a REFUND Response:
<responseblock version="3.67">
<requestreference>Xk3mvyk5v</requestreference>
<response type="REFUND">
<merchant>
<merchantname>example UNICODE merchantname</merchantname>
<orderreference>REFUND_VISA</orderreference>
<tid>27882788</tid>
<merchantnumber>00000000</merchantnumber>
<merchantcountryiso2a>GB</merchantcountryiso2a>
</merchant>
<transactionreference>17-9-12</transactionreference>
<billing>
<amount currencycode="GBP">100</amount>
<payment type="VISA">
<issuer>Test Issuer</issuer>
<issuercountry>ZZ</issuercountry>
<pan>411111######0211</pan>
</payment>
<dcc enabled="0"/>
</billing>
<authcode>TEST REFUND ACCEPTED</authcode>
<live>0</live>
<error>
<message>Ok</message>
<code>0</code>
</error>
<timestamp>2012-10-08 12:46:11</timestamp>
<acquirerresponsecode>00</acquirerresponsecode>
<security>
<address>2</address>
<postcode>2</postcode>
<securitycode>0</securitycode>
</security>
<settlement>
<settleduedate>2012-10-08</settleduedate>
<settlestatus>0</settlestatus>
</settlement>
<operation>
<parenttransactionreference>17-9-5</parenttransactionreference>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
</response>
</responseblock>
© Secure Trading Limited 2014
15 October 2014
Page 42 / 61
XML Specification
4
Account Check
4.1
Process Overview
An Account Check Request allows a card to be validated by checking the account’s address,
security code (CVV2), to ensure the details entered by the customer are valid.
Please note that the checks performed on an Account Check Request are the
same as those carried out on a regular e-commerce Authorisation (AUTH)
Request. No funds will be reserved as part of an Account Check.
4.1.1
Requirements
The following requirements must be met to be able to process Account Checks.
4.1.1.1 Acquiring Banks
Account Checks are only available for certain Acquiring Banks. Please contact the Secure
Trading support team for more details (see section 8.1 Secure Trading Support).
4.1.1.2 Multi-Process Request
A Multi-Process Request is when multiple request types are submitted in a single XML Request
to Secure Trading. If the Account Check is sent as part of a Multi-Process Request, it must be
before an Authorisation Request in the sequence. E.g. Below is an outline of an XML MultiProcess Request.
<?xml version='1.0' encoding='utf-8'?>
<requestblock version="3.67">
<alias>site12345</alias>
<request type="ACCOUNTCHECK">
…
</request>
<request type="AUTH">
…
</request>
</requestblock>
4.1.2
Using Account Check as a Parent Transaction
In some cases, by sending the transaction reference of a pre-existing Account Check (a parent
transaction) in the parenttransactionreference field of a new request, it is possible for
this new request to inherit billing and payment details from the Account Check. This is possible
when the new request has the following request type(s):
Request Type
AUTH
ORDER
RISKDEC
STORE
THREEDQUERY
Description
Used to process an Authorisation Request
Used to process a PayPal Request
Used to process a Risk Decision Request
Used to process a Card Store Request
Used to process a 3D Query Request
For information on the use of the request types listed above, please refer to section 8.3 Useful
Documents for links to relevant documentation.
For information on using Account Checks with other request types that are not listed above,
please contact the Secure Trading support team (see 8.1 Secure Trading Support).
© Secure Trading Limited 2014
15 October 2014
Page 43 / 61
XML Specification
4.1.3
Process Overview
The following is an overview of performing an Account Check through STPP.
MERCHANT
SECURE TRADING
ACQUIRING BANK
CARD ISSUER
Step 1) The Merchant
submits an
“ACCOUNTCHECK”
XML Request to Secure
Trading.
Step 2) Secure Trading
validates the Request
and forwards details to
the Acquiring Bank using
a secure connection.
Step 3) The Acquiring
Bank will contact the
Card Issuer to perform
checks on the customer’s
payment details.
Step 4) The Card Issuer
performs various checks,
including AVS and CVV2.
Step 5) The Acquiring
Bank interprets the
results of these checks
sends a response to
Secure Trading.
Step 6) Secure Trading
interprets response from
the Acquiring Bank.
Returns XML Response
to Merchant.
Step 7) Merchant
receives an
“ACCOUNTCHECK”
XML Response from
Secure Trading and
interprets this Response.
MERCHANT
SECURE TRADING
© Secure Trading Limited 2014
ACQUIRING BANK
15 October 2014
CARD ISSUER
Page 44 / 61
XML Specification
Step 1 – Merchant submits XML Request to Secure Trading
A merchant submits an ACCOUNTCHECK XML Request to Secure Trading.
Step 2 - Secure Trading contacts Acquiring Bank
Once the XML Request has been validated, Secure Trading will securely contact the merchant’s
acquiring bank with details of the request.
Step 3 – Acquiring Bank contacts Card Issuer
The acquiring bank will then contact the customer’s card issuer to perform certain checks.
Step 4 – Card Issuer performs checks
The address and security code details provided by the customer are checked to see whether or
not they match those held by the card issuer (see section 2.3.5 <security> on page 26 for more
information). The card issuer then returns the results of these checks to the acquirer.
Step 5 – Acquirer responds to Secure Trading
The acquirer will interpret the results of the checks performed on the customer’s card and
returns a response to Secure Trading.
Step 6 – Secure Trading returns XML Response to Merchant
Secure Trading will then interpret the response from the acquiring bank, and return an XML
Response to the merchant.
Step 7 – Merchant interprets XML Response
The merchant receives an XML Response from Secure Trading. This response will include a
transactionreference which should be retained by the merchant for use in future requests.
4.2
ACCOUNTCHECK XML Request
In order to successfully process an Account Check Request, the XML Request submitted to
Secure Trading must follow the structure outlined in this section. The XML Request for an
Account Check is similar to a normal Authorisation Request (see section 2.2 AUTH XML
Request on page 10), but with differences as outlined in the following sub-sections.
4.2.1
<request type = ”ACCOUNTCHECK”>
The request type for an Account Check Request is ACCOUNTCHECK.
4.2.2
<amount>
The amount for an Account Check can be 0. If a value greater than 0 is sent in the request, it
will be stored and can be used for subsequent requests, such as future Authorisations (although
you can submit a new amount in an inheriting Authorisation Request). Please note that if an
amount of 0 is submitted in an Account Check Request, you must submit a new non-zero
amount in inheriting requests. An Authorisation Request must be for a non-zero amount.
Please note that no funds will be reserved or transferred by the Account Check
Request.
© Secure Trading Limited 2014
15 October 2014
Page 45 / 61
XML Specification
4.2.3
ACCOUNTCHECK XML Request Example
The following is an example ACCOUNTCHECK XML Request. The differences between an
ACCOUNTCHECK XML Request and a standard AUTH XML Request is highlighted in bold.
<?xml version='1.0' encoding='utf-8'?>
<requestblock version="3.67">
<alias>site12345</alias>
<request type="ACCOUNTCHECK">
<merchant>
<orderreference>ACCOUNTCHECK_AUTH</orderreference>
</merchant>
<customer>
<town>Bangor</town>
<name>
<middle>Mary</middle>
<prefix>Miss</prefix>
<last>Smith</last>
<first>Joanne</first>
</name>
<ip>1.2.3.4</ip>
<telephone type="H">1111111111</telephone>
<street>Second Street</street>
<postcode>CU888ST</postcode>
<premise>111</premise>
</customer>
<billing>
<town>Bangor</town>
<name>
<middle>joe</middle>
<prefix>Dr</prefix>
<last>bloggs</last>
<suffix>Jr.</suffix>
<first>fred</first>
</name>
<country>GB</country>
<email>[email protected]</email>
<telephone type="M">0777777777</telephone>
<county>Gwynedd</county>
<amount currencycode="GBP">0</amount>
<street>Test Street</street>
<postcode>TE45 6ST</postcode>
<premise>789</premise>
<payment type="VISA">
<pan>4111110000000211</pan>
<securitycode>123</securitycode>
<expirydate>10/2031</expirydate>
</payment>
</billing>
<operation>
<accounttypedescription>ECOM</accounttypedescription>
<sitereference>site12345</sitereference>
</operation>
</request>
</requestblock>
© Secure Trading Limited 2014
15 October 2014
Page 46 / 61
XML Specification
4.3
ACCOUNTCHECK XML Response
The response for an Account Check is the same as a normal Authorisation, with the exception
of the response type being ACCOUNTCHECK (see section 2.3 AUTH XML Response on page
23).
It is strongly recommended that you check the <security> fields returned
in the XML Response, and discontinue further transactions with the
customer, if the security code entered does not match the one expected by
the acquiring bank (returns a 4). See section 4.3.1 <security> for more
details.
4.3.1
<security>
The results of the checks performed are returned in the security response of the Account Check
(in the <security> tag). The security response consists of three different fields, each
containing the result of an individual check. The names of the fields are listed, below:
Field name
securityresponseaddress
securityresponsepostcode
securityresponsesecuritycode
Comment
The results of the checks performed by the AVS on
the first line of the billing address.
The results of the checks on the billing postcode.
The results of the security code (CVV2) checks.
An Account Check Request will analyse the details provided by the customer and respond with
the following results for each check performed:
Security response value
Description
0
“Not Given”
1
“Not Checked”
2
“Matched”
4
“Not Matched”
Comment
Your bank was not provided with the
information required to perform this check.
Your bank was unable to perform checks on
the information provided.
The information provided by the customer
matches that on the card issuer’s records.
The information provided by the customer
does NOT match that on the card issuer’s
records.
For example, the XML Response may return a security response with the values shown in the
following table:
Field name
securityresponseaddress
securityresponsepostcode
securityresponsesecuritycode
Value
2
2
4
This would indicate that the first line of the address and the postcode match those on the card
issuer’s records, but the security code (CVV2) entered by the customer does not match the
details held by the customers card issuer.
You can use the Notifications feature of MyST to have the security response posted to a URL of
your choosing (which could have a script present to store this value) or sent in an email.
© Secure Trading Limited 2014
15 October 2014
Page 47 / 61
XML Specification
Alternatively, you can view security responses in the Single Transaction View for the Account
Check transaction in MyST (see Figure 1). Please refer to the MyST User Guide (see section
8.3 Useful Documents) for more information.
Figure 1 - Security Response in MyST
If an amount is submitted in an Account Check Request, it is only stored for
the purpose of inheritance by future requests (such as performing a later
Authorisation Request), which refer to this parent Account Check
transaction. The amount sent in an Account Request is not reserved, as
Account Checks never reserve funds.
Please note that the settlestatus submitted with an Account Check will be
inherited by any subsequent requests that refer to it as a parent.
For more information on the nature of the checks performed, please refer to the STPP AVS &
CVV2 document (see section 8.3 Useful Documents on page 56).
4.3.1.1 Account Check Rules
Optionally, rules can be assigned on your account by the Secure Trading support team, which
will use the results of the Account Check to decide whether or not to process an associated
Authorisation transaction. The recommended process flow is as follows:
1. If the Account Check returns a ‘Matched, then process the Authorisation.
2. If the Account Check returns a ‘Not Checked’, then process the Authorisation, but
suspend the transaction allowing for manual investigation to take place.
3. If the Account Check returns a ‘Not matched’, then do NOT process an Authorisation.
Please note that the default process flow can be customised. For example, you
could choose to process the Authorisation if the Account Check returns ‘Not
Matched’. For more information, contact Secure Trading Support (see section 8.1
Secure Trading Support on page 56).
An alternative to having rules set up, is that your system has this logic present which
determines whether or not to submit an Authorisation Request.
© Secure Trading Limited 2014
15 October 2014
Page 48 / 61
XML Specification
4.3.2
ACCOUNTCHECK XML Response Example
The following is an example ACCOUNTCHECK XML Response. The differences between an
ACCOUNTCHECK XML Response and a standard AUTH XML Response is highlighted in bold.
<?xml version='1.0' encoding='utf-8'?>
<responseblock version="3.67">
<requestreference>X575647667</requestreference>
<response type="ACCOUNTCHECK">
<merchant>
<merchantname>example UNICODE merchantname</merchantname>
<orderreference>ACCOUNTCHECK_AUTH</orderreference>
<tid>27882788</tid>
<merchantnumber>00000000</merchantnumber>
<merchantcountryiso2a>GB</merchantcountryiso2a>
</merchant>
<transactionreference>16-9-1</transactionreference>
<billing>
<amount currencycode="GBP">0</amount>
<payment type="VISA">
<issuer>Test Issuer</issuer>
<issuercountry>ZZ</issuercountry>
<pan>411111######0211</pan>
</payment>
<dcc enabled="0"/>
</billing>
<authcode>TEST</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>ECOM</accounttypedescription>
</operation>
</response>
</responseblock>
© Secure Trading Limited 2014
15 October 2014
Page 49 / 61
XML Specification
5
Best Practices
When your system receives an XML Response from Secure Trading, it is best practice to check
all the relevant fields and values are as expected before processing the response. In particular,
it is recommended you consider the following:
5.1
Transaction Reference
Transaction references are unique identifiers for each transaction processed on your Secure
Trading account. It is advisable that these are stored on your own system for any future
correspondence with Secure Trading or to assist in troubleshooting.
5.2
Response Type
The <response type=””> tag will be returned near the top of every XML Response returned
by Secure Trading. For valid requests, the response type should always be the same type as
submitted in the XML Request. Please ensure that the response type returned is the expected
value.
e.g. An AUTH XML Request should always return an AUTH XML Response
When an ERROR XML Response is returned, your request may not have been processed
correctly.
When submitting multiple request types in a single request block, you should
expect an XML Response with the same (multiple) response types in a single
block.
5.3
Error Code
The <code> element returned within the <error> tag will always be ‘0’ for successful
requests. XML Requests that return a non-zero value for the error code in the response should
be treated as an error and should be investigated.
The <message> element returned within the <error> tag contains a brief description of the
error. A full list of error codes and their meanings can be found at:
http://webapp.securetrading.net/errorcodes.html
5.4
Live Status
The <live> tag will return ‘0’ when using your test account and ‘1’ when using your live
account. If you are processing live transactions, please ensure <live> always returns the
value of ‘1’ in any XML Response received.
© Secure Trading Limited 2014
15 October 2014
Page 50 / 61
XML Specification
5.5
Additional checks
For certain request types, you may need to consider checking the following fields in addition to
those listed previously:
5.5.1
Settle Status
Please be aware that Secure Trading can suspend transactions automatically, following fraud
checks performed. For this reason, it is important to ensure the <settlestatus> returned in
the XML Response is the expected value. For more information on settle statuses, see section
9.1.
5.5.2
Amount & Currency
When responding to valid XML Requests, the <amount> and currencycode fields returned in
an XML Response will match those sent in the XML Request. Please validate that this is
correct.
5.5.3
Security
When processing payments through Secure Trading, we strongly recommend checking the
values returned in the <security> tag of the XML Response. These values represent the
results of AVS and CVV2 checks performed by the card issuer on the payment and billing
details submitted in the XML Request. For more information on AVS and CVV2 checks, please
refer to the AVS & CVV2 document.
© Secure Trading Limited 2014
15 October 2014
Page 51 / 61
XML Specification
6
Troubleshooting
6.1
Invalid or incomplete XML Request
Invalid or incomplete XML Requests (e.g. error codes “10500” or “30000” in the XML Response)
can be caused by the following:
Missing XML tags – check the XML Specification to see if any required tags are
missing from the request.
Newline character at the end of the XML – check the XML Request to ensure there is
a newline character at the end.
Character encoding – refer to Character Encoding section at the beginning of this
document.
Character escaping – refer to Character Escaping section at the beginning of this
document.
© Secure Trading Limited 2014
15 October 2014
Page 52 / 61
XML Specification
7
Testing
7.1
Testing Authorisation
During your integration, you can use the following test card details in order to build your system
around the request and responses for authorisations.
Please note that these are TEST card details, and will not return the expected
responses in a LIVE environment.
Name of payment
type
American Express
Diners
Discover
JCB
Maestro
MasterCard
MasterCard Debit
V PAY
Visa
Visa Debit
Visa Electron
Visa Purchasing
Payment type field
Authorisation
Decline
AMEX
DINERS
DISCOVER
JCB
MAESTRO
MASTERCARD
MASTERCARDDEBIT
VPAY
VISA
DELTA
ELECTRON
PURCHASING
340000000000611
3000000000000111
6011000000000301
3528000000000411
5000000000000611
5100000000000511
5124990000000101
4370000000000061
4111110000000211
4310720000000091
4245190000000311
4484000000000411
340000000000512
3000000000000012
6011000000000202
3528000000000312
5000000000000512
5100000000000412
5124990000000002
4370000000000012
4111110000000112
4310720000000042
4245190000000212
4484000000000312
For these cards, when performing your tests, please ensure that within the expirydate field
you set a date in the future.
A base amount of 70000 will return a declined response from the test bank.
A base amount of 60010 will return a bank system error from the test bank.
© Secure Trading Limited 2014
15 October 2014
Page 53 / 61
XML Specification
7.2
Testing Security Code and Address Verification Process
The following tables list test details that can be submitted to obtain different responses from the
address verification (AVS) and security code (CVV2) checks. These details can be used with
most major payment types.
Please note that only the billing premise, billing postcode and security code fields
dictate the outcome of the AVS and CVV2 checks performed. As such, entering
any details into the other address fields will not affect the outcome of the AVS and
CVV2 checks.
7.2.1
Premise
Billing Premise
No 789
No 123
No 333
Leave blank
7.2.2
Security Response Caption
Matched
Not Matched
Not Checked
Not Given
Security Response
Security Response Caption
2
4
1
0
Matched
Not Matched
Not Checked
Not Given
Security Response
2
4
1
0
Security Response Caption
Matched
Not Matched
Not Checked
Not Given
Postcode / ZIP Code
UK Billing
Postcode
TE45 6ST
TE12 3ST
TE33 3ST
Leave blank
7.2.3
Security Response
2
4
1
0
US Billing
Postcode
55555
12345
33333
Leave blank
Security code
Security Code
123
214
333
Leave blank
AMEX Security Code
1234
2144
3333
Leave blank

Information on the AVS and CVV2 checks performed is detailed in the
AVS & CVV2 document
All Secure Trading documents can be found on our website.
7.3
Testing Refunds
If you wish to test for refunds, then you need to perform an original AUTH Request using one of
the successful card numbers included in section 7.1 Testing Authorisation in order to obtain a
transaction reference. Using this transaction reference you can then perform a refund following
the steps outlined in section 3 Refund. Please note that your test transaction will need to have
settled before a refund can be performed.
© Secure Trading Limited 2014
15 October 2014
Page 54 / 61
XML Specification
7.4
Testing Account Check
If you wish to test an Account Check Request, then you can use any of the card numbers
included in section 7.1 Testing Authorisation and in your request ensure that you have set the
request type to be:
<request type="ACCOUNTCHECK">
You can also test the Security Code and Address Verification System by using the Security
Code, Address and Postcode details supplied in section 7.2.
Please note that Account Check is only available with select Acquiring Banks.
Please contact Secure Trading Support Team for more details.
See section 8.1 Secure Trading Support on page 56.
© Secure Trading Limited 2014
15 October 2014
Page 55 / 61
XML Specification
8
Further Information and Support
This section provides useful information with regards to documentation and support for the
merchant’s Secure Trading solution.
8.1
Secure Trading Support
If you have any questions regarding integration or maintenance of the system, please contact
our support team using one of the following methods.
Method
Telephone
Fax
Email
Website
8.2
Details
+44 (0) 1248 672 050
+44 (0) 1248 672 099
[email protected]
http://www.securetrading.com/support/support.html
Secure Trading Sales
If you do not have an account with Secure Trading, please contact our Sales team and they will
inform you of the benefits of a Secure Trading account.
Method
Telephone
Telephone (Int’l)
Fax
Email
Website
8.3
Details
0800 028 9151
+44 (0) 1248 672 070
+44 (0) 1248 672 079
[email protected]
http://www.securetrading.com
Useful Documents
The documents listed below should be read in conjunction with this document:
STAPI User Guide – This document outlines how to install a STAPI java client. This client
can be used to process XML Requests and Responses through Secure Trading.
STPP Web Services User Guide – This document describes how to process XML Requests
and Responses through Secure Trading’s Web Services solution.
STPP Card Store – This document describes how to process Card Store XML Requests
and Responses through Secure Trading.
STPP Protect Plus – This document describes how to process Risk Decision XML
Requests and Responses through Secure Trading.
STPP 3D Secure – This document describes how to process 3D Secure XML Requests and
Responses through Secure Trading.
STPP PayPal – This document describes how to process PayPal XML Requests and
Responses through Secure Trading.
STPP AVS & CVV2 – This document describes the checks performed on the address and
security code submitted by the customer.
STPP Transaction Update – This document outlines how to perform a Transaction Update
Request.
Any other document regarding the STPP system can be found on our website
(http://www.securetrading.com).
8.4
Frequently Asked Questions
Please visit the FAQ section on our website (http://www.securetrading.com/support/faq).
© Secure Trading Limited 2014
15 October 2014
Page 56 / 61
XML Specification
9
Appendix
9.1
Pre-Authorisations and Final Authorisations MasterCard Europe Mandate
MasterCard Europe have mandated that MasterCard and Maestro transactions processed with
certain European acquiring banks must be flagged as either pre-authorisation or final
authorisation. Such transactions are subject to acquirer-specific conditions.
We recommend that you contact your acquirer for information on whether this mandate applies
to your configuration and to clarify whether to process your transactions as pre-authorisations or
final authorisations.
By default, Secure Trading will process MasterCard and Maestro authorisations as final
authorisations. You can change this default behaviour to submit pre-authorisations, by
contacting Secure Trading Support (see section 8.1).
Alternatively, see section 9.1.2 for information on overriding the default behaviour on a
transaction-by-transaction basis.
9.1.1
About Pre-Authorisations and Final Authorisations
Pre-authorisation and final authorisation can be summarised as follows:
Pre-Authorisation:
Settlement can be deferred by up to 7 days following authorisation.
During this time, the amount to be settled can be updated to a value that is lower than
the amount authorised.
Pre-authorisations are more flexible than final authorisations, but may be subject to
higher processing fees by your acquiring bank.
Final authorisation:
Settlement
can
only
be
deferred
by
up
to
4
days
following
(1) (2)
authorisation
.
(1)
Following authorisation, the amount value should not be changed .
Final authorisations are less flexible than pre-authorisations, but may be subject to
lower processing fees by your acquiring bank.
(1)
Failure to adhere to these conditions may incur a fine from MasterCard.
(2)
Secure Trading will allow final authorisations to be settled up to 7 days
after authorisation, but recommend that you settle transactions within 4
days to avoid incurring a fine.
For full terms and conditions, please contact your acquiring bank.
© Secure Trading Limited 2014
15 October 2014
Page 57 / 61
XML Specification
9.1.2
Override
You can include the <authmethod> element (submitted within the <operation> tag) to
indicate whether the associated payment is a pre-authorisation or a final authorisation. When
submitted, this overrides the default settings on your account.
The values that can be submitted are:
“PRE” - Requests a “pre-authorisation”.
“FINAL” - Requests a “final authorisation” (default).
The <authmethod> element can ONLY be submitted in XML Requests of the following type:
THREEDQUERY:
If submitted, the authmethod value is inherited by the child AUTH Request.
AUTH:
If submitted, the authmethod overrides the value submitted in the parent
THREEDQUERY or the default value for the site.
The <authmethod> element cannot be inherited from previous authorisations.
When performing repeat authorisations, the default value of your site will be used,
unless you override this by manually submitting a new <authmethod> element in
the request.
If Secure Trading submits a value for the <authmethod> element to the acquirer during
authorisation, it will always be returned within the <operation> tag of the AUTH XML
Response, in order to indicate whether the payment processed was a pre-authorisation or a
final authorisation.
© Secure Trading Limited 2014
15 October 2014
Page 58 / 61
XML Specification
9.2
VISA Additional Authorisation Data Merchant Category Code (MCC 6012)
In order to reduce fraud, VISA has mandated that UK-based merchants with a Merchant
Category Code (MCC) of 6012 are required to send additional fields in the <customer> tag of
AUTH XML Requests, if provided by the customer making the payment. The fields are as
follows:
Tag
customer
accountnumber
type=””
Type
Length
Required
Comment
C
an
7
C
Either “CARD” or “ACCOUNT”.
If account number type is
“ACCOUNT”, the account holder’s
account number.
accountnumber
an
20
C
country
an
2
C
dob
an
10
C
name
last
an
127
C
C
postcode
an
25
C
If account number type is “CARD”,
the account holder’s card number.
Note: This may be the same as the
card number submitted in the
<billing> tag, but must still be
submitted.
The country for the account holder’s
billing address. This will need to be in
ISO2A format. List of Country Codes:
http://webapp.securetrading.net/coun
trycodes.html
The account holder’s date of birth.
Must be in the format YYYY-MM-DD.
The account holder’s last name.
The account holder’s address
postcode.
Your Merchant Category Code (MCC) is a four-digit number assigned to you by
your acquirer. It is used to classify the business by the type of products or
services it provides. If you are unsure of the value of your merchant category
code, please contact Secure Trading Support (section 8.1).
© Secure Trading Limited 2014
15 October 2014
Page 59 / 61
XML Specification
This AUTH XML Request example includes the fields mandated by VISA for merchants with
category code 6012 (highlighted in bold). A full example can be found in section 2.2.9.
<requestblock version="3.67">
<alias>SECURETRADING</alias>
<request type="AUTH">
<operation>
<sitereference>live2</sitereference>
<accounttypedescription>ECOM</accounttypedescription>
</operation>
<customer>
<name>
<last>LASTNAME</last>
</name>
<postcode>TE456ST</postcode>
<country>GB</country>
<dob>1990-01-01</dob>
<accountnumber type="ACCOUNT">ACCOUNTNUMBER</accountnumber>
</customer>
<billing>
<amount currencycode="GBP">9200</amount>
<payment type="VISA">
<expirydate>01/2034</expirydate>
<pan>4111111111111111</pan>
<securitycode>123</securitycode>
</payment>
</billing>
</request>
</requestblock>
© Secure Trading Limited 2014
15 October 2014
Page 60 / 61
XML Specification
9.3
Settle Statuses
Settle
status
Caption
0
Automatic
1
Manual
10
100
2
3
Description
Transaction that has been authorised by card issuer for payment.
Secure Trading schedules fraud checks to be performed
on the transaction.
Settles automatically providing it passes fraud checks
performed by Secure Trading (depending on account
configuration).
Does not require further action from merchant.
Can be updated or cancelled.
Transaction that has been authorised by card issuer for payment.
Settles automatically.
AVS & CVV2 and 3-D Secure checks are performed,
however transaction is not scheduled for additional Secure
Trading internal fraud checks.
Does not require further action from merchant.
Can be updated or cancelled.
Settling
Details of this transaction have been sent to the acquiring bank for
settlement.
Settles automatically.
Does not require further action from merchant.
Cannot be updated or cancelled.
Settled
Transaction has been settled into the merchant’s account.
Does not require further action from merchant.
Cannot be updated or cancelled.
Can be refunded (unless all funds have already been
refunded).
Suspended
Transaction is in a suspended state, awaiting further action from
the merchant:
Will not be settled unless updated by the merchant to
settle status ‘0’ or ‘1’.
Alternatively, merchants can cancel this transaction by
updating the settle status to ‘3’.
Transactions can be manually suspended by merchants to
prevent settlement, allowing for manual investigation.
Secure Trading by default automatically suspends
transactions it deems potentially fraudulent or a duplicate
of a previous transaction. (You can customize the rules
used to suspend transactions by contacting Support,
section 8.1)
If left in a suspended state Secure Trading will
automatically cancel the transaction 7 days after the
authorisation date.
Cancelled
Transaction has been cancelled.
When a transaction fails due to an error, the settle status is
set to ‘3’.
Merchants can manually cancel transactions by updating
the settle status to ‘3’. This prevents funds from being
settled.
Cannot be updated.
© Secure Trading Limited 2014
15 October 2014
Page 61 / 61