checkStatus

checkStatus and checkStatus2

The checkStatus method will return the json transaction response to any transaction provided you know the RefId. It’s meant to be used when you don’t receive a response due to a network issue or browser crash.It is HIGHLY recommended to run a checkstatus PRIOR to allowing the next transaction to finalize or update any pending transactions if a response has not been received.

Additionally, we have added a flag to the response, ResultFinal, which indicates if the response you received is the end result. In cases of comm failures with the terminals, this value could be false. We recommend calling checkStatus at regular intervals when the ResultFinal flag is false. On some terminals, we are able to inspect the terminal to find out if the transaction was approved, provided it is back online. Please keep in mind that if the terminal is offline, the response won’t change and you probably don’t want to keep polling forever. If possible, it’s best to check every minute or so in the background so other functions can be done on the POS. Do not constantly invoke the CheckStatus call in a continuous loop without pauses, this will cause alerts and your API credentials will be revoked. The max interval  is every 5 seconds for 3 minutes and every 30 seconds thereafter.

The RefID for the original transaction must have been passed to us in the initial request in order to use this feature.

Command=Sale, Refund, Auth etc
refID=refID of the transaction you are looking for the response on
date= date of the transaction in MMddYYYY format, ie. Jan 19, 2016 would be 01192016 – US Central tiimezone

The only reason to use checkStatus2 is if you are using multi-mid applications in the terminal. Nothing else is different for the 2 calls except that checkStatus2 accepts a merchantId value.

HTTP Request – checkStatus

HTTP Request – checkStatus2

JSON Response (standard transaction response fields)