RFR Processing Has Data Integrity And Uncontrol Issues (Doc ID 987694.1)

Symptoms

When deposits, conditional deposits or refunds require RFR(Request For Response) processing because the original batch failed and was left in checkpoint state, the business policies executed by the RFR act much differently than the original batch results would have, and in fact cause data integrity issues under certain circumstances.

-- the expected result:
RFR processing supports all documented business policy hooks and maintains data integrity.

-- the actual result :
(A) In the case of PCM_OP_PYMT_APPLY_FEE, all the transactions appear to be successful but in each test case one of the transactions was a decline. No credit card decline fees are generated during RFR processing.
(B) In the case of PCM_OP_PYMT_POL_COLLECT, there are no amounts reported, so for the deposits and refunds the opcode errors out. No actions are executed during RFR processing.
(C) Charge events have result 0 even if associated payment/refund events were not generated (will be the case for conditional deposits as well if those payment events fail to generate, though this was not produced in the test data provided). Charge events indicate success (result 0) but payment/refund events are created (if created) in a separate transaction, giving a corrupted result wherein there seems to be no checkpoint or payment recovery required but something of that sort may still be needed.

-- Steps To Reproduce:
Assumption: Paymentech simulator is configured to pass both CC#s below for authorization but fail the 5442* one for batches.

1. Install BRM with Paymentech Data Manager and requisite patch set.

2. Set simulation_level to 1 in $PIN_HOME/apps/fusa_server/pin.conf and fusa_batch_timeout to 10 seconds in $PIN_HOME/sys/dm_fusa/pin.conf, then bounce dm_fusa and answer processes.

3a. Create account with credit card 4444111122223333, credit $103, then generate refund item for it.
3b. Create account with credit card 5442986666666032, credit $45, then generate refund item for it.
3c. Create trigger to block charge events from exiting 999 checkpoint.
3d. Execute "( cd $PIN_HOME/apps/pin_billd && pin_refund -active -pay_type 10003 -vendor fusa -verbose )".
3e. Drop trigger.
3f. Execute "( cd $PIN_HOME/sys/dm_fusa && cp -p $(ls -t1 fusa_temp/fusar* | head -1) rfr_refund.file )".

4a. Create account with credit card 4444111122223333, then top-up $167 on it.
4b. Create account with credit card 5442986666666032, then top-up $28 on it.
4c. Create trigger to block charge events from exiting 999 checkpoint.
4d. Execute "( cd $PIN_HOME/apps/pin_billd && pin_deposit -start +0 -pay_type 10003 -vendor fusa -verbose )".
4e. Drop trigger.
4f. Execute "( cd $PIN_HOME/sys/dm_fusa && cp -p $(ls -t1 fusa_temp/fusar* | head -1) rfr_deposit.file )".

5a. Create account with credit card 4444111122223333, including purchasing some services, then bill now.
5b. Create account with credit card 5442986666666032, including purchasing some services, then bill now.
5c. Create trigger to block charge events from exiting 999 checkpoint.
5d. Execute "( cd $PIN_HOME/apps/pin_billd && pin_collect -active -pay_type 10003 -vendor fusa -verbose )".
5e. Drop trigger.
5f. Execute "( cd $PIN_HOME/sys/dm_fusa && cp -p $(ls -t1 fusa_temp/fusar* | head -1) rfr_collect.file )".

6. Execute "pin_clean -summary". There should be 2 checkpoints for each of the 3 batch types.

7a. In $PIN_HOME/sys/dm_fusa, copy rfr_deposit.file to rfr.file.
7b. Execute "pin_recover -rfr -pay_type 10003 -vendor fusa -verbose".

8a. In $PIN_HOME/sys/dm_fusa, copy rfr_collect.file to rfr.file.
8b. Execute "pin_recover -rfr -pay_type 10003 -vendor fusa -verbose".

9a. In $PIN_HOME/sys/dm_fusa, copy rfr_refund.file to rfr.file.
9b. Execute "pin_recover -rfr -pay_type 10003 -vendor fusa -verbose".

Looking at the collect accounts, the payment events are correct, i.e. good card gives payment and bad card generates zero payment event.

Looking at the deposit accounts, however, the deposit charge events on both accounts show zero (0) result but there are no payment events associated with the charge events.

The refund accounts also have charge events showing zero (0) result but there are no refund events associated with the charge events.

Looking in the cm.pinlog, one see that after RFR processing, neither of the opcodes PCM_OP_PYMT_APPLY_FEE nor PCM_OP_PYMT_POL_COLLECT get sufficient information to process correctly.

Changes

Cause

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