Still moving the discussion forward, what is really needed is a "client" which exists solely as a daemon (or windows service) communicates to a variety of database platforms through ODBC and is designed specifically for backend processing (integration with shopping carts, order processing systems, customer databases, etc). Keeping the private keys in an encrypted database would also provide another layer of security. Access to the server doesn't necessarily mean access to the database (or specifically tables containing keys). Having a "client" which requires manual startup and loads digitally signed business rules (limits on tx volume, max tx size, velocity, etc) would provide another layer of security.
I am working on forking the bitcoinsharp (.net library) to handle a merchant backend (database driven) wallet. One limit of the bitcoinsharp codebase is that it doesn't maintain a local copy of the blockchain. It relies on peers for transactional data. However that limitation can be overcome by ensuring the processing node only connect to a handful of trusted peers which are running as full nodes (satoshi or otherwise).