It's possible that sometimes you may send a bitcoin transaction that will then seem to disappear and another transaction with a hash you don't recognize appears in its place. If you have webhook callbacks enabled, you'll even receive a notification that the transaction you sent was double spent. However, this is not due to a bug or a malicious attack, but due to transaction malleability. If you view both transactions in a block explorer, the inputs and outputs of both transactions will be the same - the only noticeable difference is that the transaction hash changes.

Until such time as a malleability fix is introduced at the protocol level (such as Segregated Witness) then services that create bitcoin transactions will need to handle it gracefully. Because malleability means that you can't rely upon a transaction hash to be a guaranteed unique identifier, BitGo's solution is that we offer a "normalized hash" value for transactions that is guaranteed to be the same even if a transaction is malleated. This normalized hash is computed by removing the source of transaction malleability (the signature data on transaction inputs) from the transaction object and then hashing it.

Application developers should take care to ensure that there is no logic in their code that uses a transaction hash as a unique identifier - only normalized hashes should be used as such. Alternatively, store the normalized hash along with the transaction hash so that if you receive notifications about unknown transactions, you can compare their normalized hashes to the hashes you already know about in order to deduplicate your records.

You can read more about transaction malleability in this blog post: