This sounds good, in broad strokes. There are a couple of things I would watch out for:
Refunds can be tricky. People who are using web wallets may not really have their own addresses; the wallet operator has a large pool of addresses and tracks customer balances internally. When the customer wants to make a payment, the operator pays from one of the pool addresses and debits the customer's account. So if you try to send a refund to such a customer, it goes back to the operator's address, but they may not have the ability / motivation to recredit the customer. They might even throw away the private key once the coins are spent (and the change sent to a new pool address), in which case the refunded coins are lost forever. Either way, the customer is bummed. There is some further information at Is there a standard procedure for refunding Bitcoin transactions?, and BIP 70 is a proposed solution (where the customer provides a separate refund address explicitly), but since this involves some out-of-band messages over HTTPS, more infrastructure is needed on the server side.
You may want to give up on delivering the product after 2 minutes, but you might not want to give up on the payment. For example, if either your machine or the customer's mobile device has Internet connectivity problems, the payment might be created but not broadcast (or not received by you) until much later. The customer is probably no longer there to get their can of Tab, but you might want to refund their money anyway. So you should keep the private key around. (Actually, there's really no good reason to discard them: if you send the money back to HQ, they normally contain no coins so it's not really a problem if they are stolen, but if somebody sends extra coins to them for some reason, you'd sure like to have them.)
Similarly, if you do send a refund, you may want to make sure you spend the same transaction that came in. This will protect you in case the customer tries to double-spend.
The payment amount can be embedded in the QR code. This saves the customer a little typing.
Quickly sending incoming payments off to HQ for safekeeping is a good idea, but will cost you a fee on each transaction. You could batch them and send them off a couple times a day, or whenever they reach some threshold amount. Alternatively, you could have a system where you generate a bunch of addresses at HQ, keep the private keys there (perhaps even offline), and just give the machine the addresses. (BIP 32 provides a fancier way to achieve that.) The machine can still detect incoming payments, but if a refund is needed, it would have to send a request back to HQ.
That sounds reasonable. I would add that since you'll most likely want to accept unconfirmed transactions, it would be also good practice to check with a list of trusted nodes (such as large mining pools) if they received the transaction. This doesn't entirely remove the risk of a double-spend, but it mitigates it.