My ideal solution to processing bitcoin transactions for merchants.

I have begun rewriting bitcoin processing software in BitWasp. The original payment system was rather basic, and without any unique or new features: users topped up their accounts by paying to an address which we watched. any funds received to that were added to their balance in the database. This lead to all sorts of issues with negative balances, and was soon realized to be completely insufficient when dealing with customer funds, given the technical abilities that come from the bitcoin protocol. It's easy to mess with a database, whereas relying on bitcoin itself is a far better solution, and allows me to process transactions without the admin of any site to disappear with the funds.

So, I am writing here to propose a new payment system for Bitwasp, one which others could soon implement themselves. So, the core feature will be multisig addresses. As with the order process in Bitwasp now, vendors can request users either finalize early, or to allow an escrow payment.
In both cases, users will be paying into a 2-of-3 multisig address.
- Case of 2of3 in Finalize Early: If the merchant disappears, the admin must be included in the transaction in order to return the funds to the buyer.
- Case of 2of3 in Escrow - well documented purpose.

Bitwasp will eventually use BIP32 MPK's to generate an address for each transaction. That means a new public key for the buyer/vendor/admin for each address/order. Seeds will be generated on a local client level (or a javascript interface), and the mpk will be the only information held on the site.

Once the funds have arrived in the multisig address, we consider if the transaction is escrow/FE.
If escrow and the full order price is met, then the vendor ships the goods, indicating this to the user. Once the user receives the item, they indicate this on the site, and sign the transaction.
If FE, the buyer must sign the transaction before item is dispatched.

The transaction the buyer/vendor will be presented with will have two outputs: one to the vendors final payment address (this will be either based on his MPK, or a BIP38 intermediate code which again would lead to a deterministic address). If the buyer raises a dispute, a new transaction can be crafted by the admin which has the buyers payment address as the output. The second output in both cases will include a fee for the site.

Here's what I'm getting at.
Signing is the be-all and end-all of authorizing a transaction. The funds don't need to be in the Bitwasp wallet, they just need to be in a multi-sig address. It's the safest way to facilitate bitcoin payments without handling bitcoins. As signing requires the private key to be present, you would expect this to be done on the users offline computer, or just on the app on their phone. No more of these 'withdrawal pins' - it's a half measure. No more sites requiring you give them full control of the funds. There should be a clear purpose to your payment, ie, directly into a multisig address rather than blindly paying for your balance only to exist in a MySQL database.

Out of context example: By presenting the user with a transaction they must sign using their app, you leave things open for some excellent features. Asking users to keep funds in deposit on a site could be more securely done by offering a 2-of-2 signature address. One key on the site, and another from the users device. They're presented with the transaction, they double check it, sign it locally before submitting it back to the site to be broadcast.

So what I would like to see in future is support for signing transactions in bitcoin-qt, and better support for multsig transactions. The clients should keep up with such awesome developments in the bitcoin protocol, and I truly believe that soon, the pressure will be on mainstream clients to keep up with developments elsewhere. I'm aware of projects who are trying to answer the needs of people by including these features, but the bitcoin-qt client needs to embrace them before others do too.

Ramble over.. TL:DR; multisig addresses and having all website payments require the user to sign on their local device offers a fantastic level of security, so if anyone can work on this, please do.