[See Part 1 here.]
[See Part 2 here.]
In this third and final piece, I was concerned about originating application writers not understanding that transaction result, card security code result and address verification result must be evaluated separately. So, I wrote this additional piece entitled “Transaction Response Processing Notes.”
----------------------------------
Special attention must be paid to the relationship between the three result code fields: gw_result_code; gw_avs_result_code; and gw_csc_result_code. These are separate results. The originator must examine and evaluate each of them. Neither a mismatched CSC nor a mismatched is necessarily a cause for a DECLINED transaction. In practice, we have seen:
a) APPROVED transactions with matched CSC and matched AVS
b) APPROVED transactions with mismatched CSC and matched AVS
c) APPROVED transactions with matched CSC and mismatched (or partially matched) AVS
d) APPROVED transactions with mismatched CSC and mismatched (or partially matched) AVS
e) DECLINED transactions with matched CSC and matched AVS
f) DECLINED transactions with mismatched CSC and/or mismatched AVS (where the DECLINE is unrelated to the mismatch(es)).
g) DECLINED transactions with mismatched CSC (where the DECLINE is related to the mismatch – a case in which the authorizer has opted to take decision-making out of the originator’s hands by escalating the mismatch to the status of a hard decline).
Other, less frequently seen use cases involve responses indicating that the CSC and/or AVS were not processed – either because the issuer/authorizer does not support the service (a non-transient condition); or, because the service in question is temporarily unavailable (a transient condition).
In cases (b) through (d) – indeed, in any case in which the transaction is APPROVED but the submitted CSC and/or address results in anything less than a match – the originator faces a decision as to how to proceed. This is a decision that cannot be made unilaterally by the implementation team. All actions at this point must be in accordance with processing rules conveyed by the business or application owner.
Let’s take case (b) – APPROVED with mismatched CSC – as an example. Possible actions that can be taken by the transaction originator after evaluating the response include:
Accept the transaction as an approval – In doing so, the organization accepting the transaction forfeits certain chargeback rights.
Request that the customer re-enter their CSC – Before resubmitting the transaction with the new CSC, the originator must submit a void to cancel out the effect of the previous transaction.
The matter of business rules comes into play here – the transaction owner will surely not want the customer to have the freedom to spin through 100 attempts at getting the CSC right. Each business must establish a policy to determine the appropriate number of re-attempts. Authorizers like American Express enforce a policy from the other end by escalating mismatched CSCs to a hard DECLINE on a third consecutive, failed attempt with the same card.
Deny the transaction – The organization may decide to let the mismatched CSC trump the APPROVED decision. A typical policy may be to allow a limited number of shots at a re-entered CSC before deciding to overtly deny the transaction. Should this decision be taken, the originator must submit a void to cancel out the effect of the previous transaction.
Recent Comments