Worldpay MPI

3D Secure (3DS)

3DS is a three step process that requires you to send a message to Worldpay, use the response to redirect the shopper to the issuer, and provide us with the authentication result.

We also offerDynamic 3DS, whereby you can use rules to choose when your shoppers are authenticated.

Step one: collect the order and send the first message

  1. The shopper places an order in your online store.
  2. Yousend the first messagewith the order and payment information to Worldpay.
  3. We carry out a verification check to identify if the card is enrolled in the 3DS scheme.

    If the card isn't enrolled in 3DS, after receiving an authorisation response from the acquirer (and assuming all other checks passed) we send you the normalAUTHORISEDresponse and the process ends.

  4. We send a message to you to request payer authentication and the process continues.

First 3DS flow

Send the first message

You must supply:

  • The id attribute of the <session> element
  • The <acceptHeader> element
  • The <userAgentheader> element

Example first 3DS message

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService_v1.dtd">
<paymentService version="1.4" merchantCode="YOUR_MERCHANT_CODE"><!--Enter your own merchant code-->
   <submit>
      <order orderCode="YOUR_ORDER_CODE"> <!--Enter a unique order code each time-->
         <description>YOUR DESCRIPTION</description>
         <amount value="2000" currencyCode="EUR" exponent="2" />
         <orderContent />
         <paymentDetails>
            <CARD-SSL>
               <cardNumber>4444333322221111</cardNumber>
               <expiryDate>
                  <date month="01" year="2020" />
               </expiryDate>
               <cardHolderName>3D</cardHolderName>
               <cvc>123</cvc>
               <cardAddress>
                  <address>
                     <address1>Worldpay</address1>
                     <address2>270-289 The Science Park</address2>
                     <address3>Milton Road</address3>
                     <postalCode>CB4 0WE</postalCode>
                     <city>Cambridge</city>
                     <countryCode>GB</countryCode>
                  </address>
               </cardAddress>
            </CARD-SSL>
            <session shopperIPAddress="127.0.0.1" id="SESSION_ID" /> <!--Session id must be unique for each order-->
         </paymentDetails>
         <shopper>
            <shopperEmailAddress>jshopper@myprovider.com</shopperEmailAddress>
            <browser>
               <acceptHeader>text/html</acceptHeader>
               <userAgentHeader>Mozilla/5.0 ...</userAgentHeader>
            </browser>
         </shopper>
      </order>
   </submit>
</paymentService>

Step two: use our reply and redirect the shopper

From our reply message, extract the payer authentication response and store the machine cookie. You then redirect the shopper to the issuer site for 3DS authentication and await the authentication result from the issuer.

3ds reply flow

Our reply to the first message (card enrolled in 3DS)

When we reply, your system must extract the machine cookie passed back in the HTTP header of this reply message. You must then return the corresponding cookie, and the payer authentication response, in the HTTP header of the second order message:

Warning: The cookie you return is slightly different from the cookie in our reply. For example:

  • If we send the cookie as: Set-Cookie: machine=0aa20016;path=/
  • Return the cookie in the HTTP header as: Cookie: machine=0aa20016;path=/

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService v1.dtd">
<paymentService version="1.4" merchantCode="ExampleCode1"> <!--The merchantCode you supplied in the order-->
   <reply>
      <orderStatus orderCode="ExampleOrder1"> <!--The orderCode you supplied in the order-->
         <requestInfo>
            <request3DSecure> <!--PaRequest must be supplied as-is. Do not truncate-->
               <paRequest>eJxVUsFuwjAM/ZWK80aSUgpFJogNpHEo2hjTzlVr0Uq0KUkYsK+fUwpl72Q/2y/Jc2B2LvfeD2pTqGraE33e82YStrlGXHxietQoIUZjkh16RUYdQTge8DAII3846kl4n2/wIKFVkCTQ94HdUhrVaZ5UVkKSHl5Wayk6AGs5KFGvFo8lh+eu71qHOjHmpHQmhT8IhuFoDOxOQZWUKL+V3md1cvEWWCqTqxpYw0OqjpXVFzn0aeiWwFHvZW5tPWGsUtqqylilEZjjgXV3fz+6yJDOuchk/DsX8XZ3Wi+WPP6YP2IKzHVAlliUPhchHwnf4+FkGEz8CFjDQ1K6C8jl18YTT5yTD1cCanfO/JoIV3gkgJahsUovMnIvv2eA51pVSB1k/D2GDE0qLRrrkT2o6WxHAOve8vrmtpJasjYgDAg+4baapuDEC7JKRDxs1F0CzI2ydvWs/R4U/fs2f8B1wXg=</paRequest>
               <issuerURL><![CDATA[https://secure-test.worldpay.com/jsp/test/shopper/ThreeDResponseSimulator.jsp]]></issuerURL>
            </request3DSecure>
         </requestInfo>
         <echoData>1374244409987691395</echoData> <!--For compatibility with older integrations - can be ignored-->
      </orderStatus>
   </reply>
</paymentService>
Card not enrolled reply to the first message

If the card isn't enrolled in 3DS, after receiving an authorisation response from the acquirer (and assuming all other checks passed) we send you the normalAUTHORISEDresponse and the process ends.

Redirect the shopper

When you receive the first reply with the request for 3DS authentication, you must redirect the shopper to the URL of the issuer's 3DS authentication site by generating a self-submitting HTML form using these rules:

  • The method of the form should be POST.
  • The form action must contain:
    • The content of the <issuerURL> from our first response
    • A hidden input with the name PaReq. The value for the PaReq input must be the exact data we supplied in the <paRequest> element of our first reply message
    • A hidden input with the name TermUrl. The value for this is a URL pointing to your website. This URL specifies where the shopper is redirected from the issuer’s 3DS authentication site (and where you'll handle the 3DS response)
  • Optionally, you can also add the MD input. This can:
    • Contain any data, and is supplied in the same form as it is written in the final post (when the shopper is redirected from the issuer's 3DS authentication site to your site)
    • Be used to handle the session state between the original shopping session and the final post after the shopper has been authenticated

Below is an example of one way to include this content. Provided that the shopper has enabled Javascript in the browser, the shopper will automatically be forwarded to the issuer's site. If Javascript has been disabled, the shopper must press the submit button ("Continue" in the below example) to continue.

Example HTML redirect page

Copied!
<!DOCTYPE html>
<html>
   <head>
      <meta charset="UTF-8">
      <title>Cardholder authentication</title>
   </head>
   <body OnLoad="OnLoadEvent();">
      This page should forward you to your own card issuer for identification. If your browser does not start loading the page, press the Continue button.<br/>
      After you successfully identify yourself you will be sent back to this website, where the payment process will continue.<br/>
      <form name="form_name" method="post" action="The value of the issuerUrl element">
         <input type="hidden" name="PaReq" value="The value of the paRequest element" />
         <input type="hidden" name="TermUrl" value="Your URL to receive the authentication result" />
         <input type="hidden" name="MD" value="Data for your reference" />
         <input type="submit" value="Continue" />
      </form>
      <script>
         function OnLoadEvent(){
         document.form_name.submit();
         }
      </script>
   </body>
</html>

Step three: use the authentication response and send the second message

You'll receive the authentication response from the issuer. Extract the PaRes and use it to create and send us a second XML message (along with the machine cookie).

3ds send second message

Send the second message

You'll receive a HTTP post to your TermUrl which will contain the PaRes and the MD (the authentication response from the issuer).

Extract the PaRes and use it to create and send us the second message, which must contain:

  • The orderCode from the first order message
  • The shopper <session> id from the first order message
  • <info3DSecure> , which in turn contains the 3DS authentication response data (PaRes) received by the shopper and you, from the issuer (placed in the <paResponse>)
  • The (case sensitive) machine cookie extracted from the HTTP header of the initial reply message, placed into the HTTP header of this message

If you don't return the machine cookie in the HTTP header, you'll get an error code 7 - 'Could not find bean(s) in session cache'.

Example second 3DS order

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//Worldpay//DTD Worldpay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService_v1.dtd">
<paymentService version="1.4" merchantCode="YOUR_MERCHANT_CODE">
    <submit>
        <order orderCode="jsxml3792597179"> <!--The order code from the first message-->
            <info3DSecure> <!--PaResponse must be supplied as-is. Do not truncate-->
                <paResponse>eJx9UlFvgjAQft+vILxrQQHBnDUsaMKDxkyW7JXABZsIuBaM+/e7VicuZvte2n739e67a2F5qY/WGaUSbbOw3bFjW9gUbSmaamG/Z+tRaC85ZAeJmOyx6CVy2KBSeYWWKOmGF/hR6LmzwA9dm8MufkP1HBkrUTVYkuBWi1Op8QTYz5GSyuKQNx2HvPh8TbfcHQDsxkGNMk0eQxqjQXeNAxuy7Xq9U2T7Ikqexn9iAUwroMw75BPHDZzA9S0nmnvRfBoAMzycdLq4bnvK7ToOsEcCaD6SxvfFo1kI7H4CvJzaBklBHd/3wAZvu3jLPcKUMCFcu9EsZB8cOlE/efKmwAwPqsu7XvE0WW2zdJ2uEmA3Cor8fOabf5s2EsBCcMcnd7SaW/GxaqXoDrX2/JsApj0x89Qc9vSyVEwiM3M3X0NLHr/MyzdYf7wy</paResponse>
            </info3DSecure>
            <session id="ssn792597179"/> <!--The session id in the first message-->
        </order>
    </submit>
</paymentService>

Second 3DS order reply message

The second response returns a status of either:

  • AUTHORISED - We obtained authorisation from the issuer, and all other checks (such as Worldpay fraud detection services) have passed.

    Best practice: We recommend checking the ThreeDSecureResult description to see if you are entitled toliability shift.

  • REFUSED - Either the shopper failed to authenticate themselves, the issuer has declined the transaction, or Worldpay fraud detection services prevented the authorisation (in which case the <ISO8583ReturnCode> will indicate FRAUD_SUSPICION)

  • CANCELLED - Worldpay fraud detection service settings stopped the transaction (threshold exceeded).
  • ERROR - Typically this will be a '7 - could not find beans' error (explained below)

This error is caused by a cookie reference not being supplied by your system in the second request.

Capture the marchine cookie from the HTTP header received in the first 3DS XML response. The machine cookie looks similar to Set-Cookie: machine=9b88fe17;path=/, which you then need to place (as Cookie: machine=9b88fe17;path=/) into the HTTP header of your second XML request.

An example of the error message from Worldpay:

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//Worldpay//DTD Worldpay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService_v1.dtd">
<paymentService version="1.4" merchantCode="ExampleCode1"> <!--The merchantCode you supplied in the order-->
   <reply>
      <orderStatus orderCode="ExampleOrder1"> <!--The order code from the first message-->
         <error code="7"><![CDATA[Internal error! Could not find bean(s) in session cache.]]></error>
      </orderStatus>
   </reply>
</paymentService>

Example AUTHORISED reply to second 3DS message

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//WorldPay//DTD WorldPay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService_v1.dtd">
<paymentService version="1.4" merchantCode="ExampleCode1"> <!--The merchantCode you supplied in the order-->
   <reply>
      <orderStatus orderCode="ExampleOrder1"> <!--The orderCode you supplied in the order-->
         <payment>
            <paymentMethod>VISA-SSL</paymentMethod>
            <paymentMethodDetail> <!--Not returned by default - contact us to enable-->
               <card number="444433******1111" type="creditcard">
                  <expiryDate> <!--Not returned by default - contact us to enable-->
                     <date month="01" year="2020" />
                  </expiryDate>
               </card>
            </paymentMethodDetail>
            <amount value="2000" currencyCode="EUR" exponent="2" debitCreditIndicator="credit" />
            <lastEvent>AUTHORISED</lastEvent>
            <AuthorisationId id="666" />
            <CVCResultCode description="A" />
            <AVSResultCode description="A" />
            <AAVAddressResultCode description="B" />
            <AAVPostCodeResultCode description="B" />
            <AAVCardholderNameResultCode description="B" />
            <AAVTelephoneResultCode description="B" />
            <AAVEmailResultCode description="B" />
            <ThreeDSecureResult description="Cardholder authenticated">
               <eci>05</eci> <!--Not returned by default - contact us to enable-->
               <cavv>MAAAAAAAAAAAAAAAAAAAAAAAAAA=</cavv> <!--Not returned by default - contact us to enable-->
            </ThreeDSecureResult>
            <cardHolderName>
                <!CDATA[3D]]>
            </cardHolderName>
            <issuerCountryCode>N/A</issuerCountryCode>
            <balance accountType="IN_PROCESS_AUTHORISED">
               <amount value="2600" currencyCode="EUR" exponent="2" debitCreditIndicator="credit" />
            </balance>
            <riskScore value="2" />
         </payment>
      </orderStatus>
   </reply>
</paymentService>

Test values

Input these magic values in the <cardHolderName> of the second message:

Magic value3DS result
"3D"Invokes the 3D Secure simulator page, where you can select values to simulate the authentication result
"NO3D"Bypasses the 3D secure simulator page, instead simulating either:
  • Authentication Offered but not Used
  • Ecommerce

Note: "Authentication Offered but not Used" applies to Verified by Visa and Mastercard SecureCode, whereas "Ecommerce" applies only to American Express SafeKey.

ECI response codes

If you have contacted us to display these in your XML, these are the Electronic Commerce Indicator values returned from the schemes to indicate the 3DS authentication result:

Visa/Amex/JCBMasterCardDescription
0502Cardholder and issuing bank are 3D Secure. 3DS Authentication successful
0601Either cardholder or issuing bank not registered for 3DS
0700Cardholder and issuing bank not registered for 3DS

Address Verification Service (AVS) and Card Verification Code (CVC)

  • AVS checks are done on the <cardAddress>.
  • The <cvc> holds the three (or four) digit number on the back of a card.
Copied!
<CARD-SSL>
    <cardNumber>4444333322221111</cardNumber>
    <expiryDate>
        <date month="01" year="2020"/>
    </expiryDate>
    <cardHolderName>J. Shopper</cardHolderName>
    <cvc>123</cvc>
    <cardAddress>
        <address>
            <address1>47A</address1>
            <postalCode>CB94BQ</postalCode>
            <city>Cambridge</city>
            <countryCode>GB</countryCode>
        </address>
    </cardAddress>
</CARD-SSL>

The information is returned with AUTHORISED, CANCELLED and REFUSED status responses.

Test values

Input these magic values in <postalCode>:

Magic valueResponse codeDescriptive responseMeaning
AAAAAAPPROVEDPostcode and address matched
BBBBBPARTIAL APPROVEDPostcode matched; address not checked
CCCCCPARTIAL APPROVEDPostcode matched; address not matched
DDDDDPARTIAL APPROVEDAddress matched; postcode not checked
EEEEENOT SENT TO ACQUIRERPostcode and address not checked
FFFFFPARTIAL APPROVEDAddress matched; postcode not matched
GGGGGPARTIAL APPROVEDPostcode not checked; address not matched
HHHHHNOT SUPPLIED BY SHOPPERPostcode and address not supplied by shopper/merchant
IIIIIPARTIAL APPROVEDAddress not checked; postcode not matched
JJJJJFAILEDPostcode and address not matched
[Left blank]HNOT SUPPLIED BY SHOPPERPostcode and address not supplied by shopper/merchant
KKKKENO RESPONSE FROM ACQUIRERPostcode and address not checked
LLLLENOT CHECKED BY ACQUIRERPostcode and address not checked
MMMMEUNKNOWNPostcode and address not checked

All cards except American Express

Input these magic values in <cvc>:

Magic valueCVC/CVV result codeCVC/CVV result description
[Left blank]B - CVV/CVC not supplied by shopper/merchantNOT SUPPLIED BY SHOPPER
111C - CVV/CVC not checkedNOT SENT TO ACQUIRER
222C - CVV/CVC not checkedNO RESPONSE FROM ACQUIRER
333C - CVV/CVC not checkedNOT CHECKED BY ACQUIRER
444D - CVV/CVC not matchedFAILED
555A - CVV/CVC matchedAPPROVED

American Express

Input these magic values in <cvc>:

Magic valueCVC/CVV result codeCVC/CVV result description
[Left blank]B - CVV/CVC not supplied by shopper/merchantNOT SUPPLIED BY SHOPPER
1111C - CVV/CVC not checkedNOT SENT TO ACQUIRER
2222C - CVV/CVC not checkedNO RESPONSE FROM ACQUIRER
3333C - CVV/CVC not checkedNOT CHECKED BY ACQUIRER
4444D - CVV/CVC not matchedFAILED
5555C - CVV/CVC not checkedUNKNOWN
6666A - CVV/CVC matchedAPPROVED

AVS response codes

CodeDescription
APostcode and address matched
BPostcode matched; address not checked
CPostcode matched; address not matched
DAddress matched; postcode not checked
EPostcode and address not checked
FAddress matched; postcode not matched
GPostcode not checked; address not matched
HPostcode and address not supplied by shopper/you
IAddress not checked; postcode not matched
JPostcode and address not matched

CVV/CVC response codes

CodeDescription
ACVV/CVC matched
BCVV/CVC not supplied by shopper/you
CCVV/CVC not checked
DCVV/CVC not matched

American Express Advanced Verification (AAV)

This can be used to further validate the identity of the cardholder.

When a shopper uses an Amex card to make a purchase:

  1. The AAV service checks the cardholder name, telephone number and email address that the shopper enters against the details held by American Express.
  2. American Express sends the result of these checks (where applicable) to Worldpay.

Using AAV

To use AAV checks, you must:

  • Ensure that you capture the cardholder name, email address and telephone number on your payment pages
  • Send the data required by the AAV service as part of your authorisation request
  • Configure your system to receive the new values generated by the checks in your XML response

Send the data required by the AAV service

Full XML example

Copied!
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE paymentService PUBLIC "-//RBS WorldPay//DTD RBS WorldPay PaymentService v1//EN" "http://dtd.wp3.rbsworldpay.com/paymentService_v1.dtd">
<paymentService version="1.4" merchantCode="YOUR MERCHANT CODE">
  <submit>
    <order orderCode="YOUR ORDER CODE">
      <description>Test</description>
      <amount value="12300" currencyCode="EUR" exponent="2"/>
      <orderContent>
        <![CDATA[    ]]>
      </orderContent>
      <paymentDetails>
        <CARD-SSL>
          <cardNumber>3714*****98431 </cardNumber>
          <expiryDate><date month="12" year="2022"/></expiryDate>
          <cardHolderName>A Shopper</cardHolderName>
          <cvc>163</cvc>
          <cardAddress>
            <address>
              <firstName>A</firstName>
              <lastName>Shopper</lastName>
              <address1>Units 270 -289</address1>
              <address2>The Science Park</address2>
              <address3>Milton Road</address3>
              <postalCode>CB4 0WE</postalCode>
              <city>Cambridge</city>
              <state>Rio</state>
              <countryCode>BR</countryCode>
              <telephoneNumber>(190)567-457</telephoneNumber>
            </address>
          </cardAddress>
        </CARD-SSL>
        <session shopperIPAddress="453.526.789.." id="ssn363692667"/>
      </paymentDetails>
      <shopper>
        <shopperEmailAddress>a.shopper@yourprovider.com</shopperEmailAddress>
        <browser>
          <acceptHeader>text/html</acceptHeader>
          <userAgentHeader>Mozilla/5.0 ...</userAgentHeader>
        </browser>
      </shopper>
      <shippingAddress>
        <address>
          <firstName>A</firstName>
          <lastName>Shopper</lastName>
          <address1>Grüner Weg 62</address1>
          <address2>5212 Frieberg</address2>
          <address3>GERMANY</address3>
          <postalCode>GHI78</postalCode>
          <city>Frieberg</city>
          <state>Germany</state>
          <countryCode>DE</countryCode>
          <telephoneNumber>(0165)-9654-456-A2</telephoneNumber>
        </address>
      </shippingAddress>
      <billingAddress>
        <address>
          <firstName>A</firstName>
          <lastName>Shopper</lastName>
          <address1>67 Green Road</address1>
          <address2>The Science Circle</address2>
          <address3>Mulberry Road</address3>
          <postalCode>CB1 7PE</postalCode>
          <city>Northampton</city>
          <countryCode>BR</countryCode>
          <telephoneNumber>(456)789-654</telephoneNumber>
        </address>
      </billingAddress>
      <shippingMethod>ground</shippingMethod>
      <productSku>45687</productSku>
    </order>
  </submit>
</paymentService>

Elements and attributes

ElementsAttributesMandatory/OptionalDescription
<productSku>OptionalThe maximum length on Worldpay's WPG is 50 characters. Longer inputs are truncated.
Amex supports only 15 characters. If your SKU is longer, it will be truncated when sent to Amex
<shippingMethod>
  • sameDay
  • nextDay
  • priority
  • ground
  • electronic
  • shipToStore
OptionalValues supported for shipping method

Configure your system to receive AAV data

You receive AAV data as a security-level single character value. The AAV single character values returned are:

ValueDescription
AData matched.
The data entered by the shopper matches the data held by American Express for the Amex card.
BData not checked.
American Express has not checked the data (either the cardholder name, telephone number or email address).
CData not supplied.
The data (either the cardholder name, telephone number or email address) was not received by American Express. The shopper may not have entered the data.
DData not matched.
The data (either the cardholder name, telephone number or email address) entered by the shopper does not match the data held by American Express for the Amex card.

Example response with AAV data

Copied!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE paymentService PUBLIC "-//Worldpay//DTD Worldpay PaymentService v1//EN" "http://dtd.worldpay.com/paymentService_v1.dtd">
<paymentService version="1.4" merchantCode="ExampleCode1"> <!--The merchantCode you supplied in the order-->
   <reply>
      <orderStatus orderCode="ExampleOrder1">  <!--The orderCode you supplied in the order-->
         <payment>
            <paymentMethod>AMEX-SSL</paymentMethod>
            <amount value="2000" currencyCode="GBP" exponent="2" debitCreditIndicator="credit" />
            <lastEvent>AUTHORISED</lastEvent>
            <AuthorisationId id="622206" />
            <CVCResultCode description="A" />
            <AVSResultCode description="A" />
            <AAVAddressResultCode description="A" />
            <AAVPostcodeResultCode description="A" />
            <AAVCardholderNameResultCode description="A" />
            <AAVTelephoneResultCode description="A" />
            <AAVEmailResultCode description="A" />
            <cardHolderName>
                <![CDATA[J shopper]]>
            </cardHolderName>
            <issuerCountryCode>GB</issuerCountryCode>
            <balance accountType="IN_PROCESS_AUTHORISED">
               <amount value="2000" currencyCode="GBP" exponent="2" debitCreditIndicator="credit" />
            </balance>
            <cardNumber>3742*******0001</cardNumber>
            <riskScore value="21" />
         </payment>
      </orderStatus>
   </reply>
</paymentService>

Test values

Magic valueResponse codeDescriptive responseMeaning
YASHOPPER DATA MATCHESData matched
NDSHOPPER DATA DOES NOT MATCHData not matched
XCDATA NOT SENTData not sent to acquirer
UBDATA NOT CHECKED BY ACQUIRERData not checked by acquirer
[Left blank]BUNKNOWNUnknown

XML reference

Elements/attributesM/ODescription
<acceptHeader>MandatoryMust contain exactly the same content as the HTTP accept header that was sent to you by the shopper’s user agent.
<userAgentHeader>MandatoryMust contain exactly the same content as the HTTP user-agent header that was sent to you by the shopper’s user agent.
<paRequest>
PaReq
MandatoryPayer authentication request received from the 3D Security Directory. This data must be supplied as-is in the redirect message to the issuer’s 3DS authentication page - must not be truncated.
<paRequest>
termUrl
MandatoryThe URL where the 3DS result will be returned to.
<paRequest>
MD
OptionalMerchant data – data provided by you. Can be used to tie up the response to the order in your system.
<issuerURL>MandatoryThe URL where you must post the 3DS data to. This will redirect the shopper.
<echoData>OptionalUsed for compatibility with older integrations of 3DS. You won't need to return this element in your second request message.
<paResponse>MandatoryThe 3DS authentication response data. You must include all content of the paResponse element - do not truncate this data.
<amount>
debitCreditIndicator
MandatoryIndicates that the amount is positive (“credit").
<paymentMethodDetail>MandatoryReturns the obfuscated card number and the card type. You can also enable the return of the card <expiryDate>. Contact us to enable these.
<ISO8583ReturnCode>OptionalThe authorisation response code. Returned for the status of CANCELLED (by RMM), REFERRED or REFUSED. Described inUseful tables.
<CVCResultCode>
description
OptionalThe meaning of the results are described inCVV/CVC response codes.
<AVSResultCode>
description
OptionalThe meaning of the results are described inAVS response codes
<AAVAddressResultCode>
description
OptionalThe meaning of the results are described inConfigure your system to receive AAV data.
<AAVPostcodeResultCode>
description
OptionalThe meaning of the results are described inConfigure your system to receive AAV data.
<AAVCardholderNameResultCode>
description
OptionalThe meaning of the results are described inConfigure your system to receive AAV data.
<AAVTelephoneResultCode>
description
OptionalThe meaning of the results are described inConfigure your system to receive AAV data.
<AAVEmailResultCode>
description
OptionalThe meaning of the results are described inConfigure your system to receive AAV data.
<ThreeDSecureResult>
description
MandatoryThe result of the 3DS check. Note: Usethis sectionto understand which types of description entitle you to liability shift.
<eci>OptionalElectronic Commerce Indicator. Checked, but not returned by default. Contact us to see these values.
<cavv>OptionalCardholder Authentication Verification Value. Checked, but not returned by default. Contact us to see these values.
<riskScore>
value
OptionalShows the score that the Worldpay fraud detection service assigned to the authorisation request, if you have it.