It's a good question. We want Bitcoin acceptance to be straightforward for our users, so we deal with a failed confirmation on our side. We do not debit the user.
I suspect this is the reason Bitpay is able to waive fees completely: they do not take responsibility for unconfirmed transactions.
> Note: Regardless of the transaction speed settings, a fully paid invoice is credited to your merchant account after the transaction has accrued six confirmations. [1]
The problem isn't detecting whether 99% of transactions will confirm.
The problem is preventing someone from ordering $10,000 worth of gold from a site that uses Stripe with Bitcoin payments enabled. Sending a paying transaction to Stripe, who confirms it within a minute, and simultaneously mining a block with contains a transaction that double spends the bitcoins sent to Stripe.
Stripe is now out $10,000. You receive your gold, sell it to your local bullion dealer for $9,500.
Of course, for Stripe, there are various hackish ways around this problem, like defining a maximum amount of, say, $1000, so that the above attack requires the attacker to mine 10 blocks instead of 1 (ie. repeat the procedure 10 times), in order to earn $10,000.
But they don't really solve the fundamental problem of accepting unconfirmed Bitcoin transactions.
It costs 80 million dollars to buy all the hardware to mine a single block. It will probably costs 800 million dollars to amass enough computing power to mine 10 blocks. It only makes sense to double spend a transaction with a VERY large amount. No transaction going through stripe will qualify.