Home made cart system continuity problems

[salewit]

We've written our own shopping cart system in PHP years ago for a site that sells tickets to a non-profit event every year. Originally it was designed to collect credit card info and then we processed the cards manually. Well every year the operation has gotten bigger and bigger. This past year I pushed for us using a gateway to process the cards on the spot since I was getting worried about storing all this CC info. So we implemented a gateway and tweaked the script to handle this. This past season has sold out in less than 3 days. A total of 14,000 tickets and 2500 transactions.

Ok, here's the problem. We gather up the customer info, then send the info to the merhchant. The merchant then sends us to our pre-defined "success" or "failed" page that we have set up with them based on the results. Our problem is that we had a LOT of duplicate transactions. When I talked with these customers, they told me everything went fine but then they got "server not found" errors at the end and assumed it didn't go through, so they ran it again.

The problem on our end not only with the double transactions, was that unless someone actually gets that success page, the ticket inventory is NOT deducted and the order is never recorded on our site.

Sorry for the long winded letter, but any ideas on how to deal with this problem? We've considered teaming up with Ticketmaster, but they really ream people so bad with transaction fees, we don't have the heart to do it to our loyal customers.

[topher]

Do you get dupes when you run in test mode?

[bwnbwn]

buy a cart for 300.00 cart32 com is easy fact is they will install it for you just make sure the card processor is on their list. Simple set up and with a little programming you won't have to worrow about this again.

I am not with them have been using their cart on my ecommerce site for years and very soon google payment will be a part of the cart as well.

This is by far the easest way to handel this as carts are very difficult to program and if not careful will be hacked.

[axgrindr]

We've had similar issues on a couple of our sites. We have had good luck with hiring ecommerce savvy coders to go through our checkout system and make any adjustments that are necassary. There are coders out there who specialize in customizing and fixing existing ecommerce scripts.
A recent coder, while fixing some minor issues, found and fixed a security flaw in one of our checkout systems that we would have been unaware of otherwise, a fairly major flaw which would have allowed someone with basic php knowledge to shop/download freely on our site without paying.

[bwnbwn]

"a fairly major flaw which would have allowed someone with basic php knowledge to shop/download freely on our site without paying."

as I said
why buying one is still cheaper, I would think just getting the IT people to look at one cost 300 or better

[axgrindr]

as I said

hey bwnbwn
I wasn't saying that they shouldn't follow your advice, just sharing the experience we had with a similar problem.

[philbish]

Perhaps your credit card processor has a different integration method. Instead of sending data to their server on the client side, send it to their server directly from your server while the customer is waiting.

[digicam]

How a serious business can operate with a home made cart is beyond me, unless you keep abreast of the latest security issues you are asking for trouble and will spend more time programming than running the shop.

Buy xcart for a few hundred dollars and let them sort the security whilst you sell things.

my 2 cents.

[bwnbwn]

axgrindr
Sorry for the way it sounded it wasn't meant to be that way just your post confirmed what I had said

I used a bad choice of words should have been "as confirmed by" not as "I said before"

I apologize.

[jollymcfats]

Gateways interfaces that take the user off your site are very difficult to monitor and implement reliably. You don't know if the user is getting through to the gateway site, or if they ever received the proper redirect back to your approve/deny page. It's very difficult to monitor for errors. It's hard to find dupes until you reconcile transactions the gateway processed with those your site tallied, and if that delay is too long you're not able to simply void the dupes and have to incur the expense of a refund.

If you can switch to a server-to-server card authorization system you'll have much finer control and reporting over the purchases. You don't have to worry about the patrons being able to resolve and connect to the gateway- only your web host needs to be able to make this connection. And if the gateway isn't responding, you can log this information and take action on it. You'll know all transactions sent to the gateway, and reconcillation and dupe detection is simple. Tighter control over the approve/deny process also makes inventory management much easier.