5.1.2. Preauth Request

Knowledge Base

Get help for payment solutions. Search our articles or browse by category below.

5.1.2 Pre-Authorisation Request

Pre-authorisation transactions are supported by the acquirer Elavon only. 3D Secure pre-auth transactions are not supported due to scheme restrictions.

Example of a XML Pre-Auth request:

<?xml version="1.0" encoding="UTF-8"?>

A response for this transaction would be:

<?xml version="1.0" encoding="UTF-8"?>

Payment request fields description:


Field Name Required Description
ORDERID Y A unique identifier for the order created by the merchant. (Max 12 characters).
TERMINALID Y A Terminal ID provided by Worldnet. NB-Please contact Worldnet to be issued with a test terminal ID.
AMOUNT Y The amount of the transaction as a 2 digit decimal or an Integer value for JPY amounts.
CARDNUMBER N The payment card number.
CARDTYPE Y See section 3.2 above.
CARDEXPIRY N 4 digit expiry field (MMYY), required if not using a SecureCard.
CARDHOLDERNAME N The name of the cardholder, required if not using a SecureCard.
HASH Y AN MD5 HASH. See Note 1 below.
CURRENCY Y A 3 character currency code of the transaction. ISO 4217 Currency Code.
FOREIGNCURRENCY INFORMATION N Tag contains Dynamic Currency Conversion information. It has to be present in the eDCC enabled transactions. See XML Payments with eDCC.
TERMINALTYPE Y The type of the terminal:
1 - MOTO (Mail Order/Telephone Order)
2 - eCommerce
4 - MOTO (Mail Order/Telephone Order)
7 - eCommerce
Recurring Payment Flagging:
2 - Specify that this transaction is recurring. This must be accompanied by the RECURRINGTXNREF field or have special permission granted by the Gateway. Not all processors support this transaction type and consultation with the integration team should be carried out prior to configuring recurring payment flagging.
For First Data Latvia terminal MOTO transactions:
4 - Telephone Order
9 - Mail order
If sending XID & CAVV from non Worldnet MPI on an eCommerce transaction use:
0 - not applicable
1 - Single transaction
2 - Recurring transaction
3 - Installment payment
4 - Unknown classification
5 - Fully authenticated transaction 3D Secure transaction.
6 - The merchant attempted to authenticate the cardholder, but the cardholder cannot or does not participate in 3D Secure.
7 - Transaction when payment data was transmitted using SSL encryption, or Channel Encrypted.
8 - Transaction in the clear, or Non Secure.
EMAIL N Cardholder e-mail address. If populated the cardholder will be sent an email receipt. This can be overridden by the Selfcare System terminal Setup setting “Disable Cardholder receipt”.
CVV N The security code entered by the card holder.
ISSUENO N The issue no. of the card (Solo).
ADDRESS1 N The first address field for AVS.
ADDRESS2 N The second address field for AVS.
POSTCODE N The postcode (required) for AVS. Also required for MaxMind MinFraud fraud scoring.
DESCRIPTION N A description of the transaction.
CITY N Required for maxMind MinFraud fraud scoring.
REGION N Required for MaxMind MinFraud fraud scoring. See MaxMind definition of this field as it is forwarded to them without modification.
COUNTRY N ISO 3166-1-alpha-2 code. Required for MaxMind MinFraud scoring.
IPADDRESS N Recommended inclusion. Useful for tracking customers. Functionality will expand in the future. Required for MaxMind MinFraud fraud scoring.
CUSTOM FIELD N Should also use the “NAME” xml attribute to assign the name of the custom field. See Note 3 in PAYMENT section.
RECURRINGTXNREF N Should be set to the value of a UNIQUEREF returned in a PAYMENT response for a non-recurring approved transaction on a matching card. TRANSACTIONTYPE should be set to 2.

The following fields are returned in the response:

Field Name Description
UNIQUEREF Generated reference that should be stored for tracking and remote XML refunding.
RESPONSECODE A or D or R (Approval or Declined or Referral).
RESPONSETEXT The text authorisation.
BANKRESPONSECODE Only sent on TSYS terminals. The TSYS response code returned in the authorisation response.
APPROVALCODE Six digit AuthCode.
DATETIME The time of the transaction created by the bank. Format: YYYY-MM-DDTHH:MM:SS. Note that this is intentionally in a different format to the request timestamp to highlight the fact that it is a different time.
AVSRESPONSE The result of the AVS check. See Appendix A for more information.
CVVRESPONSE The result of the CVV check. See Appendix A for more information.
PROCESSINGTERMINAL If the transaction was performed on a “routing terminal” then this is populated with processing terminal ID that the system selected to process the transaction.
HASH An MD5 HASH. Note 2 below.


1. The MD5 HASH is generated using the following as an input string:


For multi-currency Terminal IDs (see section 3.3 above) this should be:


2. The MD5 HASH is generated using the following as an input string:


For multi-currency Terminal IDs (see section 3.3 above) this should be:


The DATETIME is the time returned by the bank for the transaction.

Many code examples on how to generate an MD5 HASH can be found in the Internet. For assistance, please contact Worldnet.

Errors handling

If there is an error processing the transaction, the error string is returned in an XML message with the simple tags:

Copyright © 2017 Worldnet Knowledge Base | Powered by DokuWiki
developer/integrator_guide/5._xml_integration/5.1._request_types/5.1.2._preauth_request.txt · Last modified: 2016/07/26 12:04 (external edit)