Select Junior Callback Frequently Asked Questions (FAQs)

Introduction

This document covers all aspects of the callback facility for the Select Junior method of Integration with WorldPay, as illustrated on http://support.worldpay.com/products_services/services/callbacks.html. For further details please select one of the subject areas listed below:

Common Questions
Setting up
Configuration at WorldPay
Security & Fraud
Customisation
FuturePay
Debugging

If you have a question which is not covered please contact your local Technical Support Team for further assistance. Your feedback will be used to enhance future versions of this document.

Common Questions

Can I use callback to redirect shoppers back to my web site?
What are Callback suspended?, Callback Failure Alert email address, Attach callback data to failure email? and Callback failure count?
I have received a Callback Failure Alert from WorldPay email; what does this mean?
I have received a payment confirmation email from WorldPay; why does my web site have no order details?

Setting Up

What is callback?
What does WorldPay send in a callback?
How can I send extra information to WorldPay for it to be returned in a callback?
What should I check for in a callback?
What should I be aware of when using callback?
Are there any language-specific issues I should be aware of?
Can I use callback to redirect shoppers back to my web site?

Configuration at WorldPay

How can I configure WorldPay to use callback for an installation ID?
How can I have callback data returned in a URL query string?
Can I have more than one callback URL per installation ID?

Security & Fraud

How can I validate a callback?
How can I use pre-authorisation with callback?

Customisation

What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?
I see the WorldPay banner at the top of the page; how can I either move or remove it?
Why, after a transaction is authorised and/or cancelled, do I see a "Not found" message?

FuturePay

How can I use callback with FuturePay?
How can I use dynamic callback with FuturePay?
How can I test FuturePay callbacks?

Debugging

What are Callback suspended?, Callback Failure Alert email address, Attach callback data to failure email? and Callback failure count?
I am developing a callback script; how can I debug it?
I have received a Callback Failure Alert from WorldPay email; what does this mean?
What can I do to ensure I have the callback data if a callback fails?
I have received a payment confirmation email from WorldPay; why does my web site have no order details?

What is callback?
Once a shopping cart or web site has sent the purchase details through to WorldPay, callback is the facility offered to inform the site about what happened on the WorldPay Payment Gateway. The callback will occur in the following circumstances:

Either the shopper selects Make Payment (and the card is accepted)
Or the shopper selects Cancel Purchase

It is important to note that callback is not a redirection from WorldPay to your web site, although a callback can generate a custom "thank you" or "no thank you" page for display to the shopper. For more details on this please see What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?

All forms of automatic redirection after a payment is authorised or cancelled are prohibited.

What does WorldPay send in a callback?
All the WorldPay-specific details sent covering an immediate payment, together with any variables whose name is prefixed with M_, MC_ or CM_ will be included. In addition, any variables generated because of the transaction (or cancellation) are included, and a variable provided to determine under which circumstance the callback occurred.

Any variables sent through whose names are prefixed MC_, CM_, or C_ will be available to the result page you wish to display for a successful or cancelled transaction. Note that no M_ variables submitted to WorldPay will be available.

Using the example Select Junior purchase token below:


<form action="https://select.worldpay.com/wcc/purchase" method="post">

<input type="hidden" name="desc" value="Test Item">

<input type="hidden" name="cartId" value="Test Item">

<input type="hidden" name="testMode" value="100">

<input type="hidden" name="instId" value="38290">

<input type="hidden" name="currency" value="GBP">

<input type="hidden" name="amount" value="14.99">

<input type="hidden" name="name" value="WorldPay Test Name">

<input type="hidden" name="address" value="Test Road
Test Town
Test City">

<input type="hidden" name="postcode" value="AB1 2CD">

<input type="hidden" name="country" value="GB">

<input type="hidden" name="tel" value="0123 456789012">

<input type="hidden" name="fax" value="01234 5678901">

<input type="hidden" name="email" value="demo@uk.worldpay.com">

<input type="hidden" name="lang" value="en">

<input type="hidden" name="fixContact">

<input type="hidden" name="subst" value="yes">

<input type="hidden" name="C_return" value="welcome back">

<input type="hidden" name="M_var1" value="fred">

<input type="hidden" name="MC_log" value="2379">

<input type="submit" value="Purchase this item using WorldPay">

</form>

...and the following test card details:

Visa Card Number: 4000 0000 0000 0002
Expiry Date: Within seven years from the purchase token reaching WorldPay.
Security Code: 123

Below is an example of the raw data returned in the HTTP POST to the callback script you have specified on the WorldPay Customer Management System for this installation, for an authorised and a cancelled transaction respectively:

Authorised transaction:: instId=38290&email=demo%40uk.worldpay.com&transTime=999178402000&country=GB&rawAuthCode=A&amount=14.99&installation=38290&tel=0123+456789012&address=Test+Road%0D%0ATest+Town%0D%0ATest+City&MC_log=2379&rawAuthMessage=authorised+(testMode+always+Yes)&authAmount=23.11&amountString=%26%23163%3B14.99&cardType=Visa&AVS=0001&cost=14.99&currency=GBP&testMode=100&authAmountString=EUR23.11&fax=01234+5678901&lang=en&transStatus=Y&compName=Company+Name&authCurrency=EUR&postcode=AB1+2CD&authCost=23.11&desc=Test+Item&countryMatch=S&cartId=Test+Item&transId=12227758&M_var1=fred&authMode=E&countryString=United+Kingdom&name=WorldPay+Test
Cancelled transaction:: instId=38290&email=demo%40uk.worldpay.com&country=GB&amount=14.99&installation=38290&tel=0123+456789012&address=Test+Road%0D%0ATest+Town%0D%0ATest+City&MC_log=2379&amountString=%26%23163%3B14.99&cost=14.99&currency=GBP&testMode=100&fax=01234+5678901&transStatus=C&compName=Company+Name&postcode=AB1+2CD&desc=Test+Item&cartId=Test+Item&M_var1=fred&authMode=A&countryString=United+Kingdom&name=WorldPay+Test

How can I send extra information to WorldPay for it to be returned in a callback?
If you would like to send extra information to WorldPay which is to be processed by your callback script, you will need to ensure that the variables have names prefixed with either M_, MC_ or CM_.

E.g. A variable you are using called myVariable should be sent as one of the following:

M_myVariable
MC_myVariable
CM_myVariable

...and will be returned in the callback with the same name and value.

Please note the following:

If your extra variables are not submitted to WorldPay using this naming convention, they will not reach your callback script.
If your extra variables are not submitted in the purchase token but instead collected by using customised versions of paymentTopFields.html, paymentMiddleFields.html or paymentBottomFields.html, they are not returned if Cancel Purchase is selected.
WorldPay does not store these variables after the callback: if you do not collect them they will be lost.
Do not send multiple occurrences of the same variable name to WorldPay; all bar one will be discarded.
If your site currently uses multiple occurrences of the same variable name, e.g. MC_name, it is suggested you do one of the following:
- Use MC_name1, MC_name2, MC_name3, etc...
- Use MC_name with a value which is the concatenation of all the intended values, separated by a character (or sequence of characters) which are never used by the values; e.g. value1|value2|value3 or value1_&_value2_&_value3. This can subsequently be processed within your callback script to extract the original values.
- Do not send the information to WorldPay but instead store it on your systems prior to submitting the purchase token to WorldPay, using the cartId as the key for later retrieval in the callback.

It is for these reasons we recommend you store these details before the purchase token is submitted to WorldPay, associating them with a unique value which can be sent to WorldPay as the cartId. This value, which is stored by WorldPay, can then be used by your callback script to re-associate the callback with the stored information.

What should I check for in a callback?
You should at least check the following when using callback:

To determine whether the transaction was authorised or cancelled, you should test for the value of the transStatus variable; this will be Y or C respectively. Only after this check should your script proceed.
You must not rely upon the presence or absence of transId alone. This variable will also be present if the shopper has submitted a declined transaction before selecting Cancel Purchase.
If the transaction was authorised you should test for the value of the testMode variable; if it is either not present or set to the value 0 the callback was for a live transaction.

What should I be aware of when using callback?
Please note the following when using callback:

The callback URL must not point to a static HTML document (i.e. ending in .html). If you only intend to present a customised "thank you" or "no thank you" page to shoppers after a transaction has been authorised or cancelled do not use a Callback URL, but instead use customised versions of resultY.html and resultC.html uploaded to your installation ID on the WorldPay Customer Management System.
The callback URL should not point to a file uploaded to your installation ID on the WorldPay Customer Management System.
The callback is sent as an HTTP POST. If you can only accept the variables returned to you in the query string of a URL please see How can I have callback data returned in a URL query string?
The callback data is not visible to the shopper for editing.
Callbacks to https:// URLs fail if the server hosting the callback script only supports SSL 2.0.
The callback URL must start with either http:// or https://.
There are two variables returned in the query string by default, appended to the callback URL. In the above example this is added as:
?msgType=authResult&installation=38290
The authAmount and authCurrency show what the shopper selected from the Choose Currency menu on the WorldPay Payment Page.
The deprecated variables cost and authCost are duplicates of amount and authAmount respectively. This should be interpreted as "do not use cost or authCost in your callback script; they may be withdrawn at any time and without notice".
For more details on decoding the AVS response please see http://support.worldpay.com/kb/user_guides/cms/help/appendix/cms_6130.html
The value of rawAuthMessage returned can be interpreted using the table below:

Make Payment (test) cardbe.msg.testSuccess

Make Payment (live) cardbe.msg.authorised

Cancel Purchase (test or live) trans.cancelled
countryMatch is replicated within the AVS result. For more details on both, please see http://support.worldpay.com/kb/integration_guides/junior/integration/help/appendicies/sjig_10100.html.
The value of transTime is the number of milliseconds since 00:00:00 GMT January 1st 1970 when the transaction was made.
Possible values of cardType include:
Please note you may not be able to accept all of these. If you wish to confirm or change the card types you can accept please contact our Customer Acceptance department, applications@worldpay.com.
cardType should not be confused with the possible values of the optional purchase token variable paymentType used to bypass the Dispatcher Page. Please contact your local Technical Support Team for more information.
If using the withDelivery parameter, the callback includes the Delivery Name, Address and Postcode as delvName, delvAddress and delvPostcode. The Delivery Country will be returned as both the two-letter country code (delvCountry), and as it was displayed to the shopper on the WorldPay Payment Page (delvCountryString).
If you use withDelivery and pre-populate at least delvAddress and delvCountry, you will get all of the Delivery Details variables returned in callback, even if the shopper selects Cancel Purchase. If transStatus is C then the values returned will only be the ones originally submitted in the purchase token, otherwise they will be the ones specified when Make Payment was selected.
The value of ipAddress is the IP address from which the shopper has submitted a payment request to WorldPay.
The following are not returned in callback:
- signature and signatureFields. Note this only applies if you are using the MD5 option with Select Junior (see http://support.worldpay.com/kb/integration_guides/junior/integration/help/tech_notes/sjig_tn_009.html).
- The optional parameters AuthValidFrom and AuthValidTo.
- C_ variables; these are only available for display to the shopper using wpdisplay tags.
- Any optional WorldPay variables used to control the appearance of the payment page, e.g. fixContact and subst.
Variables with a name including the "-" character are returned in the callback but will not be available for use in customised payment confirmation emails. Additionally you may have difficulty in using such variables within your callback script so their use is not recommended. This has no impact on the values of the callback variables.
Please ensure that your callback script is able to complete quickly; WorldPay will wait for 30 seconds to initially connect, and up to 2 minutes or until the script has completed, whichever is sooner, before displaying any output to the shopper. If these conditions cannot be met, WorldPay will send a Callback Failure Alert from WorldPay email. Please see I have received a Callback Failure Alert from WorldPay email; what does this mean? for more information.
If you are using sessions to preserve order details before the shopper submits the purchase token to WorldPay, your session will be abandoned and may expire, losing all session data before the callback script is triggered. To resolve this, you should store everything the callback script requires about that session before the shopper reaches the WorldPay Payment Gateway; either by using additional M_, MC_ or CM_ variables in the purchase token, or using a database. The latter (preferred) option means you would only need to send one variable, e.g. cartId to refer to that stored session in your callback script. However you choose to do this, there must be a way to uniquely associate the session on your server with the result from WorldPay.
Whatever the shopper enters as the Cardholder's Name on the Payment Pages will be returned as the value of name, regardless of what is sent in the original purchase token.

The "Content-Type:" header sent by WorldPay to your callback script includes the parameter suffix "; charset=ISO-8859-1", and is specified explicitly for future support of other non-English character sets, and may cause the callback script to be unable to interrogate the HTTP POST information.

The value of charset in the "Content-Type:" header may not always be ISO-8859-1. This is set by the message token lang.charset in the messages_xx.properties file used to display the payment page when the Make Payment button is selected, where xx will match the value of lang returned in the callback. If lang.charset is not present in the corresponding messages_xx.properties file uploaded to your installation then ISO-8859-1 will be used instead.

Fixes for various servers are listed below:

Cold Fusion

For your callback script please ensure you are using version 4.5.1 service Pack 2 or later, available from http://www.macromedia.com/support/coldfusion/downloads_updates.html

Cold Fusion MX

The following script is an example of how to obtain the HTTP POST information. Please note this is unsupported by WorldPay.

<cfset x = GetHttpRequestData()>
<cfset formData = StructNew()>
<cfloop list="#x.content#" delimiters="&" index="item">
	<cfset key = ListGetAt(item, 1, "=")>
	<cfif ListLen(item, "=") gt 1>
		<cfset value = URLDecode(ListGetAt(item, 2, "="))>
	<cfelse>
		<cfset value = "">
		</cfif>
	<cfset formData[key] = value>
	</cfloop>

Perl

Go to http://www.cpan.org/ and download and install "CGI.pm" from there (see http://search.cpan.org/dist/CGI.pm/). In most cases, this is a drop-in replacement for older libraries such as "cgi-lib.pl".

Microsoft IIS on Windows NT

Please ensure you are using Service Pack 6a, available from http://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/allSP6.asp

Sun ONE Active Server Pages (formerly Sun Chili!Soft ASP) or Microsoft ASP

The following script is an example of how to obtain the HTTP POST information without using Request.Form. Please note this is unsupported by WorldPay.

<%
Private Function BStr2UStr(BStr)
	'Byte string to Unicode string conversion
	Dim lngLoop
	BStr2UStr = ""
	For lngLoop = 1 to LenB(BStr)
		BStr2UStr = BStr2UStr & Chr(AscB(MidB(BStr,lngLoop,1)))
		Next
	End Function

Function HexToDec(HexValue)
	'Converts A Hex number into a Decimal value
	Const HexBase = "0123456789ABCDEF"
	Dim Sum, DigitCount, MultiBase, Index, HexDigit, RetVal, HexPosition
	Sum = 0
	DigitCount = 0
	MultiBase = 1
	For Index = LEN(HexValue) to 1 Step -1
		HexDigit = Mid(HexValue, Index, 1)
		HexPosition = InStr(1, HexBase, HexDigit)-1
		RetVal = RetVal + (HexPosition*MultiBase)
		MultiBase = MultiBase * 16
		Next
	HexToDec = RetVal
	End Function


Private Function URLDecode(Expression)
	Dim strSource, strTemp, strResult, lngPos, HexNumber, DecNumber
	strSource = Replace(Expression, "+", " ")
	For lngPos = 1 To Len(strSource)
		strTemp = Mid(strSource, lngPos, 1)
		If strTemp = "%" Then
			If lngPos + 2 < Len(strSource) Then
				HexNumber = (Mid(strSource, lngPos + 1, 2))
				DecNumber=HexToDec(HexNumber)
				strResult = strResult & Chr(DecNumber)
				lngPos = lngPos + 2
				End If
			Else
				strResult = strResult & strTemp
				End If
		Next
	URLDecode = strResult
	End Function

Function ReadPostData
	lngTotalBytes = Request.TotalBytes
	strBRequest = Request.BinaryRead(lngTotalBytes)
	TheForm=split(BStr2UStr(strBRequest), "&")
	Dim FormItems()
	Redim FormItems(UBound(TheForm,1), 2)
	For a=0 to UBound(TheForm,1)
		temp = split(TheForm(a), "=")
		If IsArray(temp) then
			FormItems(a,1) = URLDecode(temp(0))
			FormItems(a,2) = URLDecode(temp(1))
			Else
				FormItems(a,1) = URLDecode(temp)
				FormItems(a,2) = ""
				End If
		Next
	ReadPostData = FormItems
	End Function

Function FindArray(arrName,srcStr)
	Dim I, pint, result
	result = null
	pint = -1
	For I=0 to UBound(arrName)
		If pint < 0 Then
			If srcStr = arrName(I,1) Then
				pint = I
				result = arrName(I,2)
				End If
			End If
		Next
	FindArray = result
	End Function

Response.Write("<html><head><title>Transaction Result</title></head><body>")

' List of the variable names and values
Response.Write("<p>The HTTP POST of this callback contained:")
pd = ReadPostData
Response.Write("<table border="1"><tr><th>name</th><th>value</th></tr>")
For k = 1 to UBound(pd,1)
	Response.Write("<tr><td>" & pd(k,1) & "</td><td>" & pd(k,2)&"</td></tr>")
	Next
Response.Write("</table>")

' Example of how to use the returned data
Response.Write("<p>This ")
Select Case FindArray(pd,"testMode")
	Case "100","101"
		Response.Write("test")
	Case Else
		Response.Write("live")
	End Select
Response.Write(" transaction was ")
Select Case FindArray(pd,"transStatus")
	Case "Y"
		Response.Write("successful.")
	Case "C"
		Response.Write("cancelled.")
	Case Else
		Response.Write(FindArray(pd,"transStatus"))
	End Select

Response.Write("</p><wpdisplay item=banner></body></html>")

%>

Are there any language-specific issues I should be aware of?
While you may use any server side scripting language for your callback script, it is advised that you review the details below:

Microsoft .NET 1.1: You will need to disable a feature called Request Validation, at least for the callback script you are using. Please see http://www.asp.net/faq/requestvalidation.aspx for more information on how to disable this feature.
PHP: To examine the data sent in the HTTP POST, please see http://www.php.net/manual/reserved.variables.php#reserved.variables.post.

Can I use callback to redirect shoppers back to my web site?
No. All methods of automatic redirection are prohibited.

If you wish to present a custom page to shoppers after a transaction is authorised or cancelled, please see What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?.

How can I configure WorldPay to use callback for an installation ID?
You will initially need to log in to the WorldPay Customer Management System (via http://www.worldpay.com/admin). In the new window that opens you will need to scroll down to the section headed Installations and select the Configuration options button corresponding to the instId you are using.

The minimum settings you need to complete are:

Callback URL: This should be set to the complete address to your callback URL, hosted on your server.
Callback enabled?: This determines whether WorldPay will attempt to use the callback URL when needed.

In order to use callback you must selected at least these two settings.

If you have developed your callback script to output an HTML response and would like WorldPay to capture this for display to the shopper after the callback has completed successfully, you should also ensure Use callback response? is selected. For more information on this please see What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?.

To commit the changes you have made, select SAVE CHANGES at the bottom of the page.

How can I have callback data returned in a URL query string?
If you require WorldPay to return the variables in the query string you will need to modify your callback URL on the WorldPay Customer Management System as shown in the example below:

From: http://www.myserver.com/mycallbackscript.cgi
To: http://www.myserver.com/mycallbackscript.cgi?transStatus=<wpdisplay item=transStatus>&transaction=<wpdisplay item=transId>&reference=<wpdisplay item=cartId-urlenc>

In this example, for the authorised and cancelled transaction the URL would be converted to:

Authorised transaction:: http://www.myserver.com/mycallbackscript.cgi?msgType=authResult&installation=38290&transStatus=Y&transaction=12227758&reference=Test%20Item
Cancelled transaction:: http://www.myserver.com/mycallbackscript.cgi?msgType=authResult&installation=38290&transStatus=C&transaction=&reference=Test%20Item

Points to note:

This is often essential when using a session ID on your server. You will need to pass in the variable prefixed with M_, MC_ or CM_ so this can be included, e.g.
In the purchase token:
<input type="hidden" name="MC_session" value="abcdef123456">
(where abcdef123456 is replaced with the value of the session variable available to your script)
...and the callback URL on the WorldPay Customer Management System would be amended to:
http://www.myserver.com/mycallbackscript.cgi?visitor=<wpdisplay item=MC_session>
...assuming that the name of the variable preserving the session is called visitor.
Using HTTP POST is the preferred method of sending the details to the callback script.
The HTTP POST is still sent.
The above example callback URL uses the -urlenc modifier to the wpdisplay syntax. This encodes certain characters in such a way they can be correctly transmitted and decoded.
Whilst this could be used for every item= in the callback URL it is only necessary for those values which may potentially contain characters either less than ASCII 34 ("), greater than ASCII 122 (z), or in the following list:
!#$%^&()+=[]\`':;?@/<>
WorldPay strongly recommends using the -urlenc modifier for any field which contains shopper-entered data. Failure to do so could be exploited and result in your server being compromised.
Please see http://www.blooberry.com/indexdot/html/topics/urlencoding.htm for more information on URL encoding.
To turn off the insertion of msgType and installation within the callback query string, contact WorldPay Technical Support (quoting the installation ID) to request Use literal callback? is enabled.

Can I have more than one callback URL per installation ID?
Using a feature known as Dynamic Callback, it is possible to change the callback URL every single time a purchase token is sent through to WorldPay.

Using dynamic callback as described below should be regarded a security issue, as the purchase token largely reveals how to spoof a callback without the shopper actually paying. It is recommended that your callback script validates all the data returned to check that the callback actually was from WorldPay (even if this means examining and storing variables you would not otherwise need), contains only the data you would expect, and has not already been processed by your script.

To implement this, you will need to include a variable within your purchase token, prefixed with either M_, MC_ or CM_, e.g.:

<input type="hidden" name="MC_callback" value="http://www.myserver.com/mycallbackscript.cgi">

Query strings and wpdisplay tags can also be included, if required.

Finally, on the Customer Management System, you will need to set your Callback URL to include the name of the variable using wpdisplay, e.g.:

<wpdisplay item=MC_callback>

If you use nested wpdisplay tags in this manner, you should use a callback URL of the form <wpdisplay item=MC_callback-reparse>

Adding a query string (or extending one included within the value of the callback variable) can be used, and additional wpdisplay tags are also permitted.

You could still trigger a callback to a default or backup server, even if the variable is undefined. This is particularly useful if for example, you wish to test a new callback script you are developing; you can use the variable value to specify the location of your test script, and the wpdisplay empty to use your existing script (thus allowing transactions to continue as normal during your development). Instead of logging in to the WorldPay Customer Management System each time you need to change the Callback URL, simply change the reference in your script sending the purchase token to WorldPay.

An example of such a Callback URL could be:

<wpdisplay item=MC_callback-ppe empty="http://www.myserver.com/callback.cgi">

If you use nested wpdisplay tags in this manner, you should use a callback URL of the form <wpdisplay item=MC_callback-ppe-reparse empty="http://www.myserver.com/callback.cgi">

If you are using FuturePay with this technique (i.e. you have also enabled FuturePay callback Enabled? (Requires standard Callback enabled)), please see How can I use dynamic callback with FuturePay?

How can I validate a callback?
It is advised to use at least some of the following checks:

callbackPW is returned if you have set a Callback password for your installation on the WorldPay Customer Management System. As the value of this is only known to this and your callback script it can be used as a basic security check within your script.
All whitespace is trimmed from the beginning and end of the Callback password before it is returned as the value of callbackPW
If you are using unique values of cartId, you should check that you have not already received a callback with this.
Although WorldPay cannot provide you with the IP addresses used for callback, you should check that the address used resolves to a .worldpay.com one, and that this host name resolves to the same IP address.
This process may take longer than the time we wait for the callback to complete successfully. It is advised that the IP address is recorded as part of the callback script functionality, but checked as part of a separate process before goods or services are provided.
If you wish to use a username and password to authenticate access to your callback script you would need to use a callback URL of the form:
http://<username>:<password>@www.myserver.com/myscript.cgi

If the username is abc and the password 123 the callback URL would look like:

http://abc:123@www.myserver.com/myscript.cgi
If WorldAlert has indicated that the authorised transaction should be investigated further a parameter wafMerchMessage will be returned with the value of either waf.warning or waf.caution. See http://support.worldpay.com/fraud/ for more details on WorldAlert.
If WorldPay has enabled your installation ID for use with Verified by Visa and/or MasterCard SecureCode, you will receive a parameter for live authorised transactions called authentication. This will have a value of ARespH.card.authentication.X, where X is 0, 1, 7 or 6. Please see http://support.worldpay.com/kb/user_guides/authentication/managing_your_transactions/auth_managing_results.htm for more details.
The AVS result can help you determine if the authorised transaction should be either investigated further or even rejected (i.e. refunded or not post-authorised, depending on whether you are using immediate or pre-authorisation). For more details on interpreting this information please see http://support.worldpay.com/kb/user_guides/cms/help/appendix/cms_6130.html.
If your web site is using a database and unique values of cartId or a session variable, these could be used to associate the callback with the stored details of the potential order before it was submitted to the WorldPay Payment Gateway. Please see http://support.worldpay.com/kb/reference/faqs/purchase_token_security.html#duplicate for more details.

Please do not ask for WorldPay IP addresses or attempt to base any security measures upon addresses you may derive. This information may change at any time without prior warning or subsequent notification, and WorldPay are not responsible for any issues resulting from such action.

How can I use pre-authorisation with callback?
The callback process is identical regardless of whether you are using pre-authorisation or immediate authorisation. The only differences is that authMode would come back with the value of E (for pre-authorisation) instead of A (for immediate authorisation).

If you are using pre-authorisation you may wish to interrogate the callback information to determine whether the transaction should be post-authorised or not. You could implement a rules-based system to examine the AVS (and possibly the cartId) to determine the validity of the transaction. Please see http://support.worldpay.com/kb/user_guides/cms/help/appendix/cms_6130.html for more details on interpreting AVS.

It is possible to post-authorise transactions either via the WorldPay Customer Management System, or remotely. For more details on how to remotely post-authorise transactions please see http://support.worldpay.com/kb/reference/faqs/remote_postauth_and_refunds.html.

What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?
Please note the following:

Variables whose names are prefixed with either C_, MC_ or CM_ are available for use in the payment response page displayed to shoppers.
If customising the resultY.html and resultC.html doesn't offer you enough flexibility, you can use your callback script to generate the response. WorldPay will capture the response and check that the following WorldPay-specific tag is present:
<wpdisplay item=banner>
If you include this in the output of your callback then it will be replaced by the WorldPay receipt banner where you specify.
For WorldPay to use the output of your callback script you will need to ensure that Use callback response? is selected for your installation on the WorldPay Customer Management System, in addition to the fully specified Callback URL and Callback enabled?. There are several things to consider when using this facility:
- Any output generated by your script - unless the script fails and your server reports an error - will be considered output to display to the shopper.
- If you are preserving details via a cookie please note that the callback script creating the callback response will not be able to read the cookie on the shoppers' browser (e.g. for writing details to the page or to a database).
- If your script generates no output or WorldPay are unable to collect any output from your script, the resultY.html or resultC.html file uploaded to your installation ID will be displayed instead. If no resultY.html or resultC.html can be found for your installation ID then central default versions will be used.
- The HTML output generated by your script will be presented to the shoppers' browser as if it had come from a WorldPay server. As such, any images (or other resources, e.g. JavaScript .js or Cascading Style Sheet .css files), you wish to use will need to be uploaded to your installation on the WorldPay Customer Management System and referred to within the output of your script prefixed with /i/xxxxx/, e.g.:
  <img src="/i/xxxxx/imagename.gif">
  ...where xxxxx is your WorldPay installation ID. Note you could replace the xxxxx with <wpdisplay item=instId> and WorldPay will replace this with the correct installation ID before the response is displayed to the shopper.
  Instead of using <img src="/i/<wpdisplay item=instId>/imagename.gif"> you could use the following:
  <img src="<wpdisplay item=instId pre="/i/" post="/">imagename.gif">
- Any a href links included in the output, for example back to your web site, must be absolute links.
- All types of automatic redirection are prohibited as they could prevent the shopper from seeing the WorldPay receipt banner.
- Attempting to redirect the shopper to another page by rewriting the Location: header in your callback script is prohibited and will fail. For more details please see I have received a Callback Failure Alert from WorldPay email; what does this mean?. If you require a callback script to pass parameters to a secondary script (and optionally capture the output from it), this is language-dependant and beyond the scope of this document.
- To ensure that the character encoding used in your callback response is displayed correctly by the shopper's browser, you should include an appropriate meta tag in the head of your output. Please visit http://www.w3.org/TR/REC-html40/charset.html for more information.
  If your callback response is also referencing an external stylesheet, you should also specify the encoding as detailed in http://www.i18nguy.com/markup/serving.html#tip02.
  
  If your callback response does not explicitly state the character encoding used, the final page displayed to the shopper may be displayed incorrectly or unreadable.

I see the WorldPay banner at the top of the page; how can I either move or remove it?
To place the WorldPay receipt banner at a specified location on the page you will need to ensure that your callback script outputs the following WorldPay-specific tag:

<wpdisplay item=banner>

Please note that this banner must be displayed; removal is not an option.

For more details please see What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?.

Why, after a transaction is authorised and/or cancelled, do I see a "Not found" message?
You are incorrectly using a method of redirection to send the shopper to another location in either your callback response or customised version of resultY.html or resultC.html. Please note that all types of automatic redirection are prohibited as they could prevent the shopper from seeing the WorldPay receipt banner.

How can I use callback with FuturePay?
If the installation ID you are using is enabled for FuturePay you can also receive FuturePay callbacks to the callback URL as detailed on http://support.worldpay.com/kb/product_guides/futurepay/fpg-tn-001.html

Points to note:

FuturePay callbacks are for informing the merchant only; do not generate a callback response.
FuturePay callbacks will only be sent to the Callback URL set up for the instId used when the FuturePay Agreement was originally established, regardless of how the Agreement is subsequently controlled.
None of the M_, MC_ or CM_ variables which may have been submitted in the original purchase token are returned in a FuturePay callback as they are not stored by WorldPay.
The absence of a M_, MC_ or CM_ variable could be used as quick way of determining if the callback is a FuturePay one.

Only after determining the type of callback received by your script can you check for futurePayId to determine which FuturePay Agreement it refers to.

FuturePay cancellation?

futurePayStatusChange will be present and set to either Merchant Cancelled or Customer Cancelled if the merchant or the shopper cancelled it respectively.

FuturePay debit authorisation attempt?

desc will include the word FuturePay as well as the payment number and FuturePay Agreement ID. To determine whether the payment was successful or not, transStatus will be set to Y or N. Note that if an authorisation cannot be attempted, no callback will be made. If transStatus is Y, you should check other variables in the callback to verify that the FuturePay Agreement has not been altered for potentially fraudulent purposes.

FuturePay Agreement created?

Only after eliminating all callback types can you check transStatus to see whether it is Y or C as normal. If transStatus is C then futurePayId will not be present. Additionally, please note the following:

No FuturePay variables other than futurePayId are returned in the callback.

If a FuturePay agreement has been set up yet the purchase token did not contain an amount (or an amount of 0), the table below shows how certain parameters are returned to your script.

transId Not returned

rawAuthCode A

rawAuthMessage trans.fpCreatedNoAuth

AVS 0000

countryMatch B for a live transaction, S for a test one.

authCost & authAmount empty value

authAmountString empty value

If you are remotely administering FuturePay Agreements without logging in to the WorldPay Customer Management System (as detailed on http://support.worldpay.com/kb/reference/faqs/remote_futurepay.html), then whilst FuturePay callbacks may be disregarded the ones for a successful authorisation are still useful for your own fraud screening. In all instances where you initiate the remote request you should process the response returned to your script.
For successfully authorised transactions you may wish to record the transTime value against the futurePayId. If you know the payment structure of the FuturePay Agreement you could calculate by which time the next debit is due; for FuturePay Regular you could do this roughly by adding one payment interval (or start interval) plus four days, rounding down to 00:00:00 GMT. If you have not received a callback by this time then you could either automatically cancel the Agreement, or suspend their access to your service until you receive either a successful payment or cancellation for this futurePayId.
For more details please see http://support.worldpay.com/kb/reference/faqs/remote_futurepay.html#fp_time.

How can I use dynamic callback with FuturePay?
If you would like to use one callback URL for the initial authorisation or cancellation and a different one for all the FuturePay callbacks you'll need to use the Dynamic callback feature; the one defined by MC_callback will be used in the first instance, the EMPTY one for all FuturePay callbacks.

If you specify a Dynamic callback URL for your installation ID and enable FuturePay callback Enabled? (Requires standard Callback enabled), yet do not specify a default address in this way; you will not receive FuturePay callbacks.

If you wanted to use different scripts for each type of callback, you could use something like the following:
<wpdisplay item=MC_callback-ppe empty="<wpdisplay item=rawAuthCode-ppe pre='http://www.myserver.com/fppayment.cgi?' empty='http://www.myserver.com/fpcancel.cgi'>">
In this example:

The value of MC_callback is used after the shopper selects Make Payment or Cancel Purchase. This variable must be sent in the purchase token, otherwise http://www.myserver.com/fppayment.cgi will always be called. If this condition fails then it must be for a FuturePay callback.

If rawAuthCode is available, it is a FuturePay authorisation attempt and http://www.myserver.com/fppayment.cgi will be used.

If both conditions fail then it must be for a cancellation, so http://www.myserver.com/fpcancel.cgi will be used instead.

How can I test FuturePay callbacks?
You can take advantage of the fact that such callbacks do not differ based upon the value of futurePayType used to set up the FuturePay Agreement. Simply create a FuturePay Limited Agreement with an option of 0 (and no other FuturePay parameters), then debit from the resultant FuturePay Agreement (or cancel it) via the WorldPay Customer Management System.

If you would like to test a FuturePay callback script to see how it operates when a payment is declined you will need to set up a purchase token with no amount (or an amount of 0), and a testMode of 101.

What are Callback suspended?, Callback Failure Alert email address, Attach callback data to failure email? and Callback failure count?
Please see the explanations below. If your web site relies upon the callback working it is down to you to ensure this is resolved as quickly as possible.

Callback suspended?

If your callback fails 200 times in succession (i.e. Callback failure count reaches 200), WorldPay will stop sending callbacks. When you have fixed the problem, you can clear the Callback suspended? box and callbacks will resume. If the next callback is successful, the Callback failure count will be reset to 0.

The above paragraph should be interpreted as "you must ensure both that your callback script is functioning correctly at all times, and that whenever a Callback Failure Alert from WorldPay email is received it is acted upon as quickly as possible to ensure no further order information is lost."

It is highly recommended that you do the following:

Customise the merchant copy of the payment confirmation email WorldPay sends to you after every successfully authorised transaction so that you have a backup of the information and can recover manually. Details on how to do this can be obtained from your local Technical Support Team.
Store as much as you can about the potential order prior before the shopper can submit the purchase token to WorldPay. This allows you also to determine which orders are abandoned, as well as those which result in authorised or cancelled transactions.
Limit the information you send through to WorldPay to uniquely identify the purchase to the cartId; this is included in the payment confirmation emails as well as the Callback Failure Alert from WorldPay.
Enable both Callback Failure Alert email address and Attach callback data to failure email? for your installation ID, described below.

Callback Failure Alert email address

If a callback has not completed successfully then an email indicating this will be sent to the address specified here. For more information please see I have received a Callback Failure Alert from WorldPay email; what does this mean?

Attach callback data to failure email?

If you are using Callback Failure Alert email address then it is possible for WorldPay to send additional diagnostic information to you when a callback fails. For more details please see http://support.worldpay.com/kb/internal/release/Release_0416/RelGd/octo4rel_1300.htm.

Callback failure count

This indicates the number of times the callback has failed since it last completed successfully.

I am developing a callback script; how can I debug it?
There is an option currently available, allowing you to examine what is returned in the HTTP POST of data.

Please note that this is not supported by WorldPay and may become unavailable at any time. It should not be relied upon as a method of obtaining callback information, particularly in a live environment.

If you would like this detail emailed to you, use the callback URL http://www.worldpay.com/cgi-bin/select_callback.pl and include the following lines within your Select Junior form:

<input type="hidden" name="M_recipient" value="AAAAA"> <input type="hidden" name="M_email" value="BBBBB"> <input type="hidden" name="M_subject" value="Callback report">

The resultant email, sent immediately after the transaction has been authorised or cancelled, will be sent to the address AAAAA (i.e. your email address), with the subject set to Callback report. Optionally you can include the M_email reference such that the email generated will appear to have come from address BBBBB.

I have received a Callback Failure Alert from WorldPay email; what does this mean?
WorldPay will send an email entitled Callback Failure Alert from WorldPay if the callback process did not complete 100% successfully.

Each one of these emails will include the Transaction ID, Cart ID, Installation ID and Error reported.

If Attach callback data to failure email? is enabled for your installation ID, you can receive full diagnostic information.

Note that if no Transaction ID is included, no authorisation took place because either the shopper selected Cancel Purchase on the WorldPay Payment Page or, if you also have FuturePay callback Enabled? (Requires standard Callback enabled) enabled, a FuturePay cancellation.

If the error information detailed below to explain the Error reported is not enough to resolve the problem, you can email your local Technical Support Team and, where possible, we can provide you a full log of the data sent and the response returned to WorldPay.
To ensure we can provide you the logs as quickly as possible we must have a complete copy of the email including all headers - including those which may be hidden by your email software. The easiest way to achieve this is to send the email itself as an attachment.
Requested callback logs cannot be provided until the day after the callback occurred, so it is recommended that you enable Attach callback data to failure email? to ensure you receive the information immediately.

If you have enabled callbacks the Callback URL you have entered must be correct and your server must be working properly and sending back an appropriate response. If there is any problem with the callback process you will receive an email describing the fault.

If you have selected the Use callback response? option, please note that any callback failure listed below will cause the response to be discarded even if it looks like HTML. WorldPay will instead display the resultY.html or resultC.html file depending on whether the transaction was authorised or cancelled; if you have not uploaded your own version of these files a default version will be used.

Below is a summary of key text phrases that can be included in Callback Failure Alert from WorldPay emails. Click on the one you have received for a brief explanation of the possible cause.

A non-empty path is required A value is required

These two are caused because the full callback URL cannot be determined. This may be because you are using a dynamic Callback URL of the form http://<wpdisplay item=MC_callback> but not specifying the value of MC_callback in your purchase token. Alternatively, the Callback URL is set to <wpdisplay item=MC_callback> but MC_callback is specified in your purchase token as simply http://.

Please see Can I have more than one callback URL per installation ID? for more information.

Broken pipe Cannot create output stream Socket closed

These all mean the same thing: the connection to the callback server has been broken mid-stream. This may be due to a timeout expiring, or an actual server failure.

Callback suspended due to previous failure

There is a serious problem with your Callback URL as it has not responsed successfully after 200 attempts. WorldPay will not longer send callbacks to Callback URL until after you have unticked the option Callback suspended?

Callback obtained HTTP '301' response Callback obtained HTTP '302' response

The requested resource has moved to a new URL as specified in the returned Location: header. Redirection is not permitted. Please see What should I be aware of if I wish to display a customised page to shoppers as a response to a callback? for more information.

Callback obtained HTTP '400' response

The server did not understand the request. An improperly typed callback URL is usually the cause.

Alternatively, your server may not accept the "Content-Type:" header sent by WorldPay. Please see What should I be aware of when using callback? for more information.

Please note the following, particularly if you are using a Lotus Domino web server:

This may be caused because you are using <wpdisplay item> syntax as part of the Callback URL, and your web server is only permitting correctly formatted URLs to be used. To resolve this issue please either see How can I have callback data returned in a URL query string?, or do not include data in the query string and use Request_Content instead of Query_String_Decoded.

Callback obtained HTTP '401' response

The most likely cause is you are (or should be) using a callback URL of the form http://username:password@server/script.cgi and the username, password or both are wrong. Alternatively, you are using Oracle WebDB listener and your callback script is failing to log in to a database successfully.

Callback obtained HTTP '403' response

Usually this means either the merchant server is configured to refuse connections from our IP address range, or the URL is slightly wrong (perhaps too many or too few characters).

Callback obtained HTTP '404' response

Your callback URL does not exist at the location specified. Please check that the callback URL is correct and that the script is present in the intended location.

Callback obtained HTTP '405' response

You may be attempting to run a script that is not supported. Some Internet Service Providers do not allow scripts on their servers, which could result in this status code. This will also be generated if you are attempting to use a callback script which has been uploaded to your installation ID on the WorldPay Customer Management System.

Callback obtained HTTP '500' response

Your callback URL could be contacted but the script failed to complete successfully. This generic error is often the result of an error within the callback script or it returning improperly formatted headers.

One reason could be that your callback script is unable to collect values from the data submitted to it unless the variable names are of the correct case. For example, instead of looking for transStatus, your script could be erroneously using transstatus.

If you are using Microsoft .NET for your callback script, you may receive this because Request Validation is objecting to the values of amountString and authAmountString. Please see http://www.asp.net/faq/requestvalidation.aspx for more information on how to disable this feature.

Callback obtained HTTP '501' response

The callback has requested the server to do something it cannot. The server in question may need upgrading.

Callback obtained HTTP '502' response

The callback script contacted for a response had to contact another server to obtain it. The callback script received the error from the other server.

Callback obtained HTTP '503' response

The server hosting your callback script is over tasked and it cannot process your request. The server may be down for maintenance, or there may just be too many users currently on the site.

Callback obtained HTTP '504' response

Our connection to the server hosting the callback script was broken. There are several possible reasons for this. The most likely is that our connection was inactive longer than allowed (the time limit will usually be set by your ISP). It could also be a server or network problem.

Callback obtained HTTP '506' - '599' response

This is a user-defined error message, possibly useful for testing purposes but should be disabled before being deployed in a live environment.

Cannot send requests to relative URLs

Your callback URL is of the form directory/script.cgi. Please check that your callback URL begins with http://server or https://server as required.

Destination address is prohibited

Your callback URL is not permitted to be on a WorldPay server.

Failed to do merchant HTTP request. Check that you have the correct URL and that the merchant server is up and running.

This will be accompanied by one of the following messages:

Connection refused: Either the server cannot handle any more connections at the time the callback was attempted, or the server is no longer running.
Connection reset by peer: An existing connection was forcibly closed by the remote host. This normally results if the callback script on the remote host is suddenly stopped, the host is rebooted, the host or remote network interface is disabled, or the remote host uses a hard close. This error may also result if a connection was broken due to keep-alive activity detecting a failure while one or more operations are in progress.
java.net.UnknownHostException: www.myserver.com: WorldPay was unable to find a DNS entry for www.myserver.com
It is possible that this error may be caused by a type of DNS misconfiguration called "lame delegation". For more details of this and how it can be stopped please see http://www.faqs.org/rfcs/rfc1713.html.
javax.net.ssl.SSLException: Unrecognized SSL handshake: This could be because the clock on the server hosting your callback script is set incorrectly.
No route to host: WorldPay is unable to determine how to reach the server your callback URL is hosted on. Please contact whoever is in charge of the server you are using for more information.
Read timed out: WorldPay has been unable to capture any of the intended output of the callback script (including server headers), usually because the merchant server took too long to respond. WorldPay will wait for up to two minutes for the response.
This has been occasionally encountered where a callback URL is using https:. If this applies to your callback then please switch to http:.
If you are using ArrowPoint Cookies in conjunction with a Cisco Content Service Switch (CSS) 11000, please see http://www.cisco.com/warp/public/117/AP_cookies.html#httppost for more information.
Timed socket connection failure - took more than 30000ms: WorldPay was unable to reach your callback script within 30 seconds. Specifically, this is a failure to establish the connection in the first place. The most common reason is a firewall dropping our request. It is similar to "Connection refused", but less polite.

For input string: ""

You have specified a : in your callback URL but have not included the port number.

invalid HTTP status line returned

The callback script is not returning a suitable status header, i.e. 200 OK. This is typically because the script has crashed completely, or because a "no-parsed-headers" script returned invalid syntax for the first line.

Although rare, it is also possible that this can be reported if the steps listed below cannot be completed successfully:

Look up the Callback URL hostname A to get IP address(es) (possibly via one or more CNAME aliases) and choose one at random - B.

Look up address B to get hostname C.

If C is null (ie. the lookup in (2) fails), allow anyway.

Look up hostname C to get IP address(es) D.

If D is null, fail.

If B is one of the addresses in D, allow.
Else fail.

Invalid port number

The callback URL is not a valid URL. Please ensure you have entered it correctly on the WorldPay Customer Management System.

Null or zero length URL

You have selected Callback enabled? but have not specified a Callback URL. If you are not using callback please ensure Callback enabled? is unticked. This could also be generated if the Callback URL is set to <wpdisplay item=MC_callback> but MC_callback is either not specified in your purchase token or has no value.

SSL V2.0 servers are not supported

WorldPay do not support callback to secure servers using SSL 2.0. Please ensure that either the server is upgraded to support SSL 3.0 or TLS 1.0, or that you use http: rather than https: to access your callback script.

To determine the versions of SSL or TLS supported by your server, please visit http://jce.iaik.tugraz.at/products/02_isasilk/test/.

If you receive this and are unable to use http: for your callback script, you must contact your hosting provider to resolve this issue.

The maximum limit of 131072 bytes has been exceeded

Your callback URL is returning to WorldPay more than 128KB of data. This may be caused by the use of CSS and/or Javascript in the response. If this is the case, you will need to seperate these resources from the output of your callback script by using external files (which may be uploaded to your installation ID on the WorldPay Customer Management System and referred to as detailed in What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?).

Unsupported URL scheme

Your callback URL is syntactically incorrect; e.g. beginning with http:/ rather than http://. Alternatively, you are using ftp:// or gopher://. You must use either http:// or https://.

What can I do to ensure I have the callback data if a callback fails?
If it is not possible for us to reach your callback script then WorldPay will use the resultY.html and resultC.html as mentioned above. It may be possible for the shoppers' browser to reach your callback (or any other) script instead, and it is possible using wpdisplay to create a form on these pages which can be used as a second attempt to send the details through to you.

An example form on your resultY.html or resultC.html, to collect all the information from the above Select Junior purchase token may look something like this:


<form action="http://www.myserver.com/mycallbackscript.cgi" method="post">

<input type="hidden" name="address" value="<wpdisplay item=address>">

<input type="hidden" name="amount" value="<wpdisplay item=amount>">

<input type="hidden" name="amountString" value="<wpdisplay item=amountString>">

<input type="hidden" name="authAmount" value="<wpdisplay item=authAmount>">

<input type="hidden" name="authAmountString" value="<wpdisplay item=authAmountString>">

<input type="hidden" name="authCurrency" value="<wpdisplay item=authCurrency>">

<input type="hidden" name="authMode" value="<wpdisplay item=authMode>">

<input type="hidden" name="cardType" value="<wpdisplay item=cardType>">

<input type="hidden" name="cartId" value="<wpdisplay item=cartId>">

<input type="hidden" name="compName" value="<wpdisplay item=compName>">

<input type="hidden" name="country" value="<wpdisplay item=country>">

<input type="hidden" name="countryMatch" value="<wpdisplay item=countryMatch>">

<input type="hidden" name="countryString" value="<wpdisplay item=countryString>">

<input type="hidden" name="currency" value="<wpdisplay item=currency>">

<input type="hidden" name="desc" value="<wpdisplay item=desc>">

<input type="hidden" name="email" value="<wpdisplay item=email>">

<input type="hidden" name="fax" value="<wpdisplay item=fax>">

<input type="hidden" name="futurePayId" value="<wpdisplay item=futurePayId>">

<input type="hidden" name="instId" value="<wpdisplay item=instId>">

<input type="hidden" name="ipAddress" value="<wpdisplay item=ipAddress>">

<input type="hidden" name="lang" value="<wpdisplay item=lang>">

<input type="hidden" name="name" value="<wpdisplay item=name>">

<input type="hidden" name="postcode" value="<wpdisplay item=postcode>">

<input type="hidden" name="rawAuthCode" value="<wpdisplay item=rawAuthCode>">

<input type="hidden" name="rawAuthMessage" value="<wpdisplay item=rawAuthMessage>">

<input type="hidden" name="tel" value="<wpdisplay item=tel>">

<input type="hidden" name="testMode" value="<wpdisplay item=testMode>">

<input type="hidden" name="transId" value="<wpdisplay item=transId>">

<input type="hidden" name="transStatus" value="<wpdisplay item=transStatus>">

<input type="hidden" name="MC_log" value="<wpdisplay item=MC_log>">

<input type="submit" value="Return to web site">

</form>

Note that M_ variables are not available on the resultY.html or resultC.html pages, so you may wish to use MC_ or CM_ variables throughout (which are available to both the callback script and the resultY.html or resultC.html pages).

The <wpdisplay item=authMode> et al would be replaced with the value of the variable each time the resultY.html or resultC.html is displayed.

If you are using FuturePay and amount is not specified (or is with a value of 0), do not attempt to collect transTime using this technique.

wpdisplay is covered in more detail in http://support.worldpay.com/kb/integration_guides/pro/help/spig8200.html.

Alternatively, you could use an image tag to call a script on your web server, with parameters being passed to it for processing. An example of this could be:

<img src="http://www.myserver.com/myimagescript.cgi?transStatus=<wpdisplay item=transStatus>&transaction=<wpdisplay item=transId>&reference=<wpdisplay item=cartId-urlenc>">

This is a variant of the technique referred to in How can I have callback data returned in a URL query string?.

Note that if this fetch is to an http:// address then the shopper's browser may present an alert about a mixture of secure and insecure items.

As it is possible for you to be informed multiple times about the status of a transaction (once via callback, once via a backup); you must ensure that any duplication is detected.

I have received a payment confirmation email from WorldPay; why does my web site have no order details?
This could be caused by several reasons. The steps below should be followed in order until either the error is resolved or all steps have been exhausted.

Have you correctly set a Callback Failure Alert email address?: WorldPay may not be sending such an email at all, or not to the address you expect. To resolve this, please ensure this is set as detailed in What are Callback suspended?, Callback Failure Alert email address, Attach callback data to failure email? and Callback failure count?
Have you enabled callback?: Please ensure that Callback enabled? is selected, as detailed in How can I configure WorldPay to use callback for an installation ID?
If you are using a shopping cart for your web site please check with its documentation on the correct callback settings.

If Callback enabled? was not previously selected, please wait around 5 minutes before submitting a test transaction, otherwise you can do so immediately. If this test results in an error message being displayed after the payment was made then this is the the error in your callback script which needs to be resolved. Once fixed, you may wish to either turn Callback enabled? off again, or update your callback script further as detailed in What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?.
Is your web site using redirection?: If your web site or shopping cart solution is taking advantage of Use callback response? to generate a page which then redirects the shopper away from WorldPay and back to your site; not only is this prohibited but there are a variety of reasons why this could fail. Please ensure that your callback script performs all the processing it needs without further intervention by the shopper or their web browser.
Some shopping carts rely upon this prohibited functionality. If you have any query regarding this with your chosen solution please contact your shopping cart provider or web developer for a solution.
Do your shoppers have to click on a link or button to come back to your site?: The shopper may simply not see it or use it. Although not prohibited, this should only be used as a backup in the resultY.html or resultC.html files if the callback failed, as detailed in What can I do to ensure I have the callback data if a callback fails?. Once again, please ensure that your callback script can do all the processing it needs without further intervention by the shopper or their web browser.
If you have any query regarding this with your chosen solution please contact your shopping cart provider or web developer for a solution.
Does your callback script or server trap errors?: Please ensure that Use callback response? is enabled and then run a test transaction from your web site. If there is an error then it is likely it will be displayed here. If this option was not previous enabled then you may wish to turn it off again once the issue has been resolved, or take advantage of it as detailed in What should I be aware of if I wish to display a customised page to shoppers as a response to a callback?.

END
Last update: 08 February 2006

Make Payment (test)	`cardbe.msg.testSuccess`
Make Payment (live)	`cardbe.msg.authorised`
Cancel Purchase (test or live)	`trans.cancelled`

`transId`	Not returned
`rawAuthCode`	A
`rawAuthMessage`	`trans.fpCreatedNoAuth`
`AVS`	`0000`
`countryMatch`	`B` for a live transaction, `S` for a test one.
`authCost` & `authAmount`	`empty value`
`authAmountString`	`empty value`