| Double Credit Card Auth in iPayment [message #280461] |
Tue, 13 November 2007 13:46 |
smittyexp
Messages: 1
Registered: November 2007
|
Junior Member |
|
|
Our current Oracle apps is 10.5.9. The current problem cropped up when migrating from 9i to 10g a couple months back.
We use iPayment with PaymentTech for automated credit card processing. We don’t auth credit cards until right before pick release in the warehouse. The auth is stored in the IBY tables (IBY_TANGIBLE, IBY_TRXN_SUMMARIES_ALL, and IBY_TRXN_CORE). The auth is getting done.
The data is temporarily stored in RA_INTERFACE_LINES_ALL to be uploaded into AR to create an invoice. The problem with the RA_INTERFACE_LINES_ALL table is that the APPROVAL_CODE field is always getting populated, but for some of the rows, the field PAYMENT_SERVER_ORDER_NUM, which is the foreign key back to IBY_TANGIBLE.TANGIBLEID, is not getting populated. So, when it gets pulled into AR, since it doesn’t see the foreign key back to the IBY tables (PAYMENT_SERVER_ORDER_NUM), it goes and does a second auth as well as a capture. It doesn’t do a capture on the first one.
So, we have two auths, one capture on the second auth, and our clients’ credit cards sitting there with the first auth and no capture, which holds funds up on their credit card for seven days.
This doesn’t happen on all credit card auths. It is random and without any pattern.
Currently we have a temp fix in an hourly process that searches for rows in RA_INTERFACE_LINES_ALL where APPROVAL_CODE is not null and PAYMENT_SERVER_ORDER_NUM is null and then populate the PAYMENT_SERVER_ORDER_NUM via a join through OE_ORDER_HEADERS_ALL into IBY_TANGIBLE.
The only pattern that can be seen is with a couple of the date fields in the IBY_TRXN_SUMMARIES_ALL table. The pattern follows if the UPDATEDATE is earlier than the REQDATE. And, on a lot of these, the UPDATEDATE is almost always 12:00:01 a.m. on the same day of the REQDATE.
Just curious if anyone else has seen this and/or if you can direct me towards anything in particular. The company has tried to keep as much Oracle Standard code around without modifying it. And, like I said, this was not a problem before 10g, but now it is.
Thanks in advance,
Don Schuette
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
