By default, when a transaction has been processed, our response page will be displayed to the customer. This displays a message indicating whether or not the transaction was successful, along with details regarding the payment for the customer’s records. Alternatively, you may prefer to host a response page on your own server.
Configuring redirects
Click the headings below to learn how to configure redirects that occur following different transaction outcomes:
This can be configured on your site by adding the following to your POST to Payment Pages:
<!--Enables rule that redirects the customer following a successful transaction-->
<input type=hidden name="ruleidentifier" value="STR-6">
<!--Enables rule that redirects the customer following a successful account check-->
<input type=hidden name="ruleidentifier" value="STR-11">
<!--Update the below with the URL for the redirect-->
<input type=hidden name="successfulurlredirect" value="http://yourwebsite.com/successful">The URL of your hosted response page must be externally facing. We cannot redirect to internal, intranet, private or loopback addresses.
We recommend only redirecting to secure HTTPS pages. When using iframes, some web browsers will refuse to redirect to non-secure pages as a security measure.
If “STR-6”, "STR-11" or the redirect URL are submitted in the POST to Payment Pages, they also need to be included in the string used to generate your request site security hash. Failure to do so will result in the customer being shown an “Invalid details” error message.
By default, if a customer’s card declines, we will redisplay the payment form with an error, prompting them to try a different method of payment (recommended). Alternatively, you can instead opt to redirect customers to a different URL when their card declines.
This can be configured on your site by adding the following to your POST to Payment Pages:
<!--Enables rule that redirects the customer following a declined transaction-->
<input type=hidden name="ruleidentifier" value="STR-7">
<!--Enables rule that redirects the customer following a declined account check-->
<input type=hidden name="ruleidentifier" value="STR-12">
<!--Update the below with the URL for the redirect-->
<input type=hidden name="declinedurlredirect" value="http://yourwebsite.com/declined">The URL of your hosted response page must be externally facing. We cannot redirect to internal, intranet, private or loopback addresses.
We recommend only redirecting to secure HTTPS pages. When using iframes, some web browsers will refuse to redirect to non-secure pages as a security measure.
If “STR-7”, "STR-12" or the redirect URL are submitted in the POST to Payment Pages, they also need to be included in the string used to generate your request site security hash. Failure to do so will result in the customer being shown an “Invalid details” error message.
By default, if any errors were encountered that prevented the transaction from being processed successfully, we will redisplay the payment form with an error, prompting them to try a different method of payment (recommended). Alternatively, you can instead opt to redirect customers to a different URL when an error occurs.
This can be configured on your site by adding the following to your POST to Payment Pages:
<!--Enables rule that redirects the customer following an error-->
<input type=hidden name="ruleidentifier" value="STR-13">
<!--Update the below with the URL for the redirect-->
<input type=hidden name="errorurlredirect" value="http://yourwebsite.com/error">The URL of your hosted response page must be externally facing. We cannot redirect to internal, intranet, private or loopback addresses.
We recommend only redirecting to secure HTTPS pages. When using iframes, some web browsers will refuse to redirect to non-secure pages as a security measure.
Both “STR-13” and the URL of the redirect need to be included in the string used to generate your request site security hash. Failure to do so will result in the customer being shown an “Invalid details” error message.
If the only rule for redirects enabled on your site is STR-13, it will be triggered in all error cases (including declines).
If STR-13 AND STR-7 are enabled, all errors will cause STR-13 to be triggered EXCEPT in a declined final state, where STR-7 is triggered instead.
Fields returned
URL redirects using system rules will include the following fields of information, by default:
- transactionreference
- requestreference
- orderreference
- sitereference
- errorcode
- settlestatus
- paymenttypedescription
The redirect will also include the response site security hash (this is covered in further detail below).
To include extra fields in the redirect:
If you would like to include additional fields, you can update your POST to include stextraurlredirectfields. The following example will include the billing first name, last name and email address in a redirect, in addition to the default fields listed above:
<form method="POST" action="<DOMAIN>/process/payments/choice">
...
<input type="hidden" name="ruleidentifier" value="STR-6">
<input type="hidden" name="successfulurlredirect" value="http://www.yourwebsite.com/successful">
<input type="hidden" name="stextraurlredirectfields" value="billingfirstname">
<input type="hidden" name="stextraurlredirectfields" value="billinglastname">
<input type="hidden" name="stextraurlredirectfields" value="billingemail">
...
<input type="submit" value="Pay">
</form>
Replace <DOMAIN> with a supported domain. Click here for a full list.
Important: The names of all additional fields to be returned in the redirect need to be included in the string used to generate your request site security hash. Failure to do so will result in the customer being shown an “Invalid details” error message.
Site security for responses
You will receive a hashed responsesitesecurity value in any redirects sent to your system. We strongly recommend that you recalculate the responsesitesecurity hash returned, to ensure it has not been modified by a customer or third party and that the fields were sent by Trust Payments.
Advanced
Using the Rule Manager, you can configure redirects that happen in other scenarios.
