How to minimize risk when accepting zero confirmation payments? I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like bitundo.com around), I just want to minimize the risk.

I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)


Check if the (unconfirmed) transaction appears on my own node / in my wallet
Check if the (unconfirmed) transaction appears on sites using online APIs like blockr.io and blockchain.info
Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.


If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point? 

I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?
From
http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13, here is what services like MyCelium and BitPay may be doing:

More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can be increasingly certain that the transaction will be mined in the next block and receive one confirmation, then two, and so on and so forth.
What this means is that any Bitcoin transaction can be accepted with zero confirmations with a mathematically derived confidence level some refer to as “Transaction Confidence.”  This transaction confidence measure assures us that even if a double spend were attempted the original and correct transaction is already too heavily propagated to be overtaken.

But as you aptly noted, there is no 100% risk-free way of being able to do this if you don't trust the sender.  That's why the blockchain exists in the first place.
One risk of relying on &quot;transaction confidence&quot; is that there's nothing in the network that prevents someone from submitting a double-spend transaction directly to the miners, without broadcasting it to the network as a whole, under the agreement that any blocks that those miners find should pick their secret one instead of the one they broadcast to the network.  This is a risk no matter how much of the network sees the public transaction, which is one of the reasons why you can't have 100% confidence in a transaction that has never made it into a block.
In particular, if you accept a 0-confirmation transaction that spends inputs from other 0-confirmation transactions, the risk is much greater, because either the transaction directly to you or any of its 0-confirmation inputs could be double-spent, to your detriment.
Frankly, even 1-confirmation transactions aren't risk-free.  Even under normal circumstances, blocks get orphaned, which could create a window for double-spending, because the winning branch may not resolve the transactions the way that the losing branch did.
If you're serious about trying to minimize the risks of accepting BTC in &quot;real-life&quot; (a.k.a., brick-and-mortar) situations where speed is important, I can't think of a better idea than going with a service like Coinbase (no affiliation).  Those services operate on a scale where they can afford to eat losses from double-spends, which should be rare, so that you don't have to worry about it.  Currently, they have an economic incentive to increase adoption of the currency by being very attractive to merchants who choose to do so.