sending data to payment gateway and back - possible problems

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. Usuall开发者_如何学Pythony 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

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();

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.