dsiEMV and PDCX Transaction Timeouts
On rare occasions due primarily to connectivity-related issues, transaction requests can timeout while waiting for a response, or timeout en route. Error responses will be returned depending on where in the transaction cycle the communication failed.
When these connectivity errors are returned it is important to handle them effectively in order to avoid potential duplicates. In these cases, the merchant is unsure whether the transaction was actually approved by the processor.
Timeout on Response
Returned if MercuryPay did not get a response from the processing back-end network
Re-run the exact transaction without incrementing theInvoiceNo.Approved/AP*indicates MercuryPay had the original request logged and the card will not be charged twice.
A standard processorAPPROVEDorDECLINEDresponse indicates that the original request was not logged.
Timeout waiting for server response
Returned if the payment application did not get a response from MercuryPay
Recommendation: Upon receiving any timeout response message, POS developers should handle an immediate retry of the transaction using the exact same invoice number, card number, and amount; then interpret the authorization response accordingly based on the above table.
// CmdResponse indicating a normal approval <CmdResponse> <ResponseOrigin>Processor</ResponseOrigin> <DSIXReturnCode>000000</DSIXReturnCode> <CmdStatus>Approved</CmdStatus> <TextResponse>AP</TextResponse> <UserTraceData></UserTraceData> </CmdResponse>
// CmdResponse indicating a duplicate transaction <CmdResponse> <ResponseOrigin>Processor</ResponseOrigin> <DSIXReturnCode>000000</DSIXReturnCode> <CmdStatus>Approved</CmdStatus> <TextResponse>AP*</TextResponse> <UserTraceData></UserTraceData> </CmdResponse>