No. Imagine that it is like sending bunch of bitcoin to an "M of N address" before the actual tx. To perform actual tx, your and some trusted parties private keys are needed. So you make tx with specified output at will. Because a merchant trusts those parties won't make double spend, he doesn't need to wait for confirmation.
T = trusted party
C = customer
M = merchant
SetupC sends 1 BTC to pay if signed by T & C
<time passes>
Single SpendC goes to M and spends T&C coin
M accepts transaction since M trusts T
M sends transactions to T for the 2nd signature
<wait 24 hours>
T signs and broadcasts transaction (tx sends money to M and fee to T)
Double SpendC goes to M1 and spends T&C coin
M1 accepts transaction since M trusts T
C goes to M2 and spends T&C coin
M2 accepts transaction since M trusts T
M1 sends transactions to T for the 2nd signature
M2 sends transactions to T for the 2nd signature
<wait 24 hours>
T detects double spend and says he can't sign either transaction
T, M1 and/or M2 calls law enforcement
M1 sends 50% of the tx value to M2.
After M1's transaction is 10 deep on the chain, T signs M1's version of the transaction
-----------
This way the double spender can't get his money back. Both merchants get 50% of their money refunded and law enforcement can be contacted.
If T has an always-on server, both M1 and M2 could submit their transactions for signature immediately. The first one would be accepted, but when M2 sends his version, the T will refuse.
The fee could be included in the original transaction to sign.