This document provides a brief overview of the Transaction Manager’s processing of the PAReq with specific focus on the processing of duplicate PAReqs.
One can encounter a replay or duplicate transaction while reviewing transactions inside CA transaction manager. A transaction is termed as duplicate or replay when the same exact Payer Authentication Request is posted to CA Transaction Manager more than once.
Steps in PAReq Processing
When a PAReq is received by the ACS (Access Control Server), it is validated:
- Against both the PAReq specifications for structure and content; and
- Against the VEReq for content and validity
The validation against VEReq is primarily based on the card number and transaction proxypan.
As part of the database record keeping, one database record is maintained for each VEReq received and one database record for each PAReq received by the system. The VEReq and the PAReq records can be jointly interpreted based on the transaction proxypan field.
As part of the PAReq processing, transaction risk evaluation is undertaken with provides for the risk score of the current transaction.
Steps in 'Duplicate PAReq’ Processing
Duplicate PAReq scenario kicks in when more than one PAReq is received for a given VEReq. It should be noted that there is no way to know on PAReq receipt whether additional (duplicate) PAReqs would be received later and there is no way to restrict the receipt of these multiple/additional PAReqs.
When a PAReq is received and validated against the VEReq, the system can immediately identify if the received PAReq represents the first PAReq for that VEReq or it some other PAReq had been received for this one prior to the current PAReq.
On identification of the PAReq as a ‘duplicate PAReq’, the system checks the database to locate any PARes that might have been already relayed; if one is found, the system skips the actual processing of the received PAReq and relays the same PARes value as before and simply creates a PAReq database record pointing to the original processed PAReq entry (to indicate that the latter contains the PARes value).
In scenarios, wherein the PAReq is identified as a ‘duplicate PAReq’ but there is not PARes readily available in the system database, the received PAReq is allowed to be processed further, in effect competing with any previous PAReq that might be in a different stage of processing. However, multiple additional system checks are done to see if any competing PAReq has completed its processing and any PARes value generated. If at any stage, the system locates that at least one PAReq has completed processing and PARes value is ready, processing of other PAReqs is suspended in favor of the completed PAReq. The system then relays the same PARes value as before and simply creates a PAReq database record pointing to the original processed PAReq entry (to indicate that the latter contains the PARes value).
The system checks for PAReq processing is undertaken at the following stages:
- Classification of a PAReq as ‘duplicate PAReq’
- Prior to invocation of the transaction risk evaluation
- Prior to generation and relay of OTP (in case of user authentication challenge flow)
- Prior to validation of user-entered OTP (in case of user authentication challenge flow)
- After completion of the PAReq processing and before PARes is constructed