Why Does a No Answer Response Code Generate a Payment Event (with Vendor Results) During RFR (Doc ID 2548157.1)

Last updated on OCTOBER 04, 2023

Applies to:

Goal

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.

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.