How to effectively deal with a redirecting Payment Gateway and prevent a possible DoS
December 16th, 2007
I am at a position where I have to think in advance that how should I be coding the interactions with our (redirecting, not API based) payment gateway. What can be the best design practice - for us (as a coder), for our website (as a product) and for the end user (usability).
Keeping everything in mind together and working towards a solution is interesting. It made me think pretty nicely to come up with a solution which satisfies all scenarios (except the ones, over which I have no control).
Scenario
Your website X uses a Payment Gateway (PG). When a user Z initiates a transaction (Tx) - a Tx ID and amount value (minimalistic variables) are sent to the payment gateway. On the shopping cart side, the product which Z is buying, is locked inside the database so that some other user should not buy the same product. If the user makes a successful Tx with PG, your shopping cart is notified of the status & everyone is happy!
Problem Statement
Issues arise when the shopping cart is dependent on timeout values from the PG. There can be two worst cases in this scenario…
- The user Z closes the browser (before completing the Tx) after he successfully opens the PG. By doing so, your shopping cart locks the product in your DB but is never able to unlock it back (because you will never receive a timeout communication from the PG) - until unless you run a separate thread or a cron job which keeps on freeing up locked products based on timeout value. If you have a large online store, doing 10000Tx simultaneously, this problem would lock 10000 of your products for the entire timeout value (in case an attacker launches an intelligent DoS on your store).
- The user Z just keeps the browser window with PG open. A timeout has to occur before it is communicated back to the shopping cart.
Solution
Note - I have not yet implemented this in any of my products - this is just a theory!
In the first scenario, open up the payment gateway as a frame inside your website - with you controlling the top header like frame & the PG controlling the other frame. Further, create a constant pingback AJAX connection to your shopping cart through the top frame. Once the AJAX connection dies, you have an almost sure shot way of knowing that the browser is no more alive, or Z’s is no longer connected. Your cart logic can then take appropriate actions of unlocking your product. - This solves problem scenario 1
The second scenario is the worst of the worsts! Browser has not been closed, and the user Z can make the Tx anytime before PG expires his Tx. What we can try here is put up a javascript clock which keeps ticking like a timer - again, we can use our top frame as thats the only part that we control when a PG is displayed. This will keep informing the user about the urgency to finish the Tx. This timer can change colors from green to yellow to red, signifying increasing priority, etc. Moreover, on the server side - one can either have a separate thread/cron-job to unlock the locked products - or - before any new access is made to the locked up DB, the cart logic an check up which all Tx’s are in a stale state & free them up. This will surely slow down the system a bit, but this would almost render the DoS attack useless. That solves problem scenario 2.
This is just my maiden attempt at Payment Gateways. If you think, I can improve my idea, feel free to add your suggestions in the comments section.
ApnaBill.com would be definitely using some (if not all) of these concepts.
Posted in ApnaBill, Rails, Startups, Technology, Web 2.0 | Comments (0)