By default there is no way for a merchant to prevent a double spend whilst a transaction is in 0-conf state.
Lets assume for a second that all miners are simply motivated by fees and do not observe default mining policy (i.e. First Seen Safe (FSS), RBF-FSS and friends...) and continue to accept transactions that contain spent UTXOs. If you think about it that way, there are methods for a merchant to incentivise miners to favour the original transaction over the double spend transaction.
The merchant may elect to use a CPFP (Child pays for parent) transaction to increase the value of all subsequent transactions that are dependent on the preceding transaction that is being double spent. By doing so, miners will be incentivised to accept the original transaction over the double spent transaction.
The CPFP method is only effective contingent on the acceptance of the preceding transaction, so it may not work if the entire Bitcoin network only implements FSS as there would be an inherent inconsistent state of unconfirmed transaction (i.e. some partition of nodes P1 might think that the double spend is the valid transaction; while the other partition P2 might think the original transaction is the valid transaction).
In summary, to date, there are no known methods to accept zero-confirmation transactions due to how the reference client is implemented as it will reject transactions that contain spent UTXOs. So either the doublespent transaction will be accepted or the original will be accepted.