Check and Detect incoming deposits

reminder before deposits are accepted, the deposit account needs to be protected with a strong passphrase and protected with a public key the use of throwaway addresses is discouraged monitoring an account for incoming deposits using the node http api to monitor an account for incoming deposits, use the getaccounttransactions api call with the following request parameters curl request get \ url http //localhost 6876/api?requesttype=getaccounttransactions \ header 'accept application/json' \# request parameters \# account – numeric deposit account id or deposit account id in reed solomon format \# timestamp – if specified, returned transactions will be newer than this block timestamp \# type – the type of transaction, for payments this will be 0 \# subtype – the transaction subtype, for payments this will be 0 \# firstindex – for pagination purposes \# lastindex – for pagination purposes \# numberofconfirmations – to exclude transactions with fewer than the required number of confirmations set to zero, this will include all transactions, including pending transactions \# example curl request get \ url http //localhost 6876/api?requesttype=getaccounttransactions\&account=8952122635653861124\&type=0\&subtype=0\&numberofconfirmations=0 \ header 'accept application/json' we recommend you to access the node http api documentation and get more information about this api call you can access by clicking the following link http //localhost 6876/api doc/index html#get /api requesttype getaccounttransactions showing pending deposits generally, pending deposits are those deposits contained within the getaccounttransactions api call that do not meet the requirements to be credited to customer accounts these amounts can be displayed as pending until the transactions appear with the required number of confirmations in a subsequent api call response confirmations – determining when to credit a customer’s account deposits can be credited to a customer’s account after any number of confirmations, but crediting transactions immediately is not recommended for security puposes, is recommended that the number of confirmations is set to a minimum of 10 each transaction contains a deadline after which the transaction will be canceled if it is not included in a block this deadline will always be either a default of 24 hours or a custom deadline set by the transaction’s initiator to avoid complication from a transaction being canceled if its block is orphaned and its custom deadline is too short to assure that it is reincluded, further conditions based on the transaction’s timestamp and deadline parameters are recommended (either for all transactions or conditioned upon the amount of the transaction according to risk management strategy) the shorter recommendation of 10 confirmations is appropriate for transactions that have the default deadline of 24 hours these transactions are automatically reincluded in the event of a blockchain reorganization the longer recommendation of 1,440 blocks, the maximum depth of a blockchain reorganization, is appropriate for transactions with a custom deadline that is less than 24 hours after 1,440 confirmations, no combination of deadline and blockchain reorganization can cause a transaction to be canceled