I am upgrading a client's e-commerce webstore and have hit a bit of a snag.
The store is a custom-made set of PHP scripts. At each sale, the credit card is charged via the merchant account interface, and then the order is e-mailed to the client's desktop INBOX. However, as the company grows, this became unscalable, as the client spends more and more time manually filing e-mailed order confirmations.
I wanted to set up a database on the web server, and modify the PHP store scripts to store the sales into the database. Then the client would log into an SSL extranet portal with a browser, and see the sales securely -- fed from the database on the same webserver.
But the client said he didn't want this because he doesn't want customer data on the web server -- even though not credit card information is stored -- just names, e-mail addresses, and items purchased, and such. He prefers to have that data stored on a server at his office, which is only connected to the intranet, and has no outside access.
The intranet server which currently stores the data cannot be accessed from outside, and so cannot be accessed from the web server which processes sales, of course.
Is it the norm to have sales data on the web server? How do SaaS companies do this? Is their subscription customer data on the web server in a database?
If the client's request is viable, what's the standard accepted approach of having sales be automatically processed, and not just e-mailed, but to have those sales wind up on the intranet machine rather than on the web server? Would the intranet machine have to log into the web server and "grab" the sales from a temporary table on the web server? Would the web server have a custom service running just to service the connection from the intranet server and feed it recent sales, and then remove those sale records from the web server?
Basically, what's the standard way of moving sale data from a public web server machine to an intranet machine? Or am I not approaching this issue in the right way?