Background validation is a method of double checking the results of transactions
using a server-side post. It is useful for Hosted Payment Page transactions as the result of the transaction (i.e. the response redirect) can sometimes fail, leaving the site without a result for the transaction even though the transaction may have been authorised.
It is possible to enable background transaction validation at a terminal level. If this feature is enabled then all transactions sent through the Hosted Payment Page will be validated.
The Validation URL should be set for the terminal or sent in the payment request to the Payment Page, and Worldnet will use this URL to send an HTTP POST request with transaction processing result and will expect to receive “OK” in the HTTP response body (2 characters only, no HTML). Any other response or connection issue will be considered as not-validated and a subsequent attempt to reach the validation URL will be made later, this process will repeat until our maximum allowed time for validation has passed. If the maximum allowed time has passed and the transaction was not successfully validated, the transaction will be marked as expired and the notification email address will be notified. Background Validation can be enabled through Self Care in the Terminal Setup section.
If validation is failing or has failed for a particular transaction there will be details of the cause of the failure in the Open Batch in the Self Care. This will detail the URL being requested and the result, which could be a timeout, SSL or other error or it could also be the body of the HTML that we received that did not match “OK”. You can update the URL for the next attempt, reattempt validation of the trasnaction by clicking “Validate” or simply flag the transaction as validated without reattempting online by clicking “Validate Offline”.
Background Validation can be enabled through the Self Care in the Terminal Setup section.
The following parameters are sent in the validation request:
|UNIQUEREF||Generated reference that should be stored for tracking and remote XML refunding.|
|ORDERID||Order ID supplied by merchant in request.|
|RESPONSECODE||A, D or R (Approved, Declined or Referral).|
|RESPONSETEXT||Text describing transaction state. This will be populated with an error message if there was an issue during processing.|
|APPROVALCODE||Transaction approval code if transaction was authorised otherwise empty.|
|AVSRESPONSE||AVS response, available only when AVS is enabled for the terminal. See Appendix A.|
|CVVRESPONSE||CVV response, available only when CVV is enabled for the terminal. See Appendix A.|
|HASH||An MD5 HASH. See Note 1 below.|
|Custom Parameters||Configured Terminal Custom Parameters.|
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: