PHP and forms

[fluiduk]

Hi All

I have a bit of problem with a project I am working on.

Basically I have built a simple shopping cart and now I need to integrate the payment proccessor (HSBC)

The cart content are stored in a temp table until the user goes to pay, that way we don't get loads of orders in the system where people have just been browsing and didn't pay.

The problem with this is... I need a form on the 'cart confirmation' page that posts the order value, currency and loads of other stuff to HSBC and bounces the customer to the HSBC payment gateway. But at the same time I want to be able to write the order to the database and make a note that the user has clicked on the HSBC button.

Initally I considered posting the form to a processing page, which stores the data and then creates the HSBC form, and posts it automatically via javascript, not ideal.

I also looked at fsocketopen, the problem with this is that it does'nt seem (well not from my inital research) to actually send the browser to the page it is posting to, which is crucial.

I had considered saving the order to the DB when the confirmation page loads, and then perhaps running a cron job to remove unpaid orders after a certain time, to stop the DB getting clogged. But then this would mean I would need to allow for users changing the cart contents, or delivery options, and then have to update the records etc.

Anyone got any ideas of how to achieve what I am after?

Thanks in advance

Aaron

 

[Sagalout]

Cant help with your problem, but with an ecommerce site I built I created a cart in the db for each session where a user adds an product, then set a flag to complete on the callback from Barclays PDQ. I know what you mean about the database getting bigger and bigger, but this ones been runnign for a few years now, has hundreds of thousands of carts, without about 5% of them completed, and no noticeable slowdown. Also makes it very easy to produce statistics on uncompleted orders etc. I'll trim it if it ever becomes a problem, but at the moment its fine.

 

[fluiduk]

Yeah I guess the records wouldnt be too much of an issue, its just when users edit their carts. Guess I will just to write some functions that update the order records

Cheers
Aaron

 

[Sagalout]

Not sure what you mean about the users editing their carts. The way I do it:

User browses site - this creates a session_id, but not a cart and no need to put anything into the db
.
Customer adds a product to their cart - this triggers the creation of a cart record with the session_id as the unique identifier, and an order which is the product_id and the cart_id.

Customer may or may not add additonal orders.

Customer checks out via Barclays (or worldpay/hsbc whatever) - Callback from the payment processor sets a field in the cart to complete (assuming its authorised). Customer is returned to site and session is destroyed, meaning cart is empty as that session is over with and a new one is created.

or...customer leaves the site, meaning no purchase. Cart and orders remain in the db as uncompleted. Can be wiped off in the future if required. User session is destroyed on closure of the browser, although you could amend this to write the session to a cookie if you wanted the cart to remain active on subsequent visits.

As I say, its pretty simple and has worked for me on a number of projects