PCM_OP_PYMT_PRE_COLLECT Output Can Cause a Request for Response (Doc ID 2539542.1)

Last updated on FEBRUARY 14, 2024

Applies to:

Symptoms

Output of PCM_OP_PYMT_PRE_COLLECT customized code allowed a /payinfo/invoice to be passed out of the opcode instead of a /payinfo/cc because the pay type was changed between when pin_collect retrieved the /billinfo and the opcode received it. While fixing this custom code, it exposes a weakness in the out-of-box payment processing code as follows:

1. The transaction in the batch threw an error in the connection manager (CM) and was dropped from the batch before it was sent to dm_fusa.
2. However, the CM somehow continued to think the batch included that transaction. Because as soon as the Paymentech batch response file was received in the CM, it threw an error without processing any of the batch, thus necessitating a request for response (RFR) to process the batch that could have been processed (except the single bad transaction) on the original Paymentech response. Note that the bad transaction never make it to Paymentech.

For example: 10 transactions from PRE_COLLECT with 1 of them being a bad transaction with /payinfo/invoice, thus only 9 transactions go to dm_fusa, then 9 come back. The CM does not realize it dropped 1 transaction, but continues to expect 10 transactions.


The issue can be reproduced with the following steps:
1. Create 2 monthly credit card accounts with charges due and paid.
2. Advance pin_virtual_time 1 month and execute PCM_OP_BILL_MAKE_BILL on each account.
3. Change payment type to invoice.
4. Call PCM_OP_PYMT_COLLECT with batch of 2 containing /payinfo/cc POIDs of each.
5. Customization in PCM_OP_PYMT_POL_PRE_COLLECT loads /payinfo/invoice and returns it for one of the transactions.

Cause

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