Paylink-v3 _{Redirection Handling}

On conclusion of a transaction, the browser may be redirected back to the Merchant Store. A redirection may be directed to different URLs depending on whether the result is deemed successful or failed.

A Merchant Store that relies on receiving Transaction status information through Redirection in preference to acceptance of a Postback may recognise subtle differences in the information that would otherwise be received through the acceptance of a Postback. More specifically –

1. Customer Browser Redirection is unreliable : The Customer may close the Customer Browser, or the Browser may crash in the middle of a Transaction or immediately 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 the Transaction may have been successful; nor will the Merchant Application receive notice of whether the Transaction was rejected by the Acquirer, was consciously cancelled by the Customer or merely abandoned and left to expire.
2. Status information flow depends on compliant Customer behaviour : The flow of status information for a particular Transaction from Paylink to the Merchant Application is dependent on control flow moving from the Payment Form to the Merchant Application. This means that the Merchant Application only receives status updates when the Customer Browser is redirected to a Redirection URL either automatically, or by clicking on a button appearing on the Payment Form. In contrast, a Merchant Application that accepts a Postback call can (configuration dependant) continuously track the status of the Transaction, and each Transaction Processing Request made using the Payment Form.

Customer Browser 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 is validated using a digest. As the browser is used to rely on data exchange, it must be considered that the user may amend the result details i.e. declined to accepted.
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
   2. the payload data will be URL encoded regardless of the request content-type