Paylink-v3 Redirection Handling

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": "", "redirect_failure": "" }

whilst an enforced GET call can be preceded

{ "redirect_success": "GET:", "redirect_failure": "GET:" }

A Merchant Store that relies on receiving the result of the transaction through redirection in preference to a post back should be aware that –

  1. 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.
  2. 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

  1. it is feasible that the payload data may not be genuine, and data should be validated using a SHA-2 digest. 
  2. data will optionally be returned in success or failure results
  3. the redirection data will only be provided once the transaction is concluded. 
    1. 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
    2. the payload data will be URL encoded regardless of the request content-type
+44 (0)1534 884000