Version: 1.11 Published: 22 October 2014

Transcription

1 This document outlines how to perform Fraud Score requests through the STPP system. The Fraud Score system allows the merchant to perform additional checks on a customer to those performed on authorization. XML example requests and refunds are included. Version: 1.11 Published: 22 October 2014

2 About this Document This document is a supplement to the STPP documentation. It outlines the process of performing Fraud Score requests through SecureTrading. 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 October 2014 Page 2 / 30

3 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 October 2014 Page 3 / 30

4 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 ?> 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 '&' The character '<' MUST be escaped as '<' 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 October 2014 Page 4 / 30

5 payment type an 20 Y The customer s card type, for example VISA or MASTERCARD. pan n Y This is the card number printed on the front of the customer s card. The expiry date printed on the card. expirydate an 7 Y 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 Data Type an 25 N Here would be the reference of a previous transaction. 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 October 2014 Page 5 / 30

6 Table of Contents 1 Introduction Overview Fraud Score and Authorisations Account Configuration Secure Trading Fraud Score XML Request XML Overview <billing> <customer> <merchant> <operation> XML Request Example Secure Trading Fraud Score XML Response XML Overview <fraudscore> XML Response Example Fraud Score with Authorisations <maxfraudscore> <billing> <customer> <operation> Secure Trading Fraud Score with Authorisation XML Request Secure Trading Fraud Score with Authorisation XML Response Testing Example of Low Level Risk of Fraud Example of Medium Level Risk of Fraud Example of High Level Risk of Fraud Example of Fraud Score with blocked Authorisation Testing Authorisation Further Information and Support Secure Trading Support Secure Trading Sales Useful Documents Frequently Asked Questions Secure Trading Limited October 2014 Page 6 / 30

7 1 Introduction This document provides an explanation of the Secure Trading Fraud Score system. 1.1 Overview The purpose of the Fraud Score system is to minimise chargebacks and fraud by identifying suspicious orders. Checks are performed on such things as the IP of the customer against the billing address and whether any of the Customer s details have been used previously in fraudulent transactions across the web. A score is then returned to the Merchant based on these checks. Fraud Score checks can be performed before or after processing a transaction. 1.2 Fraud Score and Authorisations The Merchant can submit an XML call to Secure Trading that includes both a Fraud Score and an Authorisation request. Although both requests are submitted within the same call to Secure Trading, the Fraud Score request is processed first, then the Authorisation request. The Merchant can set a maximum fraud score in the call. If the Fraud Score returns a score that is greater than the value set, the Authorisation is not processed. 1.3 Account Configuration In order to successfully process Fraud Score through Secure Trading, the following configuration steps need to be completed Secure Trading Configuration The Merchant will need to have an account with Secure Trading. For more information, contact Secure Trading Sales (see section 6.2 Secure Trading Sales on page 30). Once an account has been setup, the Merchant will need to contact Secure Trading Support to obtain their Site Reference (see section 6.1 Secure Trading Support on page 30) Processing XML through Secure Trading The Merchant will need to setup their system to process XML through Secure Trading. The options available are on Secure Trading s website ( Secure Trading Limited October 2014 Page 7 / 30

8 2 Secure Trading Fraud Score XML Request This section of the document explains the XML for a Fraud Score request through the Secure Trading Payment Platform. 2.1 XML Overview Fraud Score can be performed in one of two ways: 1. The Merchant submits card details within a Fraud Score Request. 2. The Merchant can check the card details of a previous transaction using the transaction reference. It is imperative that both the <request type= > and <accounttypedescription> tags are set to FRAUDSCORE. An outline of the tags used in a Fraud Score Request can be found overleaf. Secure Trading Limited October 2014 Page 8 / 30

9 2.2 <billing> Within the <billing> tags, the Merchant can include the card details that they wish to check. billing Y payment type= an 20 Y The Customer s card type. expirydate an 7 Y The expiry date on the back of the card. This must be in the format MM/YYYY. pan n Y Credit card number printed on the front of the customer s card. The number can be from 16 to 21 digits. premise an 25 N The billing address premise (house name or number). street an 127 N The billing address street name. town an 127 Y The town of the billing address. county an 127 Y The county of the billing address. postcode an 25 Y The postcode of the billing address. This must be a valid US state code if the country is US. country an 3 N The billing country ISO code. For a list of countries, see /countrycodes.html telephone type= an 1 C telephone n 20 C an 255 N The type of telephone number. The options available are: H = Home M = Mobile W = Work Only required if telephone is included. The billing telephone number. Valid characters: Numbers 0-9 Spaces Special characters: + - ( ) Only required if telephone type is included. The billing address. Maximum length of 255 (maximum of 64 characters before symbol). Within the above table, fields such as <pan> are required only if the card details are not ones previously used through Secure Trading s systems. Secure Trading Limited October 2014 Page 9 / 30

10 2.3 <customer> customer Y telephone type= an 1 C telephone n 20 C 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. an 255 N The Customer s address. forwardedip an 15 N The Customer s forwarded IP address, as provided by a proxy server if available ip an 15 Y The IP of the Customer. premise an 25 N The premise of the Customer s address (house name or number). street an 127 N The street name of the Customer address. county an 127 N The county of the Customer address. This must be a valid US state code if the country is US. country an 3 N The customer country ISO code. For a list of country codes, see securetrading.net/ countrycodes.html postcode an 25 N The postcode of the Customer address. town an 127 N The town of the Customer address. Secure Trading Limited October 2014 Page 10 / 30

11 2.4 <merchant> merchant N orderreference an 255 N The Merchant s own reference. 2.5 <operation> operation Y parent transaction reference an 20 N sitereference an 20 Y accounttype description an 20 Y This field must contain the transaction reference of the authorised transaction that you wish to perform the request on. The Site Reference relates to your individual account which you will have received on setup. If you do not know your Site Reference, please contact support (see section 6.1 Secure Trading Support on page 30). For FRAUDSCORE requests, the value must be FRAUDSCORE. If the <parenttransactionreference> is submitted, tags such <billing> are no longer required as the check will then be made on the card details of the parent transaction. Secure Trading Limited October 2014 Page 11 / 30

12 2.6 XML Request Example Please find below an example of a Fraud Score Request to be submitted to Secure Trading s systems. <?xml version="1.0" encoding="utf-8"?> <requestblock version="3.67"> <alias>site12345</alias> <request type="fraudscore"> <merchant> <orderreference>example FRAUDSCORE</orderreference> < ></ > </merchant> <customer> <ip> </ip> < >customer@example.com</ > <name>joe Bloggs</name> </customer> <billing> <town>town</town> <country>gb</country> <payment type="visa"> <expirydate>10/2031</expirydate> <pan> </pan> <securitycode>123</securitycode> </payment> <county>county</county> <postcode>postcode</postcode> <premise>12</premise> < ></ > </billing> <delivery> <town>delivery Town</town> <county>delivery County</county> <country>us</country> <postcode>zipcode</postcode> <premise>13</premise> <street>street</street> </delivery> <operation> <sitereference>site12345</sitereference> <accounttypedescription>fraudscore</accounttypedescription> </operation> <settlement/> </request> </requestblock> Secure Trading Limited October 2014 Page 12 / 30

13 3 Secure Trading Fraud Score XML Response 3.1 XML Overview The XML response for a successful Fraud Score Request will have the response type set as FRAUDSCORE. 3.2 <fraudscore> fraudscore Y The score returned is a decimal from indicating the probability of the transaction being fraudulent. score an 10 Y The score is calculated based on the analysis of millions of transactions and online fraud. Please note that in most scenarios, Secure Trading recommends accepting scores under 3, rejecting scores over 60 and manually investigating scores that fall between 3 and 60. Please note Secure Trading does not guarantee a low score against fraud. You should consider all data regarding a transaction before deciding to process it <customer> customer Y postcode Y 1 =Yes 0 = No townmatch n 1 Y forwardaddress n 1 Y Whether customer city and county match postcode. Currently available for US addresses only, returns empty string outside the US. 1 = Yes 0= No 3 = NA. Whether delivery address is in database of known mail drops. Secure Trading Limited October 2014 Page 13 / 30

14 3.2.2 <billing> billing Y country Y binmatch n 1 Y 1= Yes 0= No 2 = NotFound 3 = NA postcode Y Whether country of issuing bank based on BIN number matches billing address country. 1= Yes 0= No 2 = NotFound 3 = NA Whether the phone number is in the billing post/zip code. telephone match n 1 Y A return value of Yes provides a positive indication that the phone number listed belongs to the cardholder. A return value of No indicates that the phone number may be in a different area, or may not be listed in the database. NotFound is returned when the phone number prefix cannot be found in the database at all. Currently only supports US Phone numbers. 1 =Yes 0 = No townmatch n 1 Y Whether billing town and county match the postcode. Currently available for US addresses only, returns empty string outside the US. Secure Trading Limited October 2014 Page 14 / 30

15 3.2.3 <ip> ip Y county an 2 Y State/Region code associated with IP address. For US/Canada, ISO code for the state/province name, with the addition of AA, AE, and AP for Armed Forces America, Europe and Pacific. Outside of the US and Canada, FIPS 10-4 code. town an 127 Y City or town name associated with IP address distance an 20 Y Distance from IP address location to billing location in kilometres (large distance = higher risk). latitude an 20 Y Latitude associated with IP address. country Y 1 =Yes 0 = No billingmatch n 1 Y isocode an 2 Y highrisk n 1 Y organisation an 127 Y isp an 127 Y longitude an 20 Y Whether country of IP address matches billing address country (mismatch = higher risk). ISO 3166 Country Code, with the addition of A1 for Anonymous Proxies. A2 for Satellite Providers EU for Europe AP for Asia/Pacific Region In addition, overseas military bases are mapped to US 1 =Yes 0 = No Whether IP address or billing address country is in Ghana, Nigeria, or Vietnam. The name of the organization associated with the IP address. The name of the ISP associated with the IP address. Longitude associated with IP address. Secure Trading Limited October 2014 Page 15 / 30

16 3.2.4 <proxy> proxy Y Decimal from 0 to 10. openproxyscore an 5 Y Likelihood of IP Address being an Open Proxy. 1 =Yes 0 = No transparent n 1 Y anonymous n 1 Y Whether IP address is in database of known transparent proxy servers, returned if forwarded IP is passed as an input. 1 =Yes 0 = No Whether IP address is an Anonymous Proxy (anonymous proxy = very high risk) < > Y highrisk n 1 Y 1 =Yes 0 = No Whether is in database of high risk s. 1 =Yes 0 = No free n 1 Y 3.3 XML Response Example Whether is from free provider (free = higher risk). <?xml version="1.0" encoding="utf-8"?> <responseblock version="3.67"> <requestreference>x </requestreference> <response type="fraudscore"> <merchant> <orderreference>fraudscore</orderreference> </merchant> <transactionreference> </transactionreference> <billing> <payment type="visa"> <pan>411111######1111</pan> </payment> </billing> <timestamp> :03:19</timestamp> <live>0</live> <fraudscore> <customer> <postcode> Secure Trading Limited October 2014 Page 16 / 30

17 <townmatch>0</townmatch> </postcode> <forwardaddress>0</forwardaddress> </customer> <billing> <country> <binmatch>1</binmatch> </country> <postcode> <telephonematch>1</telephonematch> <townmatch>0</townmatch> </postcode> </billing> <ip> <county>us36</county> <town>new York</town> <distance>13</distance> <latitude> </latitude> <country> <billingmatch>1</billingmatch> <isocode>us</isocode> <highrisk>0</highrisk> </country> <organisation>usa Company</organisation> <isp>us Online</isp> <longitude>8.2134</longitude> </ip> <score>36.15</score> <proxy> <openproxyscore>10.0</openproxyscore> <transparent>1</transparent> <anonymous>1</anonymous> </proxy> < > <highrisk>0</highrisk> <free>0</free> </ > </fraudscore> <error> <message>ok</message> <code>0</code> </error> <operation> <accounttypedescription>fraudscore</accounttypedescription> </operation> </response> </responseblock> Secure Trading Limited October 2014 Page 17 / 30

18 4 Fraud Score with Authorisations The Merchant is able to submit a FRAUDSCORE and an AUTH Request within the same call. The benefit of this is that the Merchant will only need to build their system to submit one call to Secure Trading. Within the <requestblock> tags, the Merchant will include two <request> tags, one for FRAUDSCORE and the other for the AUTH. FRAUDSCORE is processed first, followed by the AUTH. The Merchant can set a maxfraudscore in their AUTH Request, so that if this level is matched or exceeded, the authorisation is not processed. It is imperative that when including both requests within the same request block, The FRAUDSCORE Request is submitted before the AUTH. The response includes the response tags for both the FRAUDSCORE and the AUTH. The AUTH Request can inherit most fields from the FRAUDSCORE Request. The fields that are not inherited need to be included within the AUTH Request as outlined below. 4.1 <maxfraudscore> The score returned from the FRAUDSCORE Request is a decimal from indicating the probability of the transaction being fraudulent. maxfraudscore an 10 N If the value of <score> from the FRAUDSCORE Request is met or higher than the value specified, the AUTH will not be attempted. For more information on fraudscore, refer to section 3.2 <fraudscore> on page <billing> Most of the fields within the <billing> tags are inherited from the FRAUDSCORE Request. The fields that are not inherited are ones that are not relevant for FRAUDSCORE. billing Y amount currency code= an 3 Y amount an 15 Y The currency that the transaction will be processed in. A list of currencies on our Secure Trading s website ( currencycodes.html). The transaction amount in base units with no commas or decimal points, so 10 would be 1000 Secure Trading Limited October 2014 Page 18 / 30

19 4.2.1 <name> The name fields are not needed for FRAUDSCORE so will need to be added in the AUTH Request tags. billing N name N prefix an 25 N The name prefix of the billing details. first an 25 N The first name of the billing details. middle an 25 N The middle name(s) of the billing details. last an 25 N The last name of the billing details. suffix an 25 N The name suffix of the billing details <payment> billing N payment N security code n 4 N The three (four for AMEX) digit security code printed on the back of the card. 4.3 <customer> Most of the Customer details will be inherited from the FRAUDSCORE Request, but as the name fields are not needed for FRAUDSCORE, these will need to be added in the AUTH Request <name> The name fields are not needed for FRAUDSCORE so will need to be added in the AUTH Request tags. customer N name N prefix an 25 N The name prefix of the Customer details. first an 25 N The first name of the Customer details. middle an 25 N The middle name(s) of the Customer details. last an 25 N The last name of the Customer details. suffix an 25 N The name suffix of the Customer details. Secure Trading Limited October 2014 Page 19 / 30

20 4.4 <operation> The <operation> tags need to be included in both FRAUDSCORE and AUTH Requests. The field that needs to be set differently is the <accounttypedescription>, as this specifies the type of account used. operation Y accounttype description an 20 Y Can be one of the following vales: ECOM - Ecommerce transactions MOTO Mail Order Telephone Order transactions RECUR Recurring transactions 4.5 Secure Trading Fraud Score with Authorisation XML Request Below is an example where a FRAUDSCORE and an AUTH Request are included within the same request block. <?xml version="1.0" encoding="utf-8"?> <requestblock version="3.67"> <alias>test_example40000</alias> <request type="fraudscore"> <merchant> <orderreference>fraudscore_with_auth</orderreference> </merchant> <customer> <town>bangor</town> <street>second Street</street> <postcode>cu888st</postcode> <premise>111</premise> <ip> </ip> <telephone type="h"> </telephone> </customer> <operation> <sitereference>test_example40000</sitereference> <accounttypedescription>fraudscore</accounttypedescription> </operation> <billing> <town>bangor</town> <county>gwynedd</county> <street>test Street</street> <postcode>te45 6ST</postcode> <premise>789</premise> <telephone type="m"> </telephone> <country>gb</country> <payment> <expirydate>10/2031</expirydate> <pan> </pan> </payment> < >fred.bloggs@example.com< > </billing> </request> <request type="auth"> <customer> <name> <middle>mary</middle> Secure Trading Limited October 2014 Page 20 / 30

21 <prefix>miss</prefix> <last>smith</last> <first>joanne</first> </name> </customer> <billing> <payment> <securitycode>123</securitycode> </payment> <name> <middle>joe</middle> <prefix>dr</prefix> <last>bloggs</last> <suffix>jr.</suffix> <first>fred</first> </name> <amount currencycode="gbp">1102</amount> </billing> <operation> <maxfraudscore>99</maxfraudscore> <accounttypedescription>ecom</accounttypedescription> </operation> </request> </requestblock> 4.6 Secure Trading Fraud Score with Authorisation XML Response The XML Response will include the response of the FRAUDSCORE and the AUTH. More information on AUTH Requests and Responses can be downloaded from our website ( <?xml version="1.0" encoding="utf-8"?> <responseblock version="3.67"> <requestreference>x </requestreference> <response type="fraudscore"> <merchant> <orderreference>fraudscore_with_auth</orderreference> </merchant> <transactionreference> </transactionreference> <billing> <payment> <pan>400000######0051</pan> </payment> </billing> <timestamp> :06:37</timestamp> <live>0</live> <fraudscore> <billing> <country> <binmatch>3</binmatch> </country> <postcode> <telephonematch>2</telephonematch> </postcode> </billing> <ip> <county>us36</county> <town>new York</town> Secure Trading Limited October 2014 Page 21 / 30

22 <distance>13</distance> <latitude> </latitude> <country> <billingmatch>0</billingmatch> <isocode>us</isocode> <highrisk>0</highrisk> </country> <organisation>usa Company</organisation> <isp>us Online</isp> <longitude>8.2134</longitude> </ip> <score>40.73</score> <proxy> <openproxyscore>4.0</openproxyscore> <anonymous>0</anonymous> </proxy> < > <highrisk>0</highrisk> <free>0</free> </ > </fraudscore> <error> <message>ok</message> <code>0</code> </error> <operation> <accounttypedescription>fraudscore</accounttypedescription> </operation> </response> <response type="auth"> <merchant> <merchantname>example UNICODE merchantname</merchantname> <orderreference>fraudscore_with_auth</orderreference> <tid> </tid> <merchantnumber> </merchantnumber> <merchantcountryiso2a>gb</merchantcountryiso2a> </merchant> <transactionreference>19-9-9</transactionreference> <security> <postcode>2</postcode> <securitycode>2</securitycode> <address>2</address> </security> <billing> <amount currencycode="gbp">1102</amount> <payment type="visa"> <pan>400000######0051</pan> </payment> <dcc enabled="0"/> </billing> <authcode>test</authcode> <timestamp> :06:37</timestamp> <settlement> <settleduedate> </settleduedate> <settlestatus>0</settlestatus> </settlement> <live>0</live> <error> <message>ok</message> <code>0</code> Secure Trading Limited October 2014 Page 22 / 30

23 </error> <acquirerresponsecode>00</acquirerresponsecode> <operation> <parenttransactionreference> </parenttransactionreference> <accounttypedescription>ecom</accounttypedescription> </operation> </response> </responseblock> Secure Trading Limited October 2014 Page 23 / 30

24 5 Testing As can be seen in section 3.2 <fraudscore> of this document, there are a number of different sections that are included within the <fraudscore> tags. When in production, these are used in calculating the <score> included within the response. This is also the case when testing your Fraud Score system. 5.1 Example of Low Level Risk of Fraud Below is example XML that when submitted to our test bank will return a low level risk of fraud. The number will begin with 24 then the two decimal values following it are randomly generated by the test bank. <?xml version="1.0" encoding="utf-8"?> <requestblock version="3.67"> <alias>securetrading</alias> <request type="fraudscore"> <merchant> <orderreference>example FRAUDSCORE</orderreference> < ></ > </merchant> <customer> <ip> </ip> < >customer@example.com</ > <name>joe Bloggs</name> </customer> <billing> <town>town</town> <country>gb</country> <payment type="visa"> <expirydate>10/2031</expirydate> <pan> </pan> <securitycode>123</securitycode> </payment> <county>county</county> <postcode>postcode</postcode> <premise>12</premise> < ></ > </billing> <delivery> <town>delivery Town</town> <county>delivery County</county> <country>us</country> <postcode>zipcode</postcode> <premise>13</premise> <street>street</street> </delivery> <operation> <sitereference>live2</sitereference> <accounttypedescription>fraudscore</accounttypedescription> <amount currencycode="gbp">4999</amount> </operation> <settlement/> </request> </requestblock> Secure Trading Limited October 2014 Page 24 / 30

25 5.2 Example of Medium Level Risk of Fraud Below is example XML that when submitted to our test bank will return a medium level risk of fraud. The number will begin with 50 then the two decimal values following it are randomly generated by the test bank. <?xml version="1.0" encoding="utf-8"?> <requestblock version="3.67"> <alias>securetrading</alias> <request type="fraudscore"> <merchant> <orderreference>example FRAUDSCORE</orderreference> < ></ > </merchant> <customer> <ip> </ip> <name>joe Bloggs</name> </customer> <billing> <town>town</town> <country>gb</country> <payment type="visa"> <expirydate>10/2031</expirydate> <pan> </pan> <securitycode>123</securitycode> </payment> <county>county</county> <postcode>postcode</postcode> <premise>12</premise> < ></ > </billing> <delivery> <town>delivery Town</town> <county>delivery County</county> <country>wa</country> <postcode>zipcode</postcode> <premise>13</premise> <street>street</street> </delivery> <operation> <sitereference>live2</sitereference> <accounttypedescription>fraudscore</accounttypedescription> <amount currencycode="gbp">4999</amount> </operation> <settlement/> </request> </requestblock> Secure Trading Limited October 2014 Page 25 / 30

26 5.3 Example of High Level Risk of Fraud Below is example XML that when submitted to our test bank will return a high level risk of fraud. The number will begin with 80 then the two decimal values following it are randomly generated by the test bank. <?xml version="1.0" encoding="utf-8"?> <requestblock version="3.67"> <alias>securetrading</alias> <request type="fraudscore"> <merchant> <orderreference>example FRAUDSCORE</orderreference> < ></ > </merchant> <customer> <ip> </ip> <forwardedip> </forwardedip> <name>joe Bloggs</name> <telephone> </telephone> <town>new York</town> <country>us</country> <postcode>12345</postcode> </customer> <billing> <town>town</town> <country>us</country> <payment type="visa"> <expirydate>10/2031</expirydate> <pan> </pan> <securitycode>123</securitycode> </payment> <county>ny</county> <postcode>postcode</postcode> <premise>12</premise> < >highrisk@hotmail.com</ > </billing> <delivery> <town>new York</town> <county>delivery County</county> <country>us</country> <postcode>11011</postcode> <premise>13</premise> <street>street</street> </delivery> <operation> <sitereference>live2</sitereference> <accounttypedescription>fraudscore</accounttypedescription> <amount currencycode="gbp">4999</amount> </operation> <settlement/> </request> </requestblock> Secure Trading Limited October 2014 Page 26 / 30

27 5.4 Example of Fraud Score with blocked Authorisation Below is an example where a FRAUDSCORE and an AUTH Request are included within the same request block, and the maxfraudscore value is exceeded, so the authorisation is blocked. <?xml version="1.0" encoding="utf-8"?> <requestblock version="3.67"> <alias>securetrading</alias> <request type="fraudscore"> <merchant> <orderreference>example FRAUDSCORE</orderreference> < ></ > </merchant> <customer> <ip> </ip> < >customer@example.com</ > <name>joe Bloggs</name> </customer> <billing> <town>town</town> <country>gb</country> <payment type="visa"> <expirydate>10/2031</expirydate> <pan> </pan> <securitycode>123</securitycode> </payment> <county>county</county> <postcode>te57 1NG</postcode> <premise>12</premise> < ></ > </billing> <delivery> <town>delivery Town</town> <county>delivery County</county> <country>us</country> <postcode>zipcode</postcode> <premise>13</premise> <street>street</street> </delivery> <operation> <sitereference>live2</sitereference> <accounttypedescription>fraudscore</accounttypedescription> </operation> <settlement/> </request> <request type="auth"> <operation> <accounttypedescription>ecom</accounttypedescription> <maxfraudscore>25.4</maxfraudscore> </operation> <billing> <amount currencycode="gbp">4999</amount> </billing> </request> </requestblock> For the example above, the FRAUDSCORE request will return a score higher than that specified in the maxfraudscore field, so the AUTH is not performed. Secure Trading Limited October 2014 Page 27 / 30

28 <?xml version="1.0" encoding="utf-8"?> <responseblock version="3.67"> <requestreference>x </requestreference> <response type="fraudscore"> <merchant> <orderreference>example FRAUDSCORE</orderreference> </merchant> <transactionreference> </transactionreference> <billing> <payment type="visa"> <pan>424242######4242</pan> </payment> </billing> <timestamp> :02:22</timestamp> <live>1</live> <fraudscore> <billing> <country> <binmatch>0</binmatch> </country> <postcode> <telephonematch>2</telephonematch> </postcode> </billing> <ip> <county>uky2</county> <town>bangor</town> <distance>1</distance> <latitude> </latitude> <country> <billingmatch>1</billingmatch> <isocode>gb</isocode> <highrisk>0</highrisk> </country> <organisation>securetrading</organisation> <isp>st isp</isp> <longitude> </longitude> </ip> <score>32.74</score> <proxy> <openproxyscore>2.0</openproxyscore> <anonymous>0</anonymous> </proxy> < > <free>0</free> </ > </fraudscore> <error> <message>ok</message> <code>0</code> </error> <operation> <accounttypedescription>fraudscore</accounttypedescription> </operation> </response> <response type="error"> <timestamp> :02:23</timestamp> <transactionreference> </transactionreference> <error> <message>max fraudscore exceeded</message> Secure Trading Limited October 2014 Page 28 / 30

29 <code>60036</code> <data>32.74</data> </error> </response> </responseblock> 5.5 Testing Authorisation During integration testing, the following test card details can be used. Please note these are TEST card details, and will not return the expected responses in a LIVE environment. Name of payment type Payment type field Authorisation Decline American Express AMEX Diners DINERS Discover DISCOVER JCB JCB Maestro MAESTRO MasterCard MASTERCARD MasterCard Debit MASTERCARDDEBIT V PAY VPAY Visa VISA Visa Debit DELTA Visa Electron ELECTRON Visa Purchasing PURCHASING For these cards, when performing tests, the tester needs to input an expiry date that is in the future in order for the transactions to be authorised by Secure Trading s fake bank. Secure Trading Limited October 2014 Page 29 / 30

30 6 Further Information and Support This section provides useful information with regards to documentation and support for your Secure Trading solution. 6.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 Details Telephone +44 (0) Fax +44 (0) Website 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 Details Telephone Telephone (Int l) +44 (0) Fax +44 (0) sales@securetrading.com Website Useful Documents The documents listed below should be read in conjunction with this document: STAPI Setup Guide This document outlines how to install the STAPI java client 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 XML Specification This document details how to perform XML Authorisations, Account Checks and Refunds through Secure Trading. Any other document regarding the STPP system can be found on Secure Trading s website ( Alternatively, please contact our support team as outlined above. 6.4 Frequently Asked Questions Please visit the FAQ section on our website ( Secure Trading Limited October 2014 Page 30 / 30