P. 1
3dsecure

3dsecure

|Views: 533|Likes:
Published by cursaru_alexandru

More info:

Published by: cursaru_alexandru on May 19, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/23/2013

pdf

text

original

Sections

  • About this Guide
  • Copyright
  • Introduction
  • What is XML Direct?
  • Before You Start
  • Overview of Setting a Connection
  • Error Messages, Invalid XML
  • Structure of an XML Direct Order
  • XML and Document Type Declaration
  • Order Content
  • <orderContent>
  • Payment Details and Session Information
  • Shopper Information
  • XML Direct Order Example
  • Response from the Payment Service
  • Reply to an XML Direct Order
  • Informing the Shopper
  • Posting an XML Order
  • Setting-up the Connection
  • Testing the Connection
  • Testing 3-D Secure Orders
  • Testing Transactions
  • Submitting a 3-D Secure Order
  • The Process Flow
  • XML Messages and HTML Redirect
  • the initial order message (arrow 2 in diagram)
  • Redirect the Shopper to Issuer (arrow 4)
  • Second Order Message (arrow 6)
  • Second Reply Message (arrow 9)
  • Appendices
  • Payment Method Codes
  • ISO Currency Codes
  • Acquirer Response Codes
  • ISO Country Codes
  • CVC/CVV Checks and Responses
  • XML Error Codes

Submitting Transactions in the XML Direct Model with 3 D Secure Guide

Version 2 – March 2009

Submitting Transactions in the XML Direct Model with 3D Secure Guide

Table Of Contents

About this Guide.......................................................................................................... 4
Copyright................................................................................................................................ 4

Introduction ................................................................................................................. 5
What is XML Direct? .............................................................................................................. 5

Before You Start.......................................................................................................... 7
Overview of Setting a Connection.......................................................................................... 7 Error Messages, Invalid XML................................................................................................. 8

Structure of an XML Direct Order.............................................................................. 11
Introduction .......................................................................................................................... 11 XML and Document Type Declaration................................................................................. 11 Order Content ...................................................................................................................... 11 Payment Details and Session Information........................................................................... 12 Shopper Information ............................................................................................................ 13 XML Direct Order Example .................................................................................................. 13

Response from the Payment Service........................................................................ 18
Introduction .......................................................................................................................... 18 Reply to an XML Direct Order.............................................................................................. 18 Informing the Shopper ......................................................................................................... 19

Posting an XML Order............................................................................................... 20
Introduction .......................................................................................................................... 20 Setting-up the Connection ................................................................................................... 20

Testing the Connection ............................................................................................. 21
Testing 3-D Secure Orders .................................................................................................. 21 Testing Transactions............................................................................................................ 21

Submitting a 3-D Secure Order................................................................................. 24
Introduction .......................................................................................................................... 24 The Process Flow ................................................................................................................ 24

3D Secure Page 2 of 56

Submitting Transactions in the XML Direct Model with 3D Secure Guide
XML Messages and HTML Redirect.................................................................................... 25

Appendices ............................................................................................................... 32
Payment Method Codes ...................................................................................................... 32 ISO Currency Codes............................................................................................................ 35 Acquirer Response Codes ................................................................................................... 37 ISO Country Codes.............................................................................................................. 40 CVC/CVV Checks and Responses ...................................................................................... 53 XML Error Codes ................................................................................................................. 54

3D Secure Page 3 of 56

Submitting Transactions in the XML Direct Model with 3D Secure Guide

About this Guide
This guide describes the specifications of XML orders sent to the RBS 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 RBS 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
RBS WorldPay © The Royal Bank of Scotland plc 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 Limited. WorldPay Limited, 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 Limited. WorldPay Limited has made every effort to ensure the accuracy of this material.

3D Secure Page 4 of 56

Submitting Transactions in the XML Direct Model with 3D Secure Guide

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 RBS WorldPay, for processing. The XML Direct model only allows for using a select number of online payment methods, where no consumer interaction is involved.In view of the cost involved in establishing appropriate security measures this model only applies for merchants with established high transaction volumes.

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 RBS 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 XML 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.

3D Secure Page 5 of 56

refer to the Cardholder Authentication guide 3D Secure Page 6 of 56 . nor do they cover all card types. For further details about authentication. This means that authentication programmes do not cover fax. Authentication should strengthen your existing anti-fraud strategy and help protect your business. but bear in mind that coverage of authentication programmes is currently limited to Internet transactions.Submitting Transactions in the XML Direct Model with 3D Secure Guide 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. mail. or phone orders.

can only be modified via our online administration tool. For example. testing the connection: you are able to test the connection using the Test environment before using the Production environment. remember to use a valid login and password. You can login to both via: www. update settings that control aspects of how the service works. Please note the following before proceeding. Order creation can be achieved in a number of different ways depending on the scripting language that you are using. or how to establish the secure connection account settings: before sending test orders to the Payment Service check and. 3D Secure Page 7 of 56 . if necessary. from order data captured from your shoppers by your systems. setting up a successful connection between your system and the RBS WorldPay payment system. This guide provides an overview only. setting a delay between authorisation and capture. RBS WorldPay cannot advise on how to specifically create an XML order using ASP or PHP. Your login name is the relevant merchant code (to look up the merchant code(s) allocated to your organisation.rbsworldpay. involves the following major steps: order creation: automating the creation of an XML document that conforms with the rules specified in the RBS WorldPay Document Type Definition (DTD). This topic is covered in this guide. Note to remember: you have a separate Merchant Interface for your Production environment and for your Test environment. order submission: setting up an HTTP(S) connection between your system and ours and automating the sending of XML orders over that connection. the Merchant Interface. Account Settings A number of the settings that affect the way the service works.com/admin Connect Using Login Name and XML Password When setting up the HTTP(s) connection over which you will send XML orders. login to the Merchant Interface and refer to the status box in the left-hand side of the page). This topic is covered in detail in this guide.Submitting Transactions in the XML Direct Model with 3D Secure Guide Before You Start Overview of Setting a Connection From a technical / IT viewpoint.

please ensure that you are using an industry standard Parser that parses the message against the RBS WorldPay Document Type Definition (DTD) (refer to Reference the DTD below). 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. XML messages must adhere to the following rules in order to be accepted. For examples of XML errors messages our system may return. 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. please refer to the appendix XML Error Codes.com/paymentService_v1. The DTD is specified in the header of the XML message and will look as follows: <?xml version="1. For the XML to be well-formed.dtd"> 3D Secure Page 8 of 56 .0"? encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.org for further details on XML and parsers.Submitting Transactions in the XML Direct Model with 3D Secure Guide Error Messages. Use Valid Syntax All XML messages sent to the RBS WorldPay system must be well-formed and valid. Please refer to http://www. XML messages should be parsed prior to sending them to the RBS WorldPay Payment Service and upon receipt. so it can be automatically compared with it in order to check if all the references used are correct.rbsworldpay. it must adhere to a number of rules. When parsing.xml. Do not rely on a self-built parser. Most of the incorrect XML issues will be resolved by using an industry standard parser. This ensures that the messages sent are valid and messages received are correctly interpreted. Reference the DTD A valid XML message must always include a reference to the DTD.

No other characters are allowed. If you need to use these characters within a PCDATA block you should specify them as follows: & = &amp. attribute and entity in the XML that you send. > = &gt.]. for the description element which is declared to contain PCDATA <!ELEMENT description (#PCDATA )> a valid example would be: 3D Secure Page 9 of 56 . and [:]. the values of these attributes must be legal XML name tokens.Submitting Transactions in the XML Direct Model with 3D Secure Guide Use Declared Elements Only Every element. If an attribute is declared to contain a name token or list of name tokens. [<].rbsworldpay. For example. < = &lt. [-]. The DTD can be found at: http://dtd.com/paymentService_v1. " = &quot.dtd Name Tokens An XML name token consists of alphanumeric and/or ideographic characters and the punctuation marks [_]. [>] and ["]. An XML name token may not contain white spaces. 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: [&]. must be declared in the DTD (Document Type Definition). XML elements can be declared to contain: name tokens (NMTOKEN) parsed character data (PCDATA) character data (CDATA) or constants. [.

For example: <[CDATA[This text has not been parsed & still can be used]]> 3D Secure Page 10 of 56 . A CDATA block must be enclosed between the start tag <[CDATA[ and the end tag ]]>.Submitting Transactions in the XML Direct Model with 3D Secure Guide <description>Your Holland &amp. 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: ]]>.

The order content must be less than 10 kilobytes and should always be included in a CDATA section to avoid parsing problems.Submitting Transactions in the XML Direct Model with 3D Secure Guide Structure of an XML Direct Order Introduction Orders submitted to the RBS WorldPay system are required to be valid XML files as specified in this guide and in the Document Type Definition (DTD).dtd"> Order Content The third child element of the order element is orderContent. available at: dtd.com/ XML files are valid if they are well-formed. Note for details of submitting a 3-D Secure payment request.rbsworldpay. that is. please refer to the chapter Submitting a 3D-Secure Order.wp3. XML and Document Type Declaration To process an XML Direct order the submission must begin with an XML declaration and a document type declaration. You can deliver the order content in HTML format.wp3. they have a correct XML syntax. <orderContent> <![CDATA[content here]]> </orderContent> The order content may contain: order code product(s) and/or service(s) ordered item price total amount 3D Secure Page 11 of 56 .com/paymentService_v1. 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. containing the root element paymentService and the reference to our public DTD: <?xml version="1. and conform to a Document Type Definition.0"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd.rbsworldpay.

Submitting Transactions in the XML Direct Model with 3D Secure Guide shopper billing address shopper shipping address contact details merchant the fact that RBS WorldPay processes the payment the fact that the name RBS WorldPay may appear on the shopper's bank or credit card statements.> <postalCode>CB94BQ</postalCode> <countryCode>GB</countryCode> <telephoneNumber>0123456789</telephoneNumber> 3D Secure Page 12 of 56 . RBS WorldPay uses the payment details and session information for risk assessment. where VISA-SSL is the payment method code. Shopper</cardHolderName> <cvc>123</cvc> <cardAddress> <address> <firstName>John</firstName> <lastName>Shopper</lastName> <street>47A Queensbridge Rd</street> <!-. An example of the paymentDetails for a VISA payment. Each payment method has its own set of sub-elements and attributes. 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. is: <paymentDetails> <VISA-SSL> <cardNumber>4444333322221111</cardNumber> <expiryDate> <date month="09" year="2009"/> </expiryDate> <cardHolderName>J.We recommend that you include the whole address in this field with the exception of postalCode and CountryCode. 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. The payment method codes are listed in the appendix Payment Method Codes. In addition to the regular payment details you need to provide information about the shopper browser session in the paymentDetails child element session. They are a mandatory element in a 3-D Secure transaction.

For details please refer to the appendix CVC/CVV Checks And Responses. 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 payment method code VISA-SSL should be used for both Visa credit and Visa debit card payments.123. The order is for 20 tulip bulbs at EUR 1 each and has an order code: T0211010. Its shopperEmailAddress element is used by RBS WorldPay to identify possible fraudulent transactions. This example shows paymentDetails for SOLO_GB-SSL: <paymentDetails> <SOLO_GB-SSL> <cardNumber>6333333333333333336</cardNumber> <expiryDate><date month="05" year="2009"></expiryDate> <cardHolderName>J. Please note that the issue number can be up to three digits. Note that the cvc element contains the Card Verification Code.123. The non-numeric parts are ignored. including possible zeros in front. The merchant 3D Secure Page 13 of 56 . Also note that the numeric parts (if there are any) of the street element are used in the AVS check. 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.Submitting Transactions in the XML Direct Model with 3D Secure Guide </address> </cardAddress> </VISA-SSL> <session shopperIPAddress="123.int</shopperEmail Address> </shopper> XML Direct Order Example An example of a complete XML order for the Direct model is shown below. or to send an email to the shopper when the payment is authorised or refused. <shopper> <shopperEmailAddress>jshopper@myprovider. depending on the issuer policy.

Shopper and the used payment method is VISA. Shopper<br>47A Queensbridge Road<br>Cambridge<br>CB9 4BQ<br>United Kingdom</td></tr> <tr><td colspan="3">&nbsp.4" merchantCode="MYMERCHANT"> <submit> <order orderCode="T0211010"> <description>20 Tulip Bulbs from MYMERCHANT Webshops</description> <amount value="2600" currencyCode="EUR" 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 Tulip Bulbs</td><td align="right">1. J.00</td></tr> <tr><td colspan="2">VAT: 15%</td><td align="right">3</td></tr> <tr><td colspan="2">Shipping and Handling:</td><td align="right">3</td></tr> <tr><td colspan="2" bgcolor="#c0c0c0">Total cost:</td><td bgcolor="#c0c0c0" align="right">EUR 26.J.wp3. the shopper is Mr.</td></tr> <tr><td bgcolor="#ffff00" colspan="3">Your billing address:</td></tr> <tr><td colspan="3">Mr.rbsworldpay.00</td></tr> <tr><td colspan="2">Subtotal:</td><td align="right">10.</td></tr> <tr><td bgcolor="#ffff00" colspan="3">Our contact information:</td></tr> <tr><td colspan="3">MYMERCHANT Webshops International<br>461 3D Secure Page 14 of 56 . J. Please note that a browser-view picture of the order is shown below the XML code. Shopper<br> 47A Queensbridge Road<br>Cambridge<br>CB9 4BQ<br>UK</td></tr> <tr><td colspan="3">&nbsp. <?xml version="1.0"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay/DTD RBS WorldPay PaymentService v1//EN" "http://dtd.</td></tr> <tr><td bgcolor="#ffff00" colspan="3">Your shipping address:</td></tr> <tr><td colspan="3">Mr.com/paymentService_v1.Submitting Transactions in the XML Direct Model with 3D Secure Guide is the MYMERCHANT Webshop with merchant code MYMERCHANT.dtd"> <paymentService version="1.00</td></tr> <tr><td colspan="3">&nbsp.

int<br>1234 567890</td></tr> <tr><td colspan="3">&nbsp. Shopper</cardHolderName> <cvc>123</cvc> <cardAddress> <address> <firstName>John</firstName> <lastName>Shopper</lastName> <street>47A Queensbridge Rd</street> <!-.Submitting Transactions in the XML Direct Model with 3D Secure Guide Merchant Street<br>1256 Merchant Town<br>Netherlands <br><br>mymerchant@webshops.com</td></tr> </table></center> ]]> </orderContent> <paymentDetails> <VISA-SSL> <cardNumber>4444333322221111</cardNumber> <expiryDate> <date month="09" year="2007"/> </expiryDate> <cardHolderName>J.int</shopperEmailAd dress> </shopper> <shippingAddress> <address> <firstName>John</firstName> <lastName>Shopper</lastName> 3D Secure Page 15 of 56 .--> <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.</td></tr> <tr><td bgcolor="#c0c0c0" colspan="3">Billing notice:</td></tr> <tr><td colspan="3">Your payment will be handled by RBS WorldPay Payments Services<br>This name may appear on your bank statement<br>http://www.rbsworldpay.123" id="0215ui8ib1" /> </paymentDetails> <shopper> <shopperEmailAddress>jshopper@myprovider.123.123.

Please note that if no house or apartment number is included then a house name can be included using the <houseName> element.--> <postalCode>CB94BQ</postalCode> <city>Cambridge</city> <countryCode>GB</countryCode> <telephoneNumber>01234567890</telephoneNumber> </address> </shippingAddress> </order> </submit> </paymentService> The CDATA section in the orderContent element contains a complete invoice in HTML. The image below shows what this order content looks like when viewed with a web browser. 3D Secure Page 16 of 56 .Submitting Transactions in the XML Direct Model with 3D Secure Guide <street>47A Queensbridge Rd</street> <!-.

3D Secure Page 17 of 56 .Submitting Transactions in the XML Direct Model with 3D Secure Guide Figure 1: Example HTML order content as viewed with a browser.

The topics covered in this chapter are listed below.com/paymentService_v1. In the XML Direct model. Reply to an XML Direct Order Informing the Shopper Note for details of replies in response to a 3-D Secure payment request. shown earlier. please refer to the chapter Submitting a 3-D Secure Order.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> <riskScore value="0"/> </payment> 3D Secure Page 18 of 56 . <<?xml version="1. For various platforms different XML parsers exist.rbsworldPay.dtd"> <paymentService merchantCode="MYMERCHANT" version="1. The result of the authorisation request is reported to RBS WorldPay online as either AUTHORISED or REFUSED. When parsing RBS WorldPay reply it is important that you use an industry standard XML parser.wp3. Do not depend on a homemade one.0"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd. Reply to an XML Direct Order The example below shows a possible XML reply from RBS WorldPay for a successful authorisation of the example order.org.xml.Submitting Transactions in the XML Direct Model with 3D Secure Guide 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. which may not be able to correctly interpret the messages received from RBS WorldPay. RBS WorldPay sends an XML response to your system that contains the payment status of the order. Please refer to http://www.

Your system has to determine whether or not a payment was successful by interpreting this status information supplied by RBS WorldPay. The balance element reports on the balance in the IN_PROCESS_AUTHORISED account. for instance. A CVC result description is reported through the CVCResultCode element.Submitting Transactions in the XML Direct Model with 3D Secure Guide </orderStatus> </reply> </paymentService> In the reply. you can have your account configured so that RBS WorldPay sends an email to the shopper after a successful authorisation or a refusal. Always refer to the RBS WorldPay DTD for an up-to-date list of child elements and attributes of the reply element. Alternatively. To inform the shopper of the payment result you can. For instance. via HTTP(S) or email order notifications or via the Merchant Interface. send an email. the payment element holds the relevant payment details and status information. 3D Secure Page 19 of 56 . the Payment Service can report the status of individual payments to your system in a number of ways. its exponent and the debitCreditIndicator that indicates the amount is positive. including the currency. To use the latter method. you can change the settings and the text of the actual emails through the ’Edit Channels' functionality in the Merchant Interface. Its child elements paymentMethod and amount contain the payment method used and the amount. For credit card payments the first and last four digits of the card number are returned in the cardNumber element. Informing the Shopper In addition to the reply message. The payment status is specified by the lastEvent element.

wp3. Setting-up the Connection Once you have set up the connection to the Payment Service using a valid login and password.jsp 3D Secure Page 20 of 56 .com/jsp/merchant/xml/paymentService.Submitting Transactions in the XML Direct Model with 3D Secure Guide Posting an XML Order Introduction To submit an XML order you have to set up an HTTP(S) connection to the Payment Service.rbsworldpay.rbsworldpay. while specifying it incorrectly will.wp3. How you create a connection with the RBS WorldPay server depends on the specifications of your platform. your system has to post the XML order. The URLs to post orders to are: Test environment: https://securetest.com/jsp/merchant/xml/paymentService. Not specifying the content length will not create errors. Make sure the HTTP content type is “text/xml”! It is important to check that &rsquocontent length' is specified correctly.jsp Production/Live environment: https://secure.

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. in the Test Environment you should use considerably shorter lengths. Please note that your RBS WorldPay account must first be enabled for 3-D Secure. However. This service can be used to submit dummy XML orders. such as those shown above. 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 Test environment will act as if it is a normal e-commerce transaction (that is. we provide a test payment service.7KB. Using the dummy issuer site.Submitting Transactions in the XML Direct Model with 3D Secure Guide Testing the Connection Testing 3-D Secure Orders In order for merchants to test their 3-D Secure implementation. Testing Transactions 3D Secure Page 21 of 56 . Note that in the Production environment. which can only be done by RBS WorldPay support We also provide a dummy card issuer site so that this part of the process can also be tested. The value of the cardHolderName element in the XML order message can be used to manipulate the test. otherwise a parse error will be generated. no lookup with the Directory). You can use the value of the paResponse element to manipulate the outcome of the payer authentication. the Directory would respond with not-enrolled) with any other value for cardHolderName. There are these possibilities: a value of IDENTIFIED means the shopper's identity is successfully verified a value of IDENTIFIED with No XID also means the shopper’s identity is successfully verified a value of NOT_IDENTIFIED means the shopper's identification could not be verified a value of NOT_IDENTIFIED with No XID also means the shopper's identification could not be verified a value of UNKNOWN_IDENTITY means that the authentication failed and any other value such as ERROR means the verification process itself failed. the length of the paResponse element can be up to 4. these three options can be selected with a drop-down list.

Submitting Transactions in the XML Direct Model with 3D Secure Guide A number of different cases can be tested by entering the following values as the card/accountholder name (<cardHolderName>) in the order: REFUSED &. All other card/accountholder names will simulate an authorised payment.will simulate a refusal with the refusal reason &rsquoreferred' FRAUD . Use the "Capture" or "Refund" button in the Payment and Order Details page. will simulate a refused payment REFERRED .will simulate a refusal with the refusal reason &rsquofraud suspicion' ERROR . you can send an XML capture or refund order modification to the Test environment. these are listed below in the Test Card Numbers section. Length 4484070000000000 16 0 5100080000000000 16 0 4406080400000000 16 0 4462030000000000 16 0 4911830000000 4917610000000000 13 16 0 0 370000200000000 15 0 36700102000000 14 0 3D Secure Page 22 of 56 .do not use them in live.will simulate a payment that ends in error. Test Card Numbers The following card numbers can be used when you make test transactions in Test environments only . Production environments: Card Card Type Card Number Lengt h Visa Purchasing Mastercard Visa Delta UK Visa Delta Non-UK Visa Visa American Express Diners Issue No. For test purposes we have provided a set of test credit and debit card numbers. Alternatively. Captures and refunds can be simulated through the Merchant Interface.

Submitting Transactions in the XML Direct Model with 3D Secure Guide JCB Visa Electron Solo 3528000700000000 16 0 4917300800000000 16 0 6334580500000000 63347306000000000 0 16 0 Solo 18 1 Discover card 6011000400000000 16 0 Laser 63049506000000000 0 57000000000000000 00 18 0 Maestro 19 1 Note that Visa Purchasing transactions are treated as Visa credit card transactions. 3D Secure Page 23 of 56 . for example: Account number: 12345678 Bank code: 10000000 Bank name: Bundesbank Bank residence: Berlin card type bank code account number 92441196 122108525 5929120 ELV ELV ELV 20030000 43050001 30070024 Please note that ELV must be activated in the Production environment for merchants who would like to test ELV 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.

Refer to Initial Order Message (arrow 2). 3. 3D Secure Page 24 of 56 . refer to Initial Order Reply Message (arrow 3). we have no control over its appearance or functionality. This page is provided and hosted by the shopper's Card Issuer. The Process Flow The figure below describes the flow of messages between the different entities involved. The merchant's system redirects the shopper to the issuer site for authentication using information in the reply message. RBS WorldPay verifies that the cardholder is participating in the 3-D Secure programme and a reply message is sent back to the merchant's system to request payer authentication.Submitting Transactions in the XML Direct Model with 3D Secure Guide Submitting a 3-D Secure Order Introduction This chapter describes how you should implement 3-D Secure Authentication using the XML Direct model. Figure: The Process Flow 1. 4. As this page is hosted by the shopper’s card issuing bank. The shopper places an order in the merchant's online store. Please note that our Test Environment enables you to test your implementation. The merchant's system sends an XML message with the order and payment information to our system. 2. please refer to Redirect the Shopper to Issuer (arrow 4). (Please refer to the Submitting Transactions in the Direct Model for further details on constructing and submitting this XML message). This process involves providing replies to two XML messages and redirecting the shopper to an authentication page.

The merchant includes the authentication response in the original XML order message and sends it to RBS WorldPay. please refer to Second Order Message (arrow 6). please refer to Second Order Reply Message (arrow 9) XML Messages and HTML Redirect The following XML messages and HTML page are involved in the authentication process. then one of two things will occur depending on the configuration of the merchant’s RBS WorldPay account as outlined below: • if the merchant’s RBS WorldPay account doesn’t have the Risk Management Module (RMM) activated. 8. Please Note: your system doesn’t have to use an HTML form to generate the HTTP POST to the card issuer’s site. After receiving the response from the acquirer. including the 3-D Security Authentication information. 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. 3D Secure Page 25 of 56 . 9. the RBS WorldPay system will respond with the reply message detailed in step 4 again. and the payer authentication response is then posted to the merchant's site. 6. RBS WorldPay send an authorisation response to the merchant. The authentication response is sent to the shopper. This provides the merchant’s system with the opportunity to request for the shopper to go though the payer authentication process again If the merchant’s RBS WorldPay account has the RMM activated then the merchant’s system will receive a REFUSED message from RBS WorldPay.Submitting Transactions in the XML Direct Model with 3D Secure Guide 5. 7. This HTML form is provided as an example only of what is required to generate a submission to the card issuer’s site: 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. If the authentication response shows that the shopper failed to authenticate themselves.

<paymentService merchantCode="MYMERCHANT" version="1. 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..123. These elements are used to redirect the shopper to the correct issuer site for authentication. The acceptHeader element should contain the exact content of the HTTP accept header as sent to the merchant from the shopper's user agent. 3D Secure Page 26 of 56 ..123.123" id="112233"/> </paymentDetails> <shopper> <browser> <acceptHeader>text/html</acceptHeader> <userAgentHeader>Mozilla/5. The session element must be supplied for a 3-D Secure transaction. Only a few additional elements are added and some elements are made mandatory for use with 3-D Secure.Submitting Transactions in the XML Direct Model with 3D Secure Guide The first order message is almost the same as the regular order messages.4"> <submit> <order orderCode="merchantGeneratedOrderCode"> <description>Description</description> <amount currencyCode="EUR" 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.0 . Please note. acceptHeader and userAgentHeader. when using the Test environment.</userAgentHeader> </browser> </shopper> </order> </submit> </paymentService> The new elements are browser. the cardHolderName element must contain '3D' as the cardholder name.

An example of the complete message is shown below. to which the HTTP POST must be submitted. This element must be supplied in all subsequent messages as-is.url/3dsec. A request for 3-D Secure authentication is defined with element name request3DSecure.Submitting Transactions in the XML Direct Model with 3D Secure Guide Initial Order Reply Message (arrow 3) This message extends the orderStatus element with a new sub-element.issuer. Redirect the Shopper to Issuer (arrow 4) When the merchant receives the first reply with the request for 3-D Secure authentication. which is used by our software to process the subsequent messages belonging to the same transaction more efficiently. This is shopper's Issuer site where the shopper should authenticate themselves with the 3-D Secure mechanism. The HTTP POST must contain the attributes "PaReq" and "TermUrl". 3D Secure Page 27 of 56 .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". The value for the "PaReq" attribute must be the data supplied in the paRequest element of the reply message. <paymentService merchantCode="MYMERCHANT" version="1.4"> <reply> <orderStatus orderCode='merchantGeneratedOrderCode'> <requestInfo> <request3DSecure> <paRequest>somedata</paRequest> <issuerURL>http://example. An extra element echoData is added. This element is a container for possible requests for information on the submitted order. This data must be supplied as-is in the redirect message to the shopper's issuer site. the merchant must redirect the shopper to the issuer's site. is given in the issuerUrl element of the reply message. The Issuer's site URL. This must be done by submitting an HTTP POST to the Issuer URL. requestInfo. The issuerURL element contains the actual URL to which the shopper must be redirected.

If your browser does not start loading the page.submit().<br/> implemented. <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 "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)."> This page should forward you to your own card issuer for identification.. This HTML example page redirects the shopper to the Issuer's site: <html> <head> <title>3-D Secure helper page</title> </head> <body OnLoad="OnLoadEvent().Submitting Transactions in the XML Direct Model with 3D Secure Guide The value for the "TermUrl" attribute is a URL pointing to the merchant's site.. 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.theForm. press the button you see. It specifies the service to which the shopper is redirected from the issuer's site. } // --> </script> </body> </html> 3D Secure Page 28 of 56 . <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. The merchant is responsible for supplying a correct value. document.

the info3DSecure element (and sub elements) and the echoData element.4"> <submit> <order orderCode="merchantGeneratedOrderCode" "> <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="2006"/> </expiryDate> <cardHolderName>3D</cardHolderName> </VISA-SSL> <session shopperIPAddress="123.. or the second order message will be rejected by the RBS WorldPay system <paymentService merchantCode="MYMERCHANT" version="1.Submitting Transactions in the XML Direct Model with 3D Secure Guide When the shopper has enabled Javascript in the browser.0 . In the echoData element the merchant must supply the same data as it received in the first reply message. Only two elements are added.. 3D Secure Page 29 of 56 .123. If Javascript has been disabled. 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.</userAgentHeader> </browser> </shopper> <echoData>somedata</echoData> </order> </submit> </paymentService> The info3DSecure element contains the payer authentication response data received by the shopper/merchant from the issuer. Your system must ensure that there are no differences in the second order message other than those shown in the below example.123. Second Order Message (arrow 6) The second order message is almost the same as the initial order message. the shopper will automatically forwarded to the Issuer's site.

getResponseHeader("SetCookie").cookie").Submitting Transactions in the XML Direct Model with 3D Secure Guide Please note: we use a farm of web servers to serve requests and as such the RBS WorldPay system needs to ensure that the first and second orders are processed by the same web servers. Once you have redirected your shopper and received the PaRes from the card issuers site your system will then need to set the session cookie in the HTTP header of the second XML order that is sent to RBS WorldPay. No additional elements are added. 2nd CURL submission needs a parameter of: curl_setopt ($ch. again this can be done using xmlhttp. VALUE OF COOKIE Equivalent functions for PHP using Curl would be as follows: 1st CURL submission needs a parameter of: curl_setopt ($ch.4"> <reply> <orderStatus orderCode="merchantGeneratedOrderCode"> <payment> <paymentMethod>VISA-SSL</paymentMethod> 3D Secure Page 30 of 56 . In order to facilitate this. The session cookie can be captured in ASP using xmlhttp. <paymentService merchantCode="MYMERCHANT" version="1. Failed Authentication (arrow 7) If a shopper fails to authenticate themselves.cookie"). then you will receive a normal REFUSED reply. CURLOPT_COOKIEFILE. Please Note: that the above methods of capturing the session cookie are provided as examples only and as such are not supported by RBS WorldPay. you will receive the normal reply for authorised payments. which includes the payer authentication response data. you need to extract the session cookie that is passed back in the HTTP header of the XML message (the response from the Payment Service with the issuerURL) and return it in the HTTP header of the second XML order.setRequestHeader "Cookie". "cookie. "cookie. CURLOPT_COOKIEJAR. <payment> <paymentMethod>MAESTRO-SSL</paymentMethod> <amount value="2750" currencyCode="GBP" exponent="2" debitCreditIndicator="credit"/> <lastEvent>REFUSED</lastEvent> <ISO8583ReturnCode code="76" description="REFUSED"/> </payment> Second Reply Message (arrow 9) Authorised If the shopper authenticates successfully.

Submitting Transactions in the XML Direct Model with 3D Secure Guide <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> 3D Secure Page 31 of 56 .

The name Eurocard is no longer in use. Carte Bancaire Carte Bleue CB-SSL France CARTEBLEUESSL DINERS-SSL LASER-SSL DISCOVER-SSL France Diners Laser Card Discover Card Japanese Credit Bank Dankort International Ireland United States JCB-SSL International. Japan Denmark DANKORT-SSL Online Debit Methods payment method code RABODIRECTBETALEN name area remarks Rabobank DirectBetalen Netherlands For Rabobank shoppers only. For ING shoppers ING Homepay HOMEPAY-SSL Belgium 3D Secure Page 32 of 56 .Submitting Transactions in the XML Direct Model with 3D Secure Guide Appendices Payment Method Codes The child elements below are used to define the card type that is used by the shopper. name payment method code AMEX-SSL area remarks American Express SSL VISA MasterCard International VISA-SSL ECMC-SSL International International Visa Credit/Debit/Electron. Shopper is redirected to Rabobank server.

Austria. either manually or through an electronic banking system. Italy. Luxemburg. Spain. If 3D Secure Page 33 of 56 . Spain. Paybox Elektronisches Lastschriftverfahren ELV-SSL Offline Payment Methods name Domestic Bank transfer payment method code TRANSFER_NL-BANK TRANSFER_BE-BANK TRANSFER_DE-BANK TRANSFER_FI-BANK TRANSFER_FR-BANK TRANSFER_IT-BANK TRANSFER_ES-BANK TRANSFER_GB-BANK TRANSFER_SE-BANK TRANSFER_AT-BANK TRANSFER_LU-BANK TRANSFER_CH-BANK area Netherlands. Solo SOLO_GB-SSL UK Depending upon the issuer policy. Depending upon the issuer policy. will be discontinued. Maestro MAESTRO-SSL UK WWW-Bon ICCHEQUE-SSL Netherlands Nordea Bank SOLO-SSL (Fi) EBETALNINGSSL (Se) PAYBOX-SSL Finland. Sweden Germany. Sweden.Submitting Transactions in the XML Direct Model with 3D Secure Guide only. Switzerland. Internet voucher. Germany. Shopper needs to have a ING Homepay account at his bank. Finland. UK Germany Payment method using mobile phone. France. UK. Belgium. remarks Shopper transfers the money using a bank transfer. Austria. either the issuer number or the start date may need to be included in the paymentDetails. either the issuer number or the start date must be included in the paymentDetails.

the shopper may be presented with extra charges (cross border fees) from the banks. Regular cheque payments. Shopper needs to have a ING Homepay account at his bank. Forms have to be printed. Germany Rembours / Cash on Delivery CASH-DELIVERY The Netherlands. For ING shoppers only. Norway bank transfers are used for internationa l payments. Germany Germany Deutsche Bank DB24-BANK 24 Dresdner Bank DRESDNER-BANK InternetBanking Commerz Bank COMLINE-BANK Online Banking Web AcceptGiro ACCEPTGIRO_NL-BANK Germany Germany The Merchant has to use 3D Secure Page 34 of 56 .Submitting Transactions in the XML Direct Model with 3D Secure Guide TRANSFER_DK-BANK TRANSFER_GR-BANK TRANSFER_NO-BANK Denmark. signed and sent to RBS WorldPay Cheque CHEQUE-BANK Belgium Cheque CHEQUE_GB-BANK UK Direct Debit INCASSO_NL-FAX INCASSO_DE-FAX The Netherlands. Greece.

Submitting Transactions in the XML Direct Model with 3D Secure Guide Netherlands the 'reference id' as payment reference to be printed on the accept giro forms. The Netherlands ISO Currency Codes Currencies accepted by the RBS WorldPay Payment Service are listed below. Merchants should use 'exponent' instead.org/iso4217. In the following example the amount payable by the shopper is Euro 19. Please note that the values in the orders sent to RBS WorldPay NEVER have any decimal delimiters.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 Swiss Franc Chilean Peso exponent 2 AUD 2 BRL 2 CAD CHF CLP 2 2 2 3D Secure Page 35 of 56 .id3. PERMANENT_SIGNED_DD_NL SINGLE_UNSIGNED_DD_FR SINGLE_UNSIGNED_DD_NL The Netherlands France. Exponent is the number of decimals available in the currency. Also note that currency code is always in capitals.

Submitting Transactions in the XML Direct Model with 3D Secure Guide CNY Yuan Renminbi Colombian Peso Czech Koruna Danish Krone Euro Pound Sterling Hong Kong Dollar Hungarian Forint Indonesian Rupiah Iceland Krona Japanese Yen Kenyan Shilling SouthKorean Won Mexican Peso Malaysian Ringgit Norwegian Krone New Zealand Dollar Philippine Peso New Polish Zloty Portugese 2 COP CZK 2 2 DKK 2 EUR GBP 2 2 HKD HUF 2 2 IDR 0 ISK JPY 2 2 KES 2 KRW MXP 2 2 MYR NOK 2 2 NZD 2 PHP PLN 2 2 PTE 2 3D Secure Page 36 of 56 .

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 status AUTHORISED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED 3D Secure Page 37 of 56 . etc. their numeric value and the mapping to a status. REFUSED. Below you will find all possible response codes.Submitting Transactions in the XML Direct Model with 3D Secure Guide Escudo SEK SGD Swedish Krone Singapore Dollar Slovak Koruna Thai Baht New Taiwan Dollar US Dollars Vietnamese New Dong South African Rand 2 2 SKK 2 THB TWD 2 2 USD VND 2 2 ZAR 2 Acquirer Response Codes RBS WorldPay uses the ISO 8583 Response Codes in the orderStatusEvent messages to indicate the status of the payment: AUTHORISED. The Payment Service maps these responses to a simplified list.

Submitting Transactions in the XML Direct Model with 3D Secure Guide 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. PICK UP 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 REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED REFUSED 3D Secure Page 38 of 56 .

Submitting Transactions in the XML Direct Model with 3D Secure Guide 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 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 REFUSED ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR 3D Secure Page 39 of 56 .

it is an uppercase two-letter 'ISO 3166' standard country code..org/iso/en/prods-services/iso3166ma/02iso-3166code-lists/list-en1. AUTHORISATION EXPIRED 92 CREDITCARD TYPE NOT PROCESSED BY ACQUIRER 94 DUPLICATE REQUEST ERROR ERROR ERROR ERROR ERROR ISO Country Codes The countryCode element is used in XML orders/communications.iso.html ISO 3166 Two-Letter Country Codes <countryCode> country name or country parameter value AFGHANISTAN ÅLAND ISLANDS ALBANIA AF AX AL 3D Secure Page 40 of 56 . <address> <countryCode>GB</countryCode> </address> ISO source reference: http://www.Submitting Transactions in the XML Direct Model with 3D Secure Guide 68 TRANSACTION TIMED OUT 80 AMOUNT NO LONGER AVAILABLE.. as shown in the following example: .

Submitting Transactions in the XML Direct Model with 3D Secure Guide ALGERIA AMERICAN SAMOA ANDORRA ANGOLA ANGUILLA ANTARCTICA ANTIGUA AND BARBUDA ARGENTINA ARMENIA ARUBA AUSTRALIA AUSTRIA AZERBAIJAN BAHAMAS BAHRAIN BANGLADESH BARBADOS BELARUS BELGIUM BELIZE BENIN BERMUDA DZ AS AD AO AI AQ AG AR AM AW AU AT AZ BS BH BD BB BY BE BZ BJ BM 3D Secure Page 41 of 56 .

Submitting Transactions in the XML Direct Model with 3D Secure Guide BHUTAN BOLIVIA BOSNIA AND HERZEGOVINA BOTSWANA BOUVET ISLAND BRAZIL BRITISH INDIAN OCEAN TERRITORY BRUNEI DARUSSALAM BULGARIA BURKINA FASO BURUNDI CAMBODIA CAMEROON CANADA CAPE VERDE CAYMAN ISLANDS CENTRAL AFRICAN REPUBLIC CHAD CHILE BT BO BA BW BV BR IO BN BG BF BI KH CM CA CV KY CF TD CL 3D Secure Page 42 of 56 .

Submitting Transactions in the XML Direct Model with 3D Secure Guide CHINA CHRISTMAS ISLAND COCOS (KEELING) ISLANDS COLOMBIA COMOROS CONGO CONGO. THE DEMOCRATIC REPUBLIC OF THE COOK ISLANDS COSTA RICA CÔTE D'IVOIRE CROATIA CUBA CYPRUS CZECH REPUBLIC DENMARK DJIBOUTI DOMINICA DOMINICAN REPUBLIC ECUADOR CN CX CC CO KM CG CD CK CR CI HR CU CY CZ DK DJ DM DO EC 3D Secure Page 43 of 56 .

Submitting Transactions in the XML Direct Model with 3D Secure Guide EGYPT EL SALVADOR EQUATORIAL GUINEA ERITREA ESTONIA ETHIOPIA FALKLAND ISLANDS (MALVINAS) FAROE ISLANDS FIJI FINLAND FRANCE FRENCH GUIANA FRENCH POLYNESIA FRENCH SOUTHERN TERRITORIES GABON GAMBIA GEORGIA GERMANY GHANA GIBRALTAR EG SV GQ ER EE ET FK FO FJ FI FR GF PF TF GA GM GE DE GH GI 3D Secure Page 44 of 56 .

Submitting Transactions in the XML Direct Model with 3D Secure Guide GREECE GREENLAND GRENADA GUADELOUPE GUAM GUATEMALA GUERNSEY GUINEA GUINEA-BISSAU GUYANA HAITI HEARD ISLAND AND MCDONALD ISLANDS HOLY SEE (VATICAN CITY STATE) HONDURAS HONG KONG HUNGARY ICELAND INDIA INDONESIA IRAN. ISLAMIC REPUBLIC OF IRAQ GR GL GD GP GU GT GG GN GW GY HT HM VA HN HK HU IS IN ID IR IQ 3D Secure Page 45 of 56 .

REPUBLIC OF KUWAIT KYRGYZSTAN LAO PEOPLE'S DEMOCRATIC REPUBLIC LATVIA LEBANON LESOTHO LIBERIA LIBYAN ARAB IE IL IT JM JP JE JO KZ KE KI KP KR KW KG LA LV LB LS LR LY 3D Secure Page 46 of 56 .Submitting Transactions in the XML Direct Model with 3D Secure Guide IRELAND ISRAEL ITALY JAMAICA JAPAN JERSEY JORDAN KAZAKHSTAN KENYA KIRIBATI KOREA. DEMOCRATIC PEOPLE'S REPUBLIC OF KOREA.

FEDERATED STATES OF MOLDOVA. THE FORMER YUGOSLAV REPUBLIC OF MADAGASCAR MALAWI MALAYSIA MALDIVES MALI MALTA MARSHALL ISLANDS MARTINIQUE MAURITANIA MAURITIUS MAYOTTE MEXICO MICRONESIA.Submitting Transactions in the XML Direct Model with 3D Secure Guide JAMAHIRIYA LIECHTENSTEIN LITHUANIA LUXEMBOURG MACAO MACEDONIA. REPUBLIC OF LI LT LU MO MK MG MW MY MV ML MT MH MQ MR MU YT MX FM MD 3D Secure Page 47 of 56 .

Submitting Transactions in the XML Direct Model with 3D Secure Guide MONACO MONGOLIA MONTSERRAT MOROCCO MOZAMBIQUE MYANMAR NAMIBIA NAURU NEPAL NETHERLANDS NETHERLANDS ANTILLES NEW CALEDONIA NEW ZEALAND NICARAGUA NIGER NIGERIA NIUE NORFOLK ISLAND NORTHERN MARIANA ISLANDS NORWAY OMAN MC MN MS MA MZ MM NA NR NP NL AN NC NZ NI NE NG NU NF MP NO OM 3D Secure Page 48 of 56 .

OCCUPIED PANAMA PAPUA NEW GUINEA PARAGUAY PERU PHILIPPINES PITCAIRN POLAND PORTUGAL PUERTO RICO QATAR RÉUNION ROMANIA RUSSIAN FEDERATION RWANDA SAINT BARTHELEMY SAINT HELENA SAINT KITTS AND NEVIS PK PW PS PA PG PY PE PH PN PL PT PR QA RE RO RU RW BL SH KN 3D Secure Page 49 of 56 .Submitting Transactions in the XML Direct Model with 3D Secure Guide PAKISTAN PALAU PALESTINIAN TERRITORY.

Submitting Transactions in the XML Direct Model with 3D Secure Guide SAINT LUCIA SAINT PIERRE AND MIQUELON SAINT VINCENT AND THE GRENADINES SAMOA SAN MARINO SAO TOME AND PRINCIPE SAUDI ARABIA SENEGAL SERBIA AND MONTENEGRO SEYCHELLES SIERRA LEONE SINGAPORE SLOVAKIA SLOVENIA SOLOMON ISLANDS SOMALIA SOUTH AFRICA SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS SPAIN LC PM VC WS SM ST SA SN CS SC SL SG SK SI SB SO ZA GS ES 3D Secure Page 50 of 56 .

UNITED REPUBLIC OF THAILAND TIMOR-LESTE TOGO TOKELAU TONGA TRINIDAD AND TOBAGO TUNISIA TURKEY TURKMENISTAN LK SD SR SJ SZ SE CH SY TW TJ TZ TH TL TG TK TO TT TN TR TM 3D Secure Page 51 of 56 . PROVINCE OF CHINA TAJIKISTAN TANZANIA.Submitting Transactions in the XML Direct Model with 3D Secure Guide SRI LANKA SUDAN SURINAME SVALBARD AND JAN MAYEN SWAZILAND SWEDEN SWITZERLAND SYRIAN ARAB REPUBLIC TAIWAN.

U.refer to HOLY SEE VENEZUELA VIET NAM VIRGIN ISLANDS.Submitting Transactions in the XML Direct Model with 3D Secure Guide TURKS AND CAICOS ISLANDS TUVALU UGANDA UKRAINE UNITED ARAB EMIRATES UNITED KINGDOM UNITED STATES UNITED STATES MINOR OUTLYING ISLANDS URUGUAY UZBEKISTAN VANUATU Vatican City State . WALLIS AND FUTUNA WESTERN SAHARA TC TV UG UA AE GB US UM UY UZ VU VA VE VN VG VI WF EH 3D Secure Page 52 of 56 . BRITISH VIRGIN ISLANDS.S.

<cardHolderName>J.Submitting Transactions in the XML Direct Model with 3D Secure Guide YEMEN ZAMBIA ZIMBABWE YE ZM ZW CVC/CVV Checks and Responses You can carry out a Security Code Verification (CVC/CVV) check on an individual direct order.or 4-digit value printed on the card (for example.. Shopper</cardHolderName> <cvc>123</cvc> <cardAddress> . on a signature strip). CVC/CVV is a 3. An order without the CVC code fragment will not be checked. CVC/CVV code simulated situation numeric respons e B Left blank NOT SUPPLIED BY SHOPPER NOT SENT TO ACQUIRER NO RESPONSE FROM ACQUIRER NOT CHECKED BY ACQUIRER FAILED APPROVED 111 222 C C 333 444 555 C D A 3D Secure Page 53 of 56 . Testing The following CVC/CVV scenarios can be tested using the codes listed below. but not encoded on the magnetic stripe. Only orders containing a valid CVC/CVV code fragment will be checked. and enables the security code entered by the shopper to be compared against the card issuer's records during the payment process. as displayed in the example below..

dtd Examples The following are some examples for these error codes. Invalid request 6.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd. a general error 2. occurs when XML is valid but content of XML is not 7. Parse error. Error Code 2 <?xml version="1. Invalid content.Submitting Transactions in the XML Direct Model with 3D Secure Guide XML Error Codes The list of XML error codes is as follows: 1.wps. Payment details in the order element are incorrect http://dtd.com/paymentService_v1.dtd"> <paymentService merchantCode="MYCO" version="1. Security error 5.3"> <reply> <error code="4"><![CDATA[IP check failed.rbsworldpay. invalid XML 3.rbsworldpay. Internal error.]]></error> </reply> </paymentService> Error Code 5 3D Secure Page 54 of 56 .0"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd. Invalid number of transactions in batch 4.com/paymentService_v1.rbsworldpay.om/paymentService_v1.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.dtd"> <paymentService version="1. Access denied.

3" merchantCode="MYCO"> <reply> 3D Secure Page 55 of 56 .com/paymentService_v1.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN""http://dtd.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd.0"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN""http://dtd.50) exceeds the authorised balance for this payment (EUR 115.dtd"> <paymentService version="1.com/paymentService_v1.dtd"><paymentS ervice version="1.rbsworldpay.Submitting Transactions in the XML Direct Model with 3D Secure Guide <?xml version="1.dtd"><p aymentService merchantCode="MYCO" 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> </reply> </paymentService> <?xml version="1.dtd"> <paymentService version="1.rbsworldpay.50)]]></error> </orderStatus> </reply> </paymentService> Error Code 7 <?xml version="1.3" merchantCode="MYCO"> <reply> <error code="5"><![CDATA[Duplicate Order]]></error> </reply> </paymentService> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd.com/paymentService_v1.com/paymentService_v1.4"> <reply> <orderStatus orderCode="11223"> <error code="5"><![CDATA[Requested capture amount (EUR 125.rbsworldpay.rbsworldpay.

com/paymentService_v1.rbsworldpay.Submitting Transactions in the XML Direct Model with 3D Secure Guide <orderStatus orderCode="1112"> <error code="7"><![CDATA[Invalid payment details : Expiry date = 012002]]></error> </orderStatus> </reply> </paymentService> <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd.dtd"> <paymentService version="1.4" merchantCode="MYCO"> <reply> <orderStatus orderCode="11223"> <error code="7"><![CDATA[Gateway error]]></error> </orderStatus> </reply> </paymentService> 3D Secure Page 56 of 56 .

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->