views:

63

answers:

2

I'm going to use one of the payment gateways and so users from my site will be redirected to gateway hosted page to provide all the CC details. Gateway will return results to the page which I specify (lets call it paymentProcessed.php). But now my worry is that:

  1. someone might fake it. What I mean is that someone might be redirected to payment gateway, then instead of paying, will return results to my site paymentProcessed.php page with confirmation that all has been payed. This confirmation will be send by the user itself via normal POST, and my site then will deliver products to the user although there was no actually payment done. What is the common practice to avoid this kind of situation?

  2. Someone is redirected to gateway hosted page, pays, redirects back to my site and session he was logged in with has expired. Usually I rely on sessions to see if user should be allowed access to certain parts of the site, but now do I need to implement some other sort of check for confirmation page? For now I was thinking of storing order id and randomly generated value in database, when user redirected pass it to gateway (together with total, total would be passed to gateway and then back so I could confirm that proper amount was paid). Then when confirmation comes together with order id, my randomly generated value (and total) instead of relying on session like I usually do for normal shopping cart pages, I should check this value with matching order id and change status of order as needed. What is the common practice to deal with that kind of problem?

  3. What other possible issues I should think about?

I tried to explain as clearly as possible and I hope all above makes sense. please let me know if I need to clarify something though. btw I code in php/mysql

A: 

Hi,

I've implemented some payment gateways already, one thing in common with all of them is that card processor will always return the transaction status for you, some of them use a weak redirect relaying on users to accomplish, others allows you to use their webservice to authenticate transactions. Either way you will need to get processor docs to know how to authenticate the transaction on your side.

Now about the other odds to avoid sessions from expiring you might want to store all transaction data on a table, you can also have sessions to speed up the process, but you don't need to go much further to see issues with relaying only on sessions:

  • What if the user gets disconnected in the middle of process?
  • Some CC processors force you to open a popup to process, what if the user closes it?
  • What if the server crashes?
  • What if the payment method failed and user wants to retry with another type of payment?

Now some random thoughts about payment gateway implementation:

  • Some processors delay to authenticate the purchase, they will return to your site that the payment has been accepted but you will have to use their webservice to check the final status;
  • Some processors require you to capture the purchase, meaning that even if it was approved you can void or finalize it later, this is good to avoid carders from purchasing things off your site, you can check user's info to make sure it's all good them capture or void the purchase avoiding a chargeback.
  • If your credit card processor gives you access to a webservice or they do server to server purchase authentication this will require a valid ssl certificate, so be aware.

That's all i can recall by now.

Rodrigo
+1  A: 

It's actually easier and more secure then you realize. When using a hosted payment page, like Authorize.Net's SIM API, a hash of some sort is included that only you and the processor know about. It is impossible to fake as generating it requires private information only you and the processor have. So all you need to do is verify that the hash sent to your return page by the payment processor matches the one you have for the transaction. If it does, you can be 100% sure the transaction has not been spoofed.

Sessions tend to last longer then a trip to a remotely checkout form usually takes to complete and the session does last even though a user leaves your site. But, if you are concerned about a session expiring before they return to your site, simply store the session information in a database and use a cookie to track the user. Then when they come back use the cookie to identify them and retrieve their session information from your database.

UPDATE:

Here's how you can make your session cookie last longer with PHP:

// Makes the cookie last two hours. Make it a higher number to last longer.
session_set_cookie_params(7200); 
session_start();
John Conde
Or you could just configure PHP to have a longer session cookie (which can be done at run-time using session_set_cookie_params()).
Lèse majesté
@Lèse majesté Very good point. Amending answer to show example.
John Conde
hash returned from hosted payment page would be great but payment gateway I go for doesn't seem to return anything like that. Am I completely screwed and there is no way to implement it without hosting form page myself and at the same time getting into trouble with PCI compliance stuff?
spirytus
They have to return a bunch of information to you. If you can verify that multiple points of data match up properly you can assume the response is from them. If they have custom fields pass your own hash over and look for it to be returned to you. You can also verify the IP address the response is sent from is one of theirs.
John Conde
unfortunately verifying IP addresses won't work as apparently IP's of payment servers might be changing at different times. There is an option to pass additional parameters to gateway and have these returned after user made payment. The problem is however these parameters can be easily looked up as are simply available in hidden input fields. I'm worried that someone can look all the parameters up and send me "fake" payment confirmation, without paying a cent. There doesn't seem to be any way of passing data that would identify gateway and wouldn't be available to user at some point.
spirytus
Easily is being used to freely. I'm sure the pages are encrypted which makes it NOT easy to get to the information. If you pass a one time hash back and forth you dramatically increase your level of confidence in the identity of the sender. But it sounds like your processor offers a poor API. You either need to ditch them or accept less then ideal security.
John Conde
I said easily as its right there in plain text in hidden input field, obviously is not rendered but anyone can check it with viewsource etc. API seems to offer all that I would need but then when you get into details it comes out that e.g. query service they offer has 100 queries a day limit that cannot be increased. Honestly this payment gateway looks very decent and is very popular as far as I can tell, thats why I assume I might not fully understand something here and trying to find a solution. BTW thx for your answers and trying to help John
spirytus