Redirection is optional. If no redirection is provided Paylink will display a notice of the transaction result to the end user and no further action will be necessary other than closing the browser.
Once a transaction has processed, the browser can be redirected back to the merchant's store, within the Paylink API this is known as a redirect. A redirection may depend on whether the transaction result is successful or failed. Likewise you are able to configure a redirection URL on each token request or a default value that may be configured store wide. The default is to have no redirection.
A redirection from Paylink is performed via a HTTP POST application/x-www-form-urlencoded
rather than a HTTP 302
redirection. This enables Paylink to send data in the redirection in a POST call. Optionally a URL may be prefixed with a verb such as "GET:" where the redirection process will enforce a GET call. For instance
A default redirection simply provides a URL
{ "redirect_success": "https://mysite.com/payment/result", "redirect_failure": "https://mysite.com/payment/failed" }
whilst an enforced GET call can be preceded
{ "redirect_success": "GET:https://mysite.com/payment/result", "redirect_failure": "GET:https://mysite.com/payment/failed" }
A Merchant Store that relies on receiving the result of the transaction through redirection in preference to a post back should be aware that –
- Customer Browser Redirection is unreliable : The Customer may close the browser, or a network failure may occur immediately or before being redirected to a redirection URL. In such cases, the Merchant Application will not receive an update of the status of the transaction, despite the fact that it may have been successful.
- Status information flow depends on compliant Customer behaviour : This means that the Merchant Application only receives status updates when the Customer Browser is redirected either automatically, or by requiring the user to click a button on the Payment Form.
If the Customer Browser Redirection URL refers to an unencrypted protocol such as HTTP, the Customer Browser is likely to display a warning that they are moving from a secure, encrypted connection to an unsecured connection. This is a by-product of the redirection being performed as a POST operation. To ensure that the user experience is as seamless as possible, it is recommended that Merchant Applications use an encrypted protocol such as HTTPS.
Redirection Payload
If a transaction has been configured for redirection, Transaction Response data may optionally be including within a HTTP POST call, with the following considerations
- it is feasible that the payload data may not be genuine, and data should be validated using a SHA-2 digest.
- data will optionally be returned in success or failure results
- the redirection data will only be provided once the transaction is concluded.
- the Content-Type entity header of the POST operation will be set to
application/x-www-form-urlencoded
it is not currently capable of performing JSON or XML data redirections - the payload data will be URL encoded regardless of the request content-type
- the Content-Type entity header of the POST operation will be set to