How to accept a 0 confirmations transaction

[maesitos]

We are integrating Bitcoin Cash in our business (I'll disclose the URL once it's ready in production) and the site is now waiting till the first confirmation to accept the payment. From what I understand I can trust a 0 confirmation tx if I wait long enough to know that the transaction I see is the first transaction seen by the network but I have two questions.

Would I need to look at the fee? Maybe if a fee is very low the transaction won't go throught.

Another question I have is I'm thinking of using the https://insight.is API and they include a value that says "doubleSpentTxID":null. Is this value just saying that they don't see any double spend or are they offering any type of guarantee?
Example: https://insight.bitpay.com/api/tx/81bcf ... 7b2aa26ca2

I've been reading the Blockcypher API and they offer a very clear solution on this but unfortunately they don't offer the API for Bitcoin Cash yet https://blockcypher.github.io/documenta ... firmations
Any alternative to track the double spend in a relatively secure way?

[grabberfish]

If you can see the transaction broadcast cleanly and the block explorer does not register a double-spend attempt in a few seconds after you see the transaction in the mempool, you're 99% going to be fine. Even zero-fee transactions get mined in Bitcoin Cash. Nobody will provide a guarantee on double-spend attempts, but depending on the values of the transactions you are talking about it you should consider that either it would cost an attacker more to double-spend that to pay the cost of what is being purchased, or (should this be a high value item) wait for a few confirmations. If someone is buying your house with bitcoin, offer them a cup of tea whilst you're watching the blocks come in.

There's a good post by Satoshi on BCT from back in 2010 that talks about double-spend dangers in vending machine scenarios:

I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example:

1         0
4         1
16        4
64        16
80%       20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.