Using Relay Response or Redirect when Receipting

Our Tech Lead, Emil Marceta, is the big brain behind most of our cool technology. He's also the mastermind behind the design of the Redirect solution in our Payment Pages. Recently one of our clients asked for clarification again on the complexities relating to Relay Response and Redirects and Silent Posts. Understanding how these work is key to ensuring that customers are seeing what they need to see and your internal systems are getting updates appropriately.

Here's a straight excerpt from Emil's correspondance with a client:

The Redirect option is recommended since it avoids synchronous Server to Server call during payment processing. The 'Redirect' mitigates the synchronous nature of Relay Response call. The Relay Response 'freezes' (browser, e-xact, merchant server) request resources during the payment request. This is because the RR result needs to be sent back to the browser. In a very high load scenarios coupled with any slow component on the merchant servers or network it may result, (and look like) a Denial of Service Attack. We've implemented several measures, such as more aggressive RR timeouts as a measure, but it is unrealistic to lower them in the few seconds range.

Here is one illustration: Lets assume that the Payment server max capacity is 1000 handlers. Let's assume that the RR handler on the merchant server produces: receipt for the customer, and performs slow actions such as updates the DB and sends Email. Since slow operations happen in the request processing time, their time is added to the request time. Assume delays of 5s for Sending Email/updating DB and 1000 requests queued. Then this 1000 capacity is all used for that time, and new connections cannot be served. Therefore, with RR, there is a 'dependency' (coupling) on the performance of the merchant server with the system wide impact.

Obviously, updating backoffice DB and sending Email are constituent parts of the payment process and they need to happen. To improve the RR solution on the Merchant side RR handler could be written asynchronously itself (to only receive parameters and then spawn a job/thread to perform the rest of the slow actions such as sending Email, updating databases etc). This however, requires more development effort on the customer side. Besides, many popular Web languages/frameworks such as PHP etc don't support asynchronous request handling. It also poses some chicken-egg problems, since the receipt may depend on the DB updates. :) E-xact may not be aware when potentially customer component degrades in some way so coupling remains. Other aspects such as network related issues remain unsolved.

The Redirect tries to help with the following strategy. It uses the browser to carry the information back to the merchant site as a part of the Redirect (HTTP 302) location - GET request. The fields are the same as with RR (including the security signature that can be verified).

This means that as soon as the request is processed (accepted or declined) the browser is redirected to the merchant site where the browser parameters are processed and the receipt is presented. The Silent Post is sent asynchronously, so it is not a blocking action (I believe this was asked in previous Email - so my apologies for repeating - I'm writing all of this for completeness sake). The Silent Post rationale is the redundancy. In the ideal circumstances it would not be required. In the case the customer browser crashes, customer closes the browser etc at least the transaction notification is sent to the merchant server. There is no guarantee of ordering, that is, whether Silent Post or the browser reaches merchant server first. Also the two actions should be idempotent, that is, if the browser request came first, and has updated the DB, the Silent Post should not. Unique Transaction Identifier (Tag) can be used for that purpose.