CIM Refund E00051

[npiasecki]

I first noticed it yesterday, but it seems sometimes when doing refunds in production, we're receiving an E00051 error saying that "The original transaction was not issued for this payment profile."

However, when we try the same action again, the refund succeeds, so the issue is intermittent.

Captures of previous authorizations don't seem to be effected. It's only refunds where the intermittent error occurs, and since refunds have to be settled at Authorize.Net, it's a little difficult to track down.

I've contacted customer support, but is anyone else seeing this behavior, or have any ideas of what could cause it? We haven't made any recent changes to the payment processing part of our codebase. Thanks!

[RichardH]

Hello @npiasecki 

Are you still experiencing this problem?  Are you able to duplicate in the sandbox?

The most common reasons for this error is if the profile ID, the payment profile ID and the shipping ID do not match the original transaction.

Richard

[npiasecki]

Yes, it's still happening. It looks like it started happening August 7th; no refunds were done August 6th, and August 5th shows no errors. What has me scratching my head is the second attempt seems to always succeed. I'm not able to reproduce it in the sandbox. I have a ticket open with customer support.

[npiasecki]

Update: I can recreate the same issue (first attempt yields "The original transaction was not issued for this payment profile", second attempt succeeds) in the Authorize.Net Web site using Tools - Customer Information Manager. So that tells me it's not on my end? Sent that info to support.

[npiasecki]

Update 2: I can confirm this behavior (fails on the first try, succeeds on the second try)

- in both the CIM API and via the Authorize.Net Web site using Tools - Customer Information Manager

- in three different Authorize.Net gateway accounts

so it is not isolated to our single gateway account.

[npiasecki · Accepted solution]

Update 3: This problem seems to have gone away with the update they did Saturday, August 16th. I haven't seen the problem since then. Never got a response from Customer Support in over a week, but somehow I am not surprised.

[martyacks]

We are having a simiilar problem. We have an open ticket with Authorize.Net on thsi matter. We are receiving the same exact message. This started happening in early January 2015. It happened on a system that  has not been changed for over 6 months. We have been asked for the same infomation multiple times. We just want Authorize.Net to tell us what they see as different on their side.  We have provided what we are sending on the Authorization, Capture, and Credit events. We believe the information matches.If we need to make a change we are very open to do that. We just do not what to change at this point.

We had the same problem last year and it just went away after 6 weeks or so.

Has anyone had similar problem recently and what was the resolution?

Marty Acks

[RichardH]

Hello @martyacks 

If you can provide the Service Request number, I can check on it.  If you wish, you can share timestamps, transaction IDs, etc.  The more information you provide the more we can try to reproduce the issue.

Can you reproduce this in the sandbox?

Richard

[martyacks]

Thanks. This getting quite heated at the moment.  The Service Request is # 8842-469053771-5067. Hopefully your call tracking system has all the details of the logs we have sent. If not I can add them here.  I will check with the team on being able to duplicate in the sandbox.   

[martyacks]

We did get suggestions from the Authorize.Net support team yesterday. We are trying those today. 

Marty Acks