I propose an alternative to this: it is possible to use smart property/colored coins + decentralized market instead of singed invoices and get similar benefits.
It might sound outlandish, but I'm not saying it's worth implementing it right now. Besides that, I've just implemented a proof-of-concept decentralized market for colored coins based on "atomic coin swapping" (it is called p2ptrade), so I believe this kind of technology is relatively easy to implement. Say, it would take me about a week to implement a functional proof-of-concept.
So here's how it can work:
1. Let's say merchant has 1000 alpaca socks in stock. He will create 1000 alpaca socks vouchers using smart property or colored coins. I recommend colored coins, though. So, basically, one who owns a smart coin-based voucher can get alpaca socks.
2. Merchant sells these voucher tokens on decentralized market, let's call it p2ptrade for simplicity. He doesn't care who buys them as long as they pay. If he is using colored coins, he can get paid in any colored coin-based currency, not just Bitcoins.
3. Optional: These vouchers might be bought by resellers, who can them sell it on same market for a different price or for different currency.
4. End-user buys voucher via p2ptrade. Of course, it might work via highly specialized GUI which might work like app store: he simply searches for a product, reads overview and clicks buy.
5. End-user who is in possession of voucher can order shipment: he will sign message like "Ship alpaca socks to
6. Merchant now gets this voucher back and it sees user's message (ideally message should be incorporated into blockchain), he should ship socks.
7. User has hard evidence that he have purchased socks, so he can use it against merchant if that fails to deliver the product.
I haven't thoroughly analyze this, but here are some potential advantages compared to signed invoice approach:
1. Merchant needs to sign smart property or color definition, he doesn't need to sign each invoice. This means that he can keep his private key offline, signing a new batch of vouchers once per week, for example.
2. We don't really need SSL. Well, end users need to make sure that voucher indeed come from merchant, but there is plenty of options for such verification. It can be entirely out-of-band, for example. Perhaps a catalog company will endorse vouchers and provide insurance (think like Amazon, eBay), so user only needs to trust that company. It can also work with web-of-trust-like things.
3. It can easily work with multiple currencies via colored coins. Say, merchant sells vouchers for USDcoin, then resellers sell them for GoldCoin, Bitcoin, EURcoin etc. It can also work with ripple-style colored-coin-based currencies.
4. Wide opportunities for reselling (user doesn't care whether he buys voucher directly from merchant or from resellers).
5. You automatically get features like gift cards, catalogs etc.