How does the reference bitcoin wallet/client handle rejected transactions? (in the API) I'm working on writing a wrapper for the standard bitcoin client. I'll be communicating with it via the JSON-RPC API and I'm just wondering if anyone has any experience with this;
this app is mostly geared to receive BTC, not send.

How does the client react when it sees an incoming transaction from an address of x BTC, but it is later determined by the network that that transaction was invalid (probably due to a double-spend by someone sending BTC to an address, then immediately sending the same BTC to another address but from a far away play so the lag allows both to go through. In this case I'm talking about transactions before a block is mined)

Does the transaction just disappear off the network and away from the bitcoind interface/API or is that recorded somewhere? (In the confirms result in the API?)

I want my app to be able to keep track of any instances of this happening and notify the end user.

Thanks.
With Bitcoin-Qt/bitcoind there there is no callback or other real-time notification that a transaction that had previously been a valid 0/unconfirmed is not a transaction that will not confirm due to there being another confirmed transaction for the same unspent transaction output (UTXO).

When a new block is found, each transaction can be inspected (using Raw transactions) to determine the INPUT(s).   If the input was already used by a previously seen transaction, then the spend from the block would cause the earlier transaction to be an invalid double spend and it can be purged.

The Bitcoin-Qt/bitcoind client will no longer display the 0/unconfirmed transaction for a payment received that becomes invalid after a double spend from a new block arrives.