Why Does a No Answer Response Code Generate a Payment Event (with Vendor Results) During RFR
(Doc ID 2548157.1)
Last updated on SEPTEMBER 19, 2019
Applies to:Oracle Communications Billing and Revenue Management - Version 18.104.22.168.0 and later
Information in this document applies to any platform.
Normal payment processing (pin_collect for example) generates a charge event, a payment event, and even a failed payment event when applicable.
However, when the Paymentech response code is 301 or anything mapped to PIN_CHARGE_RES_FAIL_NO_ANS(1), the charge event is completed (with result = 1) but no payment or failed payment event is generated.
However(2), if said NO_ANS condition occurs with a transaction processed in an RFR (Request For Response) batch, payment and failed payment events are generated.
This seems to be an inconsistency between normal and RFR batch processing.
RFR processing means that Paymentech did receive the batch and thus it is assured that the NO_ANS condition is the result of Paymentech getting no answer from the bank, not that dm_fusa getting no answer from Paymentech.
There should be some way for the original batch processing to detect the difference between those 2 conditions, (1) and (2), if only dm_fusa would tell the CM which pertained for that batch.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document