Submitting Transactions in the Direct Model
         

Version 1
www.worldpay.com 

                                   

Table Of Contents

Table Of Contents
About This Guide ..................................................................................................................................1 Copyright............................................................................................................................................1 Introduction............................................................................................................................................2 What is XML Direct? .........................................................................................................................2 Before You Start .....................................................................................................................................4 Introduction........................................................................................................................................4 Error Messages, Invalid XML ..........................................................................................................6 Structure of an XML Direct Order.......................................................................................................8 Introduction........................................................................................................................................8 XML and Document Type Declaration...........................................................................................8 Merchant and Service‐specific Information ...................................................................................8 Order Description and Amount ......................................................................................................9 Order Content ....................................................................................................................................9 Payment Details and Session Information ...................................................................................10 Shopper Information .......................................................................................................................11 XML Direct Order Example ...........................................................................................................12 Response from the Payment Service .................................................................................................15 Introduction......................................................................................................................................15 Reply to an XML Direct Order.......................................................................................................15 Posting an XML Order ........................................................................................................................17 Introduction......................................................................................................................................17 Setting‐up the Connection..............................................................................................................17 Submitting a 3‐D Secure Order..........................................................................................................18 Introduction......................................................................................................................................18 The Process Flow .............................................................................................................................18 XML Messages and HTML Redirect .............................................................................................20 Test Environment ............................................................................................................................24 Appendices...........................................................................................................................................26 Introduction......................................................................................................................................26 Payment Method Codes .................................................................................................................26 ISO Currency Codes........................................................................................................................28 Acquirer Response Codes...............................................................................................................31 ISO Country Codes..........................................................................................................................34

ii 

Table Of Contents

CVC/CVV Checks and Responses.................................................................................................49 Testing Transactions........................................................................................................................50 XML Error Codes.............................................................................................................................52

iii 

About this Guide

About This Guide

This guide describes the specifications of XML orders sent to the WorldPay system in the  XML Direct model. The intended audience is the merchantʹs technical staff or the  merchantʹs system integrator.  Because almost all communication between the merchantʹs system and the WorldPay  Payment Service is realised through predefined XML messages over the Internet using  standard protocols, you will need basic XML programming skills and knowledge of  HTTP(S). Furthermore, it is recommended that you are familiar with the basics of the  Payment system. Where applicable, this document refers to the related documentation  with further details. 

Copyright
© 2008 WorldPay. All rights reserved.  While every effort has been made to ensure the accuracy of the information contained in  this publication, the information is supplied without representation or warranty of any  kind, is subject to change without notice and does not represent a commitment on the part  of WorldPay Ltd. WorldPay Ltd, therefore, assumes no responsibility and shall have no  liability, consequential or otherwise, of any kind arising from this material or any part  thereof, or any supplementary materials subsequently issued by WorldPay Ltd. WorldPay  Ltd has made every effort to ensure the accuracy of this material.     

Submitting Transactions in the Direct Model   ◊   Page 1 

Introduction

Introduction

What is XML Direct?
Merchants who collect and store their shoppersʹ payment details on their own platform  can use the XML Direct model as an effective payment‐processing gateway. With this  model, the merchant collects both order and payment details and then communicates the  relevant payment details on a per order basis with WorldPay, for processing.  

Security
A core issue associated with using the XML Direct model is security. The collection and  storage of payment information, such as, card numbers and cardholder names must take  place in a secure environment.  

Payment Card Industry Data Security Standard (PCI DSS)
PCI DSS is a global Card Scheme initiative that aims to ensure that every entity that  handles, stores or processes cardholder data does so in a secure manner. MasterCard and  Visa have combined their own security standards for cardholder data creating an aligned  program, which is now endorsed by American Express, JCB and Diners. Much of PCI DSS  relates to the technology involved in capturing and processing card data and this is  particularly relevant to those merchants who process and capture cardholder data on their  own systems rather than those who use the secure WorldPay payment pages.   For more information, please refer to PCI DSS and to the PCI Security Standards Council  at: www.pcisecuritystandards.org. If you want any help to gain compliance this site also  lists PCI approved Quality Security Assessors (QSAʹ) who can provide technical advice  (chargeable).  

3-D Secure Authentication
You can reduce your exposure to fraud and increase confidence in online shopping by  implementing 3‐D Secure Authentication with the Direct Model. The additional security  benefits and liability shifts of authenticated transactions are currently only supported by  cards within the Visa and MasterCard brands.    From 30th June 2008, MasterCard requires that your website  implements 3‐D Secure authentication in order for you to continue  accepting Maestro payments. Please also note that at some point in  the future we expect that this mandate will be applied to all Visa  and MasterCard transactions. 

 

 

Submitting Transactions in the Direct Model   ◊   Page 2 

 Authentication should strengthen your existing anti‐fraud  strategy and help protect your business.  For further details about authentication. mail. refer to the Cardholder Authentication guide.Introduction The benefits of the 3‐D Secure process are the enhanced security available when  performing an authenticated transaction as well as the shift of liability in the event of  fraudulent transactions. or phone orders. Submitting Transactions in the Direct Model   ◊   Page 3  . nor do they cover all card types. but bear in mind that coverage of authentication  programmes is currently limited to Internet transactions. This means that authentication  programmes do not cover fax.

 that is.Before You Start Before You Start Introduction From a technical / IT viewpoint. involves the following major steps:  • order creation: automating the creation of an XML document that conforms with  the rules specified in the WorldPay Document Type Definition (DTD). You have a choice of how you automate the reception of replies using one  of the following two methods. if  necessary.    • account settings: before sending test orders to the Payment Service check and. For  example. This topic is covered in detail  in this guide. update settings that control aspects of how the service works.   • • o • modify and query order data: administer transactions ʹremotelyʹ. Order notifications can be sent through  two different channels: email (SMTP) and HTTP(S) and in different  formats: CGI. setting up a successful connection between your system  and the WorldPay payment system. WorldPay  will send an HTTP POST of the payment information from our server to a  URL on your server via HTTP(S). setting a delay between authorisation and capture.  payment response: automate the reception and processing of replies from our  system.    order submission: setting up an HTTP(S) connection between your system and ours  and automating the sending of XML orders over that connection. For details. you can report on payment status  changes of individual payments.   Order Notifications ‐ when enabled. Using this functionality you can select  the channel (protocol) and format. This guide  provides an overview only. WorldPay cannot advise on how to  specifically create an XML order using ASP or PHP.   o HTTP(S) Payment Response feature (callback) ‐  when enabled. or how to  establish the secure connection. refer to the (HTML)  Payment Response guide.   Order creation can be achieved in a number of different ways  depending on the scripting language that you are using. from outside  (and in addition to) WorldPayʹs Merchant Administration Interface (MAI). This topic is  covered in this guide. You  have a choice of how you work remotely using one of the following:  Submitting Transactions in the Direct Model   ◊   Page 4  . from order  data captured from your shoppers by your systems. text and XML.

 capture or refund the payment that belongs  to an order. The settings  can then be copied over to the Test environment.   Note to remember: you have a separate Merchant Administration Interface for your  Production environment and for your Test environment.Before You Start o WorldPayʹs ʹRemote Administrationʹ feature.com/admin   Any changes to settings must be made in the Production  environment in the Merchant Administration Interface.  The XML password is your Invisible Auth password. You can login to both. This is set up by default by  WorldPay.   Connect Using Login Name and XML Password When setting up the HTTP(s) connection over which you will send XML orders. please contact Customer Services at:  customerservices@worldpay.worldpay. by  sending an XML order inquiry you can actively inquire about the current  payment status of an existing order. Most settings can  be amended from within the Installation page of the Merchant Administration Interface. This functionality automates the  creation of XML statements that conform to the rules as specified in the  WorldPay DTD.  Your XML password can only be changed by WorldPay. then the  password is that of the lowest Installation ID. If there are multiple installations used by your Administration. can only be modified via  our online administration tool.  Account Settings A number of the settings that affect the way the service works.  This includes the settings for administrating the reception and processing of replies from  the WorldPay system.   Your login name is the relevant merchant code (to look up the merchant code(s) allocated  to your organisation. This feature enables you to  complete a transaction after a capture delay. login to the Merchant Administration Interface and refer to the  status box in the left‐hand side of the page). If you  need to change your password. or refund a captured  transaction. to modify and query order data in our system.  Order Modifications and Inquiries.  remember to use a valid login and password.com. This  service enables you to cancel. the Merchant Administration Interface. via:  http://www. Additionally.   o Please note the following before proceeding. or to add a back‐office code to an order.    Submitting Transactions in the Direct Model   ◊   Page 5  .

com/paymentService_v1.org for further details on XML and parsers.   XML elements can be declared to contain:  • name tokens (NMTOKEN)   Submitting Transactions in the Direct Model   ◊   Page 6  . This ensures that the messages sent are valid and messages received are  correctly interpreted. Do not rely on a self‐built parser.worldpay.  XML messages must adhere to the following rules in order to be accepted. Invalid XML Receiving ʺInvalid XMLʺ error messages? No orders created? Wondering why your XML  is “invalid”? The most common cause of error when posting XML to the Payment Service  is incorrectly formed XML. For the XML to be  well‐formed.dtd"> Use Declared Elements Only Every element.Before You Start Error Messages.  Reference the DTD A valid XML message must always include a reference to the DTD.  XML messages should be parsed prior to sending them to the WorldPay Payment Service  and upon receipt. must be declared in the  DTD (Document Type Definition).  For examples of XML errors messages our system may return.0"? encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.xml. please ensure that you are using an industry  standard Parser that parses the message against the Document Type Definition (DTD)  (refer to Reference the DTD below). it must adhere to a number of rules. attribute and entity in the XML that you send. Please refer to  http://www.  Use Valid Syntax All XML messages sent to the system must be well‐formed and valid. so it can be  automatically compared with it in order to check if all the references used are correct. When parsing. including:  • • • • • • • every start tag must have a matching end tag  elements must not overlap  there must be exactly one root element  attribute values must be quoted  an element may not have two attributes with the same name  comments and processing instructions may not appear inside tags  no unescaped [<] or [&] signs may occur in the elementʹs or attributeʹs character  data.   Most of the incorrect XML issues will be resolved by using an industry standard parser. please refer to the appendix  XML Error Codes.  The DTD is specified in the header of the XML message and will look as follows:  <?xml version="1.

 No other characters are allowed.]. [‐]. [<]. and [:]. [>] and [ʺ]. An XML name  token may not contain white spaces.  The DTD can be found at: http://dtd. If you need to use these characters  within a PCDATA block you should specify them as follows:   & = &amp. for the description element which is declared to contain PCDATA  <!ELEMENT description (#PCDATA )> a valid example would be:  <description>Your Holland &amp.  A CDATA block must be enclosed between the start tag <[CDATA[ and the end tag ]]>. the values of  these attributes must be legal XML name tokens. [.   If an attribute is declared to contain a name token or list of name tokens.  For example.  > = &gt. Holland Catalogue</description> CDATA In a CDATA (Character DATA) block it is allowed to include any data / characters as long  as it adheres to the specified encoding and does not contain the character sequence:  ]]>.  < = &lt.worldpay.com/paymentService_v1.dtd   Name Tokens An XML name token consists of alphanumeric and/or ideographic characters and the  punctuation marks [_].Before You Start • • parsed character data (PCDATA)   character data (CDATA) or constants.   ʺ = &quot.  For example:  <[CDATA[This text has not been parsed & still can be used]]>       Submitting Transactions in the Direct Model   ◊   Page 7  . Below you can find an example of this:  <!ELEMENT amount EMPTY> <!ATTLIST amount value NMTOKEN #REQUIRED currencyCode NMTOKEN #REQUIRED exponent (0 | 2 | 3 ) #REQUIRED debitCreditIndicator (debit | credit ) 'credit' > A valid instance of an amount element looks like this:  <amount value="4938" currencyCode="SEK" exponent="2" /> PCDATA In a PCDATA (Parsed Character DATA) block in the XML message the following special  characters should not be included: [&].

 please refer to the chapter  Submitting a 3D‐Secure Order. that is.worldpay.  XML and Document Type Declaration To process an XML Direct order the submission must begin with an XML declaration and  a document type declaration.0"?> <!DOCTYPE paymentService PUBLIC "-//worldpay//DTD WorldPay PaymentService v1//EN" "http://dtd. they have a correct XML syntax. and  conform to a Document Type Definition.com XML files are valid if they are well‐formed.Structure of an XML Direct Order Structure of an XML Direct Order Introduction Orders submitted to the WorldPay system are required to be valid XML files as specified  in this guide and in the Document Type Definition (DTD). available at:  http://dtd.dtd"> Merchant and Service-specific Information The paymentService root element has two required attributes: the version number of  the Payment Service DTD and your merchant code.com/paymentService_v1.   The topics covered in this chapter are:  • • • • • • • XML and Document Type Declaration  Merchant and Service‐specific Information  Order Description and Amount  Order Content  Payment Details and Session Information  Shopper Information  XML Order Example  Note for details of submitting a 3‐D Secure payment request.  An example for merchant code WPACC11112222 is:  Submitting Transactions in the Direct Model   ◊   Page 8  . The merchant code is issued by  WorldPay and is always in capitals.worldpay. containing the root element paymentService and the  reference to our public DTD:   <?xml version="1.

 neither spaces. counting from the right)..   an installation id attribute.    An order with a previously used order code cannot be processed  correctly and you are likely to receive error messages and encounter  problems with reporting. The amount element has the attributes: value (no decimal  point or comma).    The first two child elements of the order element are description and amount. You can deliver the  order content in HTML format. then we recommend you use either:  • • • the description element (see below) to enter the Cart ID.Structure of an XML Direct Order <paymentService version="1. the currencyCode (ISO 4217 code) and exponent (specifies where the  decimal point or comma should be placed.  <order orderCode="T0211010" installationId="12345"> <description>20 English Roses from MYMERCHANT Webshops</description> <amount currencyCode="GBP" exponent="2" value="5000"/> . A list of currency codes and their  respective exponents can be found in the appendix ISO Currency Codes.     You may use the orderCode attribute to contain a Cart ID as long as it is unique. </order> Order Content The third child element of the order element is orderContent.   The order content must be less than 10 kilobytes and should always be included in a  CDATA section to avoid parsing problems.4" merchantCode="WPACC11112222"> <submit> . This should be your XML Invisible installation id that you  have received from WorldPay. or  use the orderCode attribute but append a unique number to a static Cart ID... The amount value is  the total amount the shopper is expected to pay.. When supplying HTML order content the only HTML tags  allowed are the tags permitted between the <body> and </body> tags of a valid HTML  document! No form of scripting is allowed in the order content. </submit> </paymentService> The paymentService element contains the child element <submit> to classify the XML  message as a submission. The  description element should contain a simple one‐line description of the order and can  be up to 255 characters long.   Submitting Transactions in the Direct Model   ◊   Page 9  .  Order codes can be up to 64  characters long.   Order Description and Amount Within the submit element. quotes nor the ʺ<ʺ and ʺ>ʺ characters are allowed. the order element and its content describe the goods or  services that are being ordered. If a  Cart ID is not unique.   The order element has two required attributes:  • an orderCode attribute whose value must be unique.

 where VISA-SSL is the  payment method code.     An example of the paymentDetails for a VISA payment. They are a mandatory element in a 3‐D Secure  transaction. Each payment method has its own set of sub‐elements and  attributes. Please refer to the specifications of the paymentDetails element in the DTD  for an up‐to‐date list of available payment method codes for the Direct model and their  child elements.Structure of an XML Direct Order <orderContent> <![CDATA[content here]]> </orderContent> The order content may contain:    • • • • • • • • • order code  product(s) and/or service(s) ordered  item price  total amount  shopper billing address  shopper shipping address  contact details merchant  the fact that WorldPay processes the payment  the fact that the name WorldPay may appear on the shopperʹs bank or credit card  statements.   WorldPay uses the payment details and session information for risk  assessment.   In addition to the regular payment details you need to provide information about the  shopper browser session in the paymentDetails child element session. is:  Submitting Transactions in the Direct Model   ◊   Page 10  .  Payment Details and Session Information The fourth order child element is paymentDetails and contains the details of the  selected payment method. containing the  shopperIPAddress and session id. The payment method codes are listed in the appendix Payment Method  Codes.

123.> <postalCode>CB94BQ</postalCode> <countryCode>GB</countryCode> <telephoneNumber>0123456789</telephoneNumber> </address> </cardAddress> </VISA-SSL> <session shopperIPAddress="123. This  example shows paymentDetails for SOLO_GB‐SSL:  <paymentDetails> <SOLO_GB-SSL> <cardNumber>6333333333333333336</cardNumber> <expiryDate><date month="05" year="2009"></expiryDate> <cardHolderName>J. For  details please refer to the appendix CVC/CVV Checks And Responses. Shopper</cardHolderName> <issueNumber>07</issueNumber> </SOLO_GB-SSL> </paymentDetails>   Shopper Information You can provide extra information about the shopper in an XML order by using the  order child element shopper. or to send an email to the shopper  when the payment is authorised or refused.We recommend that you include the whole address in this field with the exception of postalCode and CountryCode. including possible zeros in front.123.    For the Solo (SOLO_GB‐SSL) payment method either the issue number or the start date  must be included in the paymentDetails.123" id="02l5ui8ib1"/> </paymentDetails>   Note that the cvc element contains the Card Verification Code. The non‐numeric parts are ignored. depending on the issuer policy.int</shopperEmailAddress> </shopper>   Submitting Transactions in the Direct Model   ◊   Page 11  .Structure of an XML Direct Order   <paymentDetails> <VISA-SSL> <cardNumber>4444333322221111</cardNumber> <expiryDate> <date month="09" year="2009"/> </expiryDate> <cardHolderName>J. Please note  that the issue number can be up to three digits.  <shopper> <shopperEmailAddress>jshopper@myprovider.  Also note that the numeric parts (if there are any) of the street element  are used in the AVS check. Its shopperEmailAddress element is used by  WorldPay to identify possible fraudulent transactions. Shopper</cardHolderName> <cvc>123</cvc> <cardAddress> <address> <firstName>John</firstName> <lastName>Shopper</lastName> <street>47A Queensbridge Rd</street> <!-.

</td></tr> <tr><td bgcolor="#ffff00" colspan="3">Your billing address:</td></tr> <tr><td colspan="3">Mr.  Please note that a browser‐view picture of the order is shown below.worldpay. The merchant is the  MYMERCHANT Webshop with merchant code WPACC11112222.com</td></tr> </table></center> ]]> </orderContent> <paymentDetails> <VISA-SSL> <cardNumber>4444333322221111</cardNumber> <expiryDate> <date month="09" year="2007"/> </expiryDate> <cardHolderName>J.50 each and has an order code: T0211010.int<br>01234 567 890</td></tr> <tr><td colspan="3">&nbsp.25</td></tr> <tr><td colspan="2" bgcolor="#c0c0c0">Total cost:</td><td bgcolor="#c0c0c0" align="right">GBP 14.Structure of an XML Direct Order XML Direct Order Example An example of a complete XML order for the Direct model is shown below. Shopper<br> 47A Queensbridge Road<br>Cambridge<br>CB9 4BQ<br>UK</td></tr> <tr><td colspan="3">&nbsp.4" merchantCode="WPACC11112222"> <submit> <order orderCode="T0211010" installationId="12345"> <description>20 English Roses from MYMERCHANT Webshops</description> <amount value="1400" currencyCode="GBP" exponent="2"/> <orderContent> <![CDATA[ <center><table> <tr><td bgcolor="#ffff00">Your Internet Order:</td><td colspan="2" bgcolor="#ffff00" align="right">T0211010</td></tr> <tr><td bgcolor="#ffff00">Description:</td><td>20 English Roses</td><td align="right">0.50</td></tr> <tr><td colspan="2">Subtotal:</td><td align="right">10. Shopper<br>47A Queensbridge Road<br>Cambridge<br>CB9 4BQ<br>United Kingdom</td></tr> <tr><td colspan="3">&nbsp.  Shopper and the used payment method is VISA.  <?xml version="1. Shopper</cardHolderName> <cvc>123</cvc> <cardAddress> <address> <firstName>John</firstName> <lastName>Shopper</lastName> <street>47A Queensbridge Rd<street/> Submitting Transactions in the Direct Model   ◊   Page 12  .00</td></tr> <tr><td colspan="2">VAT: 17.75</td></tr> <tr><td colspan="2">Shipping and Handling:</td><td align="right">2.J.</td></tr> <tr><td bgcolor="#ffff00" colspan="3">Our contact information:</td></tr> <tr><td colspan="3">MYMERCHANT Webshops International<br>461 Merchant Street <br>Merchant Town<br>ZZ1 1ZZ<br>UK <br>mymerchant@webshops.5%</td><td align="right">1.</td></tr> <tr><td bgcolor="#c0c0c0" colspan="3">Billing notice:</td></tr> <tr><td colspan="3">Your payment will be handled by WorldPay<br>This name may appear on your bank statement<br>http://www. J.00</td></tr> <tr><td colspan="3">&nbsp.</td></tr> <tr><td bgcolor="#ffff00" colspan="3">Your shipping address:</td></tr> <tr><td colspan="3">Mr.dtd"> <paymentService version="1.com/paymentService_v1.worldpay. the shopper is Mr. J.0"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay/DTD WorldPay PaymentService v1//EN" "http://dtd. The order is  for 20 English Roses at £0.

--> <postalCode>CB94BQ</postalCode> <city>Cambridge</city> <countryCode>GB</countryCode> <telephoneNumber>01234567890</telephoneNumber> </address> </cardAddress> </VISA-SSL> <session shopperIPAddress="123.Please note that if no house or apartment number is included then a house name can be included using the <houseName> element.Structure of an XML Direct Order <!-..We recommend that you include the whole address in this field with the exception of postalCode and CountryCode.int</shopperEmailAddress> </shopper> <shippingAddress> <address> <firstName>John</firstName> <lastName>Shopper</lastName> <street>47A Queensbridge Rd<street/> <!-.123" id="0215ui8ib1" /> </paymentDetails> <shopper> <shopperEmailAddress>jshopper@myprovider.  The image below shows what this order content looks like when viewed with a web  browser.   Submitting Transactions in the Direct Model   ◊   Page 13  .--> <postalCode>CB94BQ</postalCode> countryCode>GB</countryCode> <telephoneNumber>01234567890</telephoneNumber> </address> </shippingAddress> </order> </submit> </paymentService> The CDATA section in the orderContent element contains a complete invoice in HTML.123.123.

Structure of an XML Direct Order   Figure 1: Example HTML order content as viewed with a browser.     Submitting Transactions in the Direct Model   ◊   Page 14  .

xml.dtd"> <paymentService merchantCode="WPACC11112222" version="1. which may not be able to correctly interpret  the messages received from WorldPay.worldpay. The result of the  authorisation request is reported to WorldPay online as either AUTHORISED or  REFUSED.4"> <reply> <orderStatus orderCode="T0211010"> <payment> <paymentMethod>VISA-SSL</paymentMethod> <amount value="1400" currencyCode="GBP" exponent="2" debitCreditIndicator="credit"/> <lastEvent>AUTHORISED</lastEvent> <CVCResultCode description="APPROVED"/> <balance accountType="IN_PROCESS_AUTHORISED"> <amount value="1400" currencyCode="GBP" exponent="2" debitCreditIndicator="credit"/> </balance> <cardNumber>4444********1111</cardNumber> </payment> </orderStatus> </reply> </paymentService> Submitting Transactions in the Direct Model   ◊   Page 15  .0"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd. shown earlier. For various platforms different XML parsers exist.  Reply to an XML Direct Order The example below shows a possible XML reply from WorldPay for a successful  authorisation of the example order.org. WorldPay sends an XML response to your system  that contains the payment status of the order. please refer to the  chapter Submitting a 3‐D Secure Order. Do not depend on a homemade one.  Please refer to http://www.  <?xml version="1.  • Reply to an XML Direct Order  Note for details of replies in response to a 3‐D Secure payment request.Response from the Payment Service Response from the Payment Service Introduction When the Payment Service has received a valid order with payment details it will send  the information to the financial institutions (acquirers) for authorisation.  When parsing WorldPayʹs reply it is important that you use an industry standard XML  parser.com/paymentService_v1. In the XML Direct model.  The topics covered in this chapter are listed below.

  Submitting Transactions in the Direct Model   ◊   Page 16  . A CVC result description is  reported through the CVCResultCode element.   Always refer to the WorldPay DTD for an up‐to‐date list of child elements and attributes  of the reply element.  For credit card payments the first  and last four digits of the card number are returned in the cardNumber element. The balance element reports on the  balance in the IN_PROCESS_AUTHORISED account. the payment element holds the relevant payment details and status  information. Its child elements paymentMethod and amount contain the payment  method used and the amount.  The payment status is specified by the lastEvent element. including the currency.Response from the Payment Service In the reply. its exponent and the  debitCreditIndicator that indicates the amount is positive.

 How you create a connection with the WorldPay server depends on the  specifications of your platform.jsp  Production/Live environment:  https://secure.ims.  o Setting‐up the Connection  Setting-up the Connection Once you have set up the connection to the Payment Service using a valid login and  password.ims.worldpay.worldpay. while specifying it  incorrectly will.com/jsp/merchant/xml/paymentService. Not specifying the content length will not create errors. your system has to post the XML order.com/jsp/merchant/xml/paymentService.Posting an XML Order   Posting an XML Order Introduction To submit an XML order you have to set up an HTTP(S) connection to the Payment  Service.jsp  o   Submitting Transactions in the Direct Model   ◊   Page 17  .  The URLs to post orders to are:  o Test environment: https://secure‐ test.  Make sure the HTTP content type is “text/xml”! It is important to check that ‘content lengthʹ  is specified correctly.  The topics covered in this chapter are listed below.

 This page is provided and hosted by  the shopperʹs Card Issuer.  Submitting Transactions in the Direct Model   ◊   Page 18  .  Implementing a 3‐D Secure Authentication is described in the following topics:  • • The Process Flow ‐ a diagram showing the flow of information during the  authentication process   XML Messages and HTML Redirect ‐ examples of the XML messages and the HTML  redirect page   o o o o o • Initial Order Message (arrow 2 in diagram)  Initial Order Reply Message (arrow 3 in diagram)  Redirect Shopper to Issuer (arrow 4 in diagram)  Second Order Message (arrow 6 in diagram)  Second Order Reply Message (arrow 8 in diagram)  Test Environment ‐ how to use the test environment   The Process Flow The figure below describes the flow of messages between the different entities involved. Please note that our Test Environment enables you to test your  implementation. This process involves providing replies to two XML messages and  redirecting the shopper to an authentication page.Submitting a 3-D Secure Order Submitting a 3-D Secure Order Introduction This chapter describes how you should implement 3‐D Secure Authentication using the  XML Direct model.

the shopper places an order with the merchant  the merchant sends an XML message with order information to our system. please refer to Second Order Reply Message (arrow 9)  4. then the merchant will receive either a Refused message from  WorldPay if the Risk Management Module (RMM) is activated or if the RMM is  not activated then you will receive the 3‐D Secure referral message again (step 3)  if the authentication response shows that the shopper was authenticated then we  verify that the authentication response belongs to the authentication request and  proceed with authorisation exchange with the acquirer. refer  to Initial Order Message (arrow 2)  WorldPay verify that the card is participating in 3‐D Secure ‐ a reply message is  sent back to the merchant to request payer authentication.Submitting a 3-D Secure Order   Figure: The Process Flow 1. WorldPay send an authorisation  response to the merchant. 7. refer to Initial Order  Reply Message (arrow 3)  the merchant redirects the shopper to the issuer site for authentication using  information in the reply message. 3. 2. and the payer authentication  response is then posted to the merchantʹs site  the merchant includes the authentication response in the original XML order  message and sends it to WorldPay. 5. Submitting Transactions in the Direct Model   ◊   Page 19  . 6. please refer to Second Order Message (arrow  6)  if the authentication response shows that the shopper failed to authenticate  themselves. please refer to Redirect the Shopper to Issuer  (arrow 4)  the authentication response is sent to the shopper. 9. including the 3‐D Security  Authentication information  after receiving the response from the acquirer. 8.

4"> <submit> <order orderCode="merchantGeneratedOrderCode" installationId="12345"> <description>Description</description> <amount currencyCode= exponent="2" value="5000"/> <orderContent>Default Order Content</orderContent> <paymentDetails> <VISA-SSL> <cardNumber>4111111111111111</cardNumber> <expiryDate> <date month="02" year="2008"/> </expiryDate> <cardHolderName>3D</cardHolderName> </VISA-SSL> <session shopperIPAddress="123.Submitting a 3-D Secure Order XML Messages and HTML Redirect The following XML messages and HTML page are involved in the authentication process:   • • • • • the initial order message (arrow 2 in diagram)  reply for the initial order message (arrow 3 in diagram)   redirect the shopper to the issuer (arrow 4 in diagram)   the second order message with the authentication response (arrow 6 in diagram)  reply for the second order message (arrow 8 in diagram)  Creating an Initial Order Message (arrow 2) The following section details the additional XML required to process a request and  explains the information returned in the subsequent response.0 .123" id="112233"/> </paymentDetails> <shopper> <browser> <acceptHeader>text/html</acceptHeader> <userAgentHeader>Mozilla/5.  The acceptHeader element should contain the exact content of the HTTP accept header  as sent to the merchant from the shopperʹs user agent. Only a few  additional elements are added and some elements are made mandatory for use with 3‐D  Secure.  Submitting Transactions in the Direct Model   ◊   Page 20  .123.   The following order message example shows only the mandatory elements..  <paymentService merchantCode="MYMERCHANT" version="1. acceptHeader and userAgentHeader. These  elements are used to redirect the shopper to the correct issuer site for authentication.  The userAgentHeader element should contain the exact content of the HTTP user‐agent  header as sent to the merchant from the shopperʹs user agent.  The first order message is almost the same as the regular order messages..123.</userAgentHeader> </browser> </shopper> </order> </submit> </paymentService> The new elements are browser.

 The merchant is  responsible for suppling a correct value.Submitting a 3-D Secure Order Initial Order Reply Message (arrow 3) This message extends the orderStatus element with a new sub‐element. This attribute can be used by the merchant to handle the session state  between the original shopping session and the final post after the shopper has been  authenticated. This element  must be supplied in all subsequent messages as‐is.html</issuerURL> </request3DSecure> </requestInfo> <echoData>somedata</echoData> </orderStatus> </reply> </paymentService> The element paRequest contains data that was received from the 3‐D Security Directory. Optionally it can contain an attribute ʺMDʺ. It specifies  the service to which the shopper is redirected from the issuerʹs site. to which the form must be posted. An example of the complete message is shown below.  Redirect the Shopper to Issuer (arrow 4) When the merchant receives the first reply with the request for 3‐D Secure authentication. requestInfo.  The issuerURL element contains the actual URL to which the shopper must be  redirected.  The Issuerʹs site URL.  The ʺMDʺ attribute can contain any data and will be supplied as‐is in the final post when  the shopper is redirected from the Issuerʹs site to the merchantʹs site (the value of the  TermUrl attribute).  The value for the ʺPaReqʺ attribute must be the data supplied in the paRequest element  of the reply message.  This data must be supplied as‐is in the redirect message to the shopperʹs issuer site.  An extra element echoData is added. The form must contain the attributes ʺPaReqʺ and  ʺTermUrlʺ.  A request for 3‐D Secure authentication is defined with element name  request3DSecure.url/3dsec.4"> <reply> <orderStatus orderCode='merchantGeneratedOrderCode'> <requestInfo> <request3DSecure> <paRequest>somedata</paRequest> <issuerURL>http://example. is given in the issuerUrl  element of the reply message. which is used by our software to process the  subsequent messages belonging to the same transaction more efficiently.  <paymentService merchantCode="MYMERCHANT" version="1.  the merchant must redirect the shopper to the issuerʹs site. This must be done by posting  an HTML form to the Issuer URL.  This HTML example page redirects the shopper to the Issuerʹs site:    Submitting Transactions in the Direct Model   ◊   Page 21  .  This element is a container for possible requests for information on the submitted order.issuer. This is shopperʹs Issuer site where the shopper should authenticate themselves  with the 3‐D Secure mechanism.  The value for the ʺTermUrlʺ attribute is a URL pointing to the merchantʹs site.

If your browser does not start loading the page.submit(). the shopper must press  the Submit button in order to continue.123" id="112233"/> <info3DSecure> <paResponse>somedata</paResponse> </info3DSecure> </paymentDetails> <shopper> <browser> <acceptHeader>text/html</acceptHeader> <userAgentHeader>Mozilla/5. <form name="theForm" method="POST" action="value of the issuerUrl element" > <input type="hidden" name="PaReq" value="value of the paRequest element" /> <input type="hidden" name="TermUrl" value="url of merchant site" /> <input type="hidden" name="MD" value="merchant supplied data" /> <input type="submit" name="Identify yourself" /> </form> <script language="Javascript"> <!-function OnLoadEvent() { // Make the form post as soon as it has been loaded...  <paymentService merchantCode="MYMERCHANT" version="1.123. <br/> After you successfully identify yourself you will be sent back to this site where the payment process will continue as if nothing had happened.. the shopper will automatically  be forwarded to the Issuerʹs site.0 .4"> <submit> <order orderCode="merchantGeneratedOrderCode" installationId="12345"> <description>Description</description> <amount currencyCode="GBP" exponent="2" value="5000"/> <orderContent>Default Order Content</orderContent> <paymentDetails> <VISA-SSL> <cardNumber>4111111111111111</cardNumber> <expiryDate> <date month="02" year="2006"/> </expiryDate> <cardHolderName>3D</cardHolderName> </VISA-SSL> <session shopperIPAddress="123."> This page should forward you to your own card issuer for identification. As shown in the example below. press the button you see.. Only two  elements are added. document.Submitting a 3-D Secure Order <html> <head> <title>3-D Secure helper page</title> </head> <body OnLoad="OnLoadEvent().  Second Order Message (arrow 6) The second order message is almost the same as the initial order message.123. } // --> </script> </body> </html> When the shopper has enabled Javascript in the browser.</userAgentHeader> </browser> Submitting Transactions in the Direct Model   ◊   Page 22  .theForm.<br/> implemented. the info3DSecure element (and sub elements) and the echoData  element. If Javascript has been disabled.

 In order to facilitate this. you will receive  a normal REFUSED reply.  In the echoData element.4"> <reply> <orderStatus orderCode='merchantGeneratedOrderCode'> <requestInfo> <request3DSecure> <paRequest>ThePaReq</paRequest> <issuerURL>http://example. you need to  extract the session cookie that is passed back in the header of the  XML document (the response from the Payment Service) and return  it in the header of the second XML order. the merchant must supply the same data as it received in the  first reply message. you will  receive the 3D‐Secure referral message again (refer to Initial Order Reply Message (3)).Submitting a 3-D Secure Order </shopper> <echoData>somedata</echoData> </order> </submit> </paymentService> The info3DSecure element contains the payer authentication response data received by  the shopper/merchant from the issuer. then you will receive one of two replies  depending on whether the Risk Management Module is activated or not.    Failed Authentication (arrow 7) If a shopper fails to authenticate themselves.  Refused If the Risk Management Module is implemented for your Administration.  <payment> <paymentMethod>MAESTRO-SSL</paymentMethod> <amount value="2750" currencyCode="GBP" exponent="2" debitCreditIndicator="credit"/> <lastEvent>REFUSED</lastEvent> <ISO8583ReturnCode code="76" description="CARD BLOCKED"/> </payment> 3D-Secure Referral Message If the Risk Management Module is not implemented for your Administration.   <paymentService merchantCode="MYMERCHANT" version="1.issuer.url/3dsec.html</issuerURL> </request3DSecure> </requestInfo> <echoData>somedata</echoData> </orderStatus> </reply> </paymentService> Submitting Transactions in the Direct Model   ◊   Page 23  .  Note that we use a farm of web servers to serve the requests and  WorldPay need to ensure that the first and second orders are  successfully matched up.

     The value of the cardHolderName element in the XML order message can be used to  manipulate the test. There are these possibilities:  • • a value of IDENTIFIED means the shopperʹs identity is successfully verified  a value of NOT_IDENTIFIED means the shopperʹs identification could not be  verified  Submitting Transactions in the Direct Model   ◊   Page 24  . the 3‐D Security Directory would  respond with enrolled)  if the cardHolderName is NO3D then the test environment will act as if the  credit card is not participating in 3‐D Secure (that is. the Directory would respond  with not‐enrolled)  with any other value for cardHolderName.4"> <reply> <orderStatus orderCode="merchantGeneratedOrderCode"> <payment> <paymentMethod>VISA-SSL</paymentMethod> <amount currencyCode="EUR" debitCreditIndicator="credit" exponent="2" value="10000"/> <lastEvent>AUTHORISED</lastEvent> <balance accountType="IN_PROCESS"> <amount currencyCode="EUR" debitCreditIndicator="credit" exponent="2" value="10000"/> </balance> <balance accountType="AUTHORISED"> <amount currencyCode="EUR" debitCreditIndicator="debit" exponent="2" value="10000"/> </balance> <cardNumber>4111********1111</cardNumber> </payment> </orderStatus> </reply> </paymentService> Test Environment In order for merchants to test their 3‐D Secure implementation. the test environment will act as if it is  a normal e‐commerce transaction (that is. No additional elements are added.  <paymentService merchantCode="MYMERCHANT" version="1. no lookup with the Directory).Submitting a 3-D Secure Order Second Reply Message (arrow 9) Authorised If the shopper authenticates successfully. This service can be used to submit dummy XML orders. as follows:  • if the cardHolderName is 3D then the test environment will act as if the credit  card is participating in 3‐D Secure (that is. Note that you must be  enabled for 3‐D Secure before you can use the test payment service. we provide a test payment  service. you will receive the normal reply for authorised  payments.  • • You can use the value of the paResponse element to manipulate the outcome of the  payer authentication. We also provide a  dummy issuer site so that part of the process can also be tested.

 such as those shown above.  otherwise a parse error will be generated. in the Test environment you  should use considerably shorter lengths.7KB. However.              Submitting Transactions in the Direct Model   ◊   Page 25  . the length of the paResponse  element can be up to 4.Submitting a 3-D Secure Order • • a value of UNKNOWN_IDENTITY means that the authentication failed  and any other value means the verification process itself failed.  Using the dummy issuer site. these three options can be selected with a drop‐down list.  Note that in the Production environment.

  payment method paymentType Amex  AMEX‐SSL  Diners  Card  DINERS‐SSL  ELV  ELV‐SSL  JCB Card  JCB‐SSL  MasterCard  ECMC‐SSL  Solo Card  SOLO_GB‐SSL  Maestro  MAESTRO‐ SSL  Submitting Transactions in the Direct Model   ◊   Page 26  .Appendices Appendices Introduction The appendices available for this guide are listed below.  o o o o o o o Payment Method Codes  ISO Currency Codes  Acquirer Response Codes  ISO Country Codes  CVC/CVV Checks and Responses  Testing Transactions  XML Error Codes  Payment Method Codes The child elements below are used to define the card type that is used by the shopper.

Appendices Visa Card  VISA‐SSL  Visa Delta  VISA‐SSL  Visa  Electron  VISA‐SSL  Visa  Purchasing  VISA‐SSL  Submitting Transactions in the Direct Model   ◊   Page 27  .

 Merchants should use ʹexponentʹ instead.82:  <amount value="1982" currencyCode="EUR" exponent="2"/> The full ISO 4217 list can be found at: http://www.html  ISO 4217 Currency Codes code ARS  Name Nuevo  Argentine  Peso  Australian  Dollar  Brazilian  Real  Canadian  Dollar  Exponent 2  AUD  2  BRL  2  CAD  2  CHF  CLP  Swiss Franc  2  Chilean  Peso  Yuan  Renminbi  2  CNY  2  COP  Colombian  2  Peso  Czech  Koruna  Danish  Krone  Euro  2  CZK  DKK  2  EUR  2  Submitting Transactions in the Direct Model   ◊   Page 28  .id3.Appendices ISO Currency Codes Currencies accepted by the WorldPay Payment Service are listed below.  In the following example the amount payable by the shopper is Euro 19.org/iso4217. Also note that currency code is always in capitals. Exponent is the number of decimals  available in the currency.  Please note that the values in the orders sent to WorldPay NEVER have any decimal  delimiters.

Appendices GBP  Pound  Sterling  2  HKD  Hong Kong  2  Dollar  Hungarian  2  Forint  Indonesian  0  Rupiah  Iceland  Krona  Japanese  Yen  Kenyan  Shilling  South‐ Korean  Won  Mexican  Peso  Malaysian  Ringgit  2  HUF  IDR  ISK  JPY  2  KES  2  KRW  2  MXP  2  MYR  2  NOK  Norwegian  2  Krone  New  Zealand  Dollar  Philippine  Peso  2  NZD  PHP  2  PLN  New Polish  2  Zloty  Portugese  Escudo  Swedish  Krone  2  PTE  SEK  2  Submitting Transactions in the Direct Model   ◊   Page 29  .

Appendices SGD  Singapore  Dollar  Slovak  Koruna  Thai Baht  New  Taiwan  Dollar  US Dollars  2  SKK  2  THB  TWD  2  2  USD  VND  2  Vietnamese  2  New Dong  South  African  Rand  2  ZAR    Submitting Transactions in the Direct Model   ◊   Page 30  .

 Below you will find all  possible response codes. PICK UP  status AUTHORISED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  Submitting Transactions in the Direct Model   ◊   Page 31  .   The Payment Service maps these responses to a simplified list.Appendices Acquirer Response Codes WorldPay uses the ISO 8583 Response Codes in the orderStatusEvent messages to indicate  the status of the payment: AUTHORISED. etc. their numeric value and the mapping to a status.  ISO 8583 Response Codes code message value 0 AUTHORISED  2 REFERRED  4 HOLD CARD  5 REFUSED  8 APPROVE AFTER  IDENTIFICATION  13 INVALID AMOUNT  15 INVALID CARD ISSUER  17 ANNULATION BY CLIENT  28 ACCESS DENIED  29 IMPOSSIBLE REFERENCE  NUMBER  33 CARD EXPIRED  34 FRAUD SUSPICION  38 SECURITY CODE EXPIRED  41 LOST CARD  43 STOLEN CARD. REFUSED.

Appendices 51 LIMIT EXCEEDED  55 INVALID SECURITY CODE  56 UNKNOWN CARD  57 ILLEGAL TRANSACTION  62 RESTRICTED CARD  63 SECURITY RULES  VIOLATED  75 SECURITY CODE INVALID  76 CARD BLOCKED   85 REJECTED BY CARD  ISSUER  91 CREDITCARD ISSUER  TEMPORARILY NOT  REACHABLE  97 SECURITY BREACH  3 INVALID ACCEPTOR  12 INVALID TRANSACTION  14 INVALID ACCOUNT  19 REPEAT OF LAST  TRANSACTION  20 ACQUIRER ERROR  21 REVERSAL NOT  PROCESSED. MISSING  AUTHORISATION  24 UPDATE OF FILE  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  REFUSED  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  Submitting Transactions in the Direct Model   ◊   Page 32  .

  AUTHORISATION EXPIRED  92 CREDITCARD TYPE NOT  PROCESSED BY ACQUIRER  94 DUPLICATE REQUEST  ERROR    ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  Submitting Transactions in the Direct Model   ◊   Page 33  .Appendices IMPOSSIBLE  25 REFERENCE NUMBER  CANNOT BE FOUND  26 DUPLICATE REFERENCE  NUMBER  27 ERROR IN REFERENCE  NUMBER FIELD  30 FORMAT ERROR  31 UNKNOWN ACQUIRER  ACCOUNT CODE  40 REQUESTED FUNCTION  NOT SUPPORTED  58 TRANSACTION NOT  PERMITTED  64 AMOUNT HIGHER THAN  PREVIOUS TRANSACTION  AMOUNT  68 TRANSACTION TIMED  OUT  80 AMOUNT NO LONGER  AVAILABLE.

 it is an upper‐case  two‐letter ʹISO 3166ʹ standard country code. as shown in the following example:  ..iso.html  ISO 3166 Two-Letter Country Codes   Country name <countryCode> or country parameter value AFGHANISTAN  AF  ÅLAND  ISLANDS  ALBANIA  AX  AL  ALGERIA  DZ  AMERICAN  SAMOA  ANDORRA  AS  AD  ANGOLA  AO  ANGUILLA  AI  ANTARCTICA  AQ  ANTIGUA AND  BARBUDA  AG  Submitting Transactions in the Direct Model   ◊   Page 34  .. <address> <countryCode>GB</countryCode> </address> ISO source reference:  http://www.org/iso/en/prods-services/iso3166ma/02iso-3166code-lists/list-en1.Appendices ISO Country Codes The countryCode element is used in XML orders/communications.

Appendices ARGENTINA  AR  ARMENIA  AM  ARUBA  AW  AUSTRALIA  AU  AUSTRIA  AT  AZERBAIJAN  AZ  BAHAMAS  BS  BAHRAIN  BH  BANGLADESH  BD  BARBADOS  BB  BELARUS  BY  BELGIUM  BE  BELIZE  BZ  BENIN  BJ  BERMUDA  BM  BHUTAN  BT  BOLIVIA  BO  BOSNIA AND  HERZEGOVINA  BOTSWANA  BA  BW  Submitting Transactions in the Direct Model   ◊   Page 35  .

Appendices BOUVET ISLAND  BV  BRAZIL  BR  BRITISH INDIAN  OCEAN  TERRITORY  BRUNEI  DARUSSALAM  BULGARIA  IO  BN  BG  BURKINA FASO  BF  BURUNDI  BI  CAMBODIA  KH  CAMEROON  CM  CANADA  CA  CAPE VERDE  CV  CAYMAN  ISLANDS  CENTRAL  AFRICAN  REPUBLIC  CHAD  KY  CF  TD  CHILE  CL  CHINA  CN  CHRISTMAS  ISLAND  CX  Submitting Transactions in the Direct Model   ◊   Page 36  .

Appendices COCOS  (KEELING)  ISLANDS  COLOMBIA  CC  CO  COMOROS  KM  CONGO  CG  CONGO. THE  DEMOCRATIC  REPUBLIC OF  THE  COOK ISLANDS  CD  CK  COSTA RICA  CR  CÔTE DʹIVOIRE  CI  CROATIA  HR  CUBA  CU  CYPRUS  CY  CZECH  REPUBLIC  DENMARK  CZ  DK  DJIBOUTI  DJ  DOMINICA  DM  DOMINICAN  REPUBLIC  ECUADOR  DO  EC  Submitting Transactions in the Direct Model   ◊   Page 37  .

Appendices EGYPT  EG  EL SALVADOR  SV  EQUATORIAL  GUINEA  ERITREA  GQ  ER  ESTONIA  EE  ETHIOPIA  ET  FALKLAND  ISLANDS  (MALVINAS)  FAROE ISLANDS  FK  FO  FIJI  FJ  FINLAND  FI  FRANCE  FR  FRENCH  GUIANA  FRENCH  POLYNESIA  FRENCH  SOUTHERN  TERRITORIES  GABON  GF  PF  TF  GA  GAMBIA  GM  GEORGIA  GE  Submitting Transactions in the Direct Model   ◊   Page 38  .

Appendices GERMANY  DE  GHANA  GH  GIBRALTAR  GI  GREECE  GR  GREENLAND  GL  GRENADA  GD  GUADELOUPE  GP  GUAM  GU  GUATEMALA  GT  GUERNSEY  GG  GUINEA  GN  GUINEA‐BISSAU  GW  GUYANA  GY  HAITI  HT  HEARD ISLAND  AND  MCDONALD  ISLANDS  HOLY SEE  (VATICAN CITY  STATE)  HONDURAS  HM  VA  HN  Submitting Transactions in the Direct Model   ◊   Page 39  .

  DEMOCRATIC  PEOPLEʹS  REPUBLIC OF  KP  Submitting Transactions in the Direct Model   ◊   Page 40  .Appendices HONG KONG  HK  HUNGARY  HU  ICELAND  IS  INDIA  IN  INDONESIA  ID  IRAN. ISLAMIC  REPUBLIC OF  IRAQ  IR  IQ  IRELAND  IE  ISRAEL  IL  ITALY  IT  JAMAICA  JM  JAPAN  JP  JERSEY  JE  JORDAN  JO  KAZAKHSTAN  KZ  KENYA  KE  KIRIBATI  KI  KOREA.

Appendices KOREA.  THE FORMER  YUGOSLAV  REPUBLIC OF  MADAGASCAR  MK  MG  MALAWI  MW  MALAYSIA  MY  Submitting Transactions in the Direct Model   ◊   Page 41  .  REPUBLIC OF  KUWAIT  KR  KW  KYRGYZSTAN  KG  LAO PEOPLEʹS  DEMOCRATIC  REPUBLIC  LATVIA  LA  LV  LEBANON  LB  LESOTHO  LS  LIBERIA  LR  LIBYAN ARAB  JAMAHIRIYA  LIECHTENSTEIN  LY  LI  LITHUANIA  LT  LUXEMBOURG  LU  MACAO  MO  MACEDONIA.

Appendices MALDIVES  MV  MALI  ML  MALTA  MT  MARSHALL  ISLANDS  MARTINIQUE  MH  MQ  MAURITANIA  MR  MAURITIUS  MU  MAYOTTE  YT  MEXICO  MX  MICRONESIA.  FEDERATED  STATES OF  MOLDOVA.  REPUBLIC OF  MONACO  FM  MD  MC  MONGOLIA  MN  MONTSERRAT  MS  MOROCCO  MA  MOZAMBIQUE  MZ  MYANMAR  MM  NAMIBIA  NA  Submitting Transactions in the Direct Model   ◊   Page 42  .

Appendices NAURU  NR  NEPAL  NP  NETHERLANDS  NL  NETHERLANDS  ANTILLES  NEW  CALEDONIA  NEW ZEALAND  AN  NC  NZ  NICARAGUA  NI  NIGER  NE  NIGERIA  NG  NIUE  NU  NORFOLK  ISLAND  NORTHERN  MARIANA  ISLANDS  NORWAY  NF  MP  NO  OMAN  OM  PAKISTAN  PK  PALAU  PW  PALESTINIAN  TERRITORY.  OCCUPIED  PS  Submitting Transactions in the Direct Model   ◊   Page 43  .

Appendices PANAMA  PA  PAPUA NEW  GUINEA  PARAGUAY  PG  PY  PERU  PE  PHILIPPINES  PH  PITCAIRN  PN  POLAND  PL  PORTUGAL  PT  PUERTO RICO  PR  QATAR  QA  RÉUNION  RE  ROMANIA  RO  RUSSIAN  FEDERATION  RWANDA  RU  RW  SAINT  BARTHELEMY  SAINT HELENA  BL  SH  SAINT KITTS  AND NEVIS  SAINT LUCIA  KN  LC  Submitting Transactions in the Direct Model   ◊   Page 44  .

Appendices SAINT PIERRE  AND MIQUELON  SAINT VINCENT  AND THE  GRENADINES  SAMOA  PM  VC  WS  SAN MARINO  SM  SAO TOME AND  PRINCIPE  SAUDI ARABIA  ST  SA  SENEGAL  SN  SERBIA   CS  SEYCHELLES  SC  SIERRA LEONE  SL  SINGAPORE  SG  SLOVAKIA  SK  SLOVENIA  SI  SOLOMON  ISLANDS  SOMALIA  SB  SO  SOUTH AFRICA  ZA  SOUTH  GEORGIA AND  THE SOUTH  SANDWICH  GS  Submitting Transactions in the Direct Model   ◊   Page 45  .

Appendices ISLANDS  SPAIN  ES  SRI LANKA  LK  SUDAN  SD  SURINAME  SR  SVALBARD AND  JAN MAYEN  SWAZILAND  SJ  SZ  SWEDEN  SE  SWITZERLAND  CH  SYRIAN ARAB  REPUBLIC  TAIWAN.  UNITED  REPUBLIC OF  THAILAND  TZ  TH  TIMOR‐LESTE  TL  TOGO  TG  TOKELAU  TK  Submitting Transactions in the Direct Model   ◊   Page 46  .  PROVINCE OF  CHINA  TAJIKISTAN  SY  TW  TJ  TANZANIA.

Appendices TONGA  TO  TRINIDAD AND  TOBAGO  TUNISIA  TT  TN  TURKEY  TR  TURKMENISTAN  TM  TURKS AND  CAICOS  ISLANDS  TUVALU  TC  TV  UGANDA  UG  UKRAINE  UA  UNITED ARAB  EMIRATES  UNITED  KINGDOM  UNITED STATES  AE  GB  US  UNITED STATES  MINOR  OUTLYING  ISLANDS  URUGUAY  UM  UY  UZBEKISTAN  UZ  VANUATU  VU  Submitting Transactions in the Direct Model   ◊   Page 47  .

S.  WALLIS AND  FUTUNA  WESTERN  SAHARA  YEMEN  VG  VI  WF  EH  YE  ZAMBIA  ZM  ZIMBABWE    ZW  Submitting Transactions in the Direct Model   ◊   Page 48  .Appendices Vatican City State  ‐ refer to HOLY  SEE   VENEZUELA  VA  VE  VIET NAM  VN  VIRGIN  ISLANDS.  BRITISH  VIRGIN  ISLANDS. U.

  Only orders containing a valid CVC/CVV code fragment will be checked. as displayed in  the example below. CVC/CVV is a 3‐ or 4‐digit value printed on the card (for example. and enables the security code entered by  the shopper to be compared against the card issuerʹs records during the payment process. Shopper</cardHolderName> <cvc>123</cvc> <cardAddress> . on a signature  strip).Appendices CVC/CVV Checks and Responses You can carry out a Security Code Verification (CVC/CVV) check on an individual direct  order. but not encoded on the magnetic stripe... Testing The following CVC/CVV scenarios can be tested using the codes listed below.  CVC/CVV code Left blank   simulated situation NOT SUPPLIED  BY SHOPPER  NOT SENT TO  ACQUIRER  NO RESPONSE  FROM  ACQUIRER  NOT CHECKED  BY ACQUIRER  FAILED  APPROVED  numeric response 1  111  2  222  3  333  4  444  555      5  6  Submitting Transactions in the Direct Model   ◊   Page 49  .  <cardHolderName>J. An order without the CVC code fragment will not be checked.

  Alternatively.   Captures and refunds can be simulated through the Merchant Administration Interface.   Test Card Numbers The following card numbers can be used when you make test transactions in Test  environments only ‐ do not use them in live.  Use the ʺCaptureʺ or ʺRefundʺ button in the Payment and Order Details  page.  For test purposes we have provided a set of test credit and debit card numbers. these are  listed below in the Test Card Numbers section.Appendices Testing Transactions A number of different cases can be tested by entering the following values as the  card/accountholder name (<cardHolderName>) in the order:  • • • • REFUSED – will simulate a refused payment  REFERRED ‐ will simulate a refusal with the refusal reason ‘referredʹ  FRAUD ‐ will simulate a refusal with the refusal reason ‘fraud suspicionʹ  ERROR ‐ will simulate a payment that ends in error. Production environments:  card type Mastercard  Visa Delta ‐  UK  Visa Delta ‐  Non UK  Visa  Visa  American  Express  Diners  JCB  Visa  Electron  (UK only)  card number 5100080000000000  4406080400000000  number length 16  16  issue no length 0  0  4462030000000000  16  0  4911830000000  4917610000000000  370000200000000  13  16  15  0  0  0  36700102000000  3528000700000000  4917300800000000  14  16  16  0  0  0  Submitting Transactions in the Direct Model   ◊   Page 50  .  All other card/accountholder names will simulate an authorised payment. you can send an XML capture or refund order modification to the  Test environment.

  bank code 20030000  43050001  30070024  account number 92441196  122108525  5929120  Submitting Transactions in the Direct Model   ◊   Page 51  .Appendices Solo  Solo  Discover  Card  Laser  Maestro  Visa  Purchasing  6334580500000000  633473060000000000  6011000400000000  16  18  16  0  1  0  630495060000000000  6759649826438453  4484070000000000  18  16  16  0  0  0    Note that Visa Purchasing transactions are treated as Visa credit  card transactions.  German ELV To test German ELV payments in the Test environment a correctly formatted account  number (Kontonummer) and valid bank code (Bankleitzahl) should be used. for example:  Account number: 12345678  Bank code: 10000000  Bank name: Bundesbank  Bank residence: Berlin  card type ELV  ELV  ELV    Please note that ELV must be activated in the Production environment for merchants who  would like to test ELV transactions.

worldpay.3"> <reply> <error code="4"><![CDATA[IP check failed.com/paymentService_v1.0"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd. 6.  Error Code 2 <?xml version="1. occurs when XML is valid but content of XML is not  Payment details in the order element are incorrect  For full details of our DTD. 4.com/paymentService_v1.com/paymentService_v1. invalid XML  Invalid number of transactions in batch  Security error  Invalid request  Invalid content. 5.worldpay.3" merchantCode="MYCO"> <reply> <error code="2"><![CDATA[Invalid bankAccount details : Invalid payment details : Account and bankcode combination is incorrect]]></error> </reply> </paymentService> Error Code 4 <?xml version="1.com/paymentService_v1. refer to: http://dtd. 7. 3.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd. Internal error.worldpay.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.dtd"> <paymentService merchantCode="MYCO" version="1. Access denied.dtd"> <paymentService version="1.dtd  Examples The following are some examples for these error codes.dtd"> <paymentService version="1.]]></error> </reply> </paymentService> Error Code 5 <?xml version="1.3" merchantCode="MYCO"> <reply> <orderStatus orderCode="12234"> <error code="5"><![CDATA[Cannot book payment to CANCELLED if paymentstatus is not AUTHORISED but : REFUSED]]></error> </orderStatus> Submitting Transactions in the Direct Model   ◊   Page 52  .worldpay. a general error  Parse error.Appendices XML Error Codes The list of XML error codes is as follows:  1. 2.

4" merchantCode="MYCO"> <reply> <orderStatus orderCode="11223"> <error code="7"><![CDATA[Gateway error]]></error> </orderStatus> </reply> </paymentService>   Submitting Transactions in the Direct Model   ◊   Page 53  .0"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN""http://dtd.dtd"> <paymentService version="1.3" merchantCode="MYCO"> <reply> <orderStatus orderCode="1112"> <error code="7"><![CDATA[Invalid payment details : Expiry date = 012002]]></error> </orderStatus> </reply> </paymentService>   <?xml version="1.dtd"> <paymentService version="1.com/paymentService_v1.com/paymentService_v1.Appendices </reply> </paymentService>   <?xml version="1.com/paymentService_v1.worldpay.4"> <reply> <orderStatus orderCode="11223"> <error code="5"><![CDATA[Requested capture amount (EUR 125.com/paymentService_v1.worldpay.dtd"><paymentService version="1.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN""http://dtd.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.50) exceeds the authorised balance for this payment (EUR 115.worldpay.50)]]></error> </orderStatus> </reply> </paymentService> Error Code 7 <?xml version="1.dtd"><paymentService merchantCode="MYCO" version="1.worldpay.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.3" merchantCode="MYCO"> <reply> <error code="5"><![CDATA[Duplicate Order]]></error> </reply> </paymentService>   <?xml version="1.

Sign up to vote on this title
UsefulNot useful