topic Re: CIM Refund E00051 in Integration and Testing

CIM Refund E00051

npiasecki — Tue, 12 Aug 2014 12:05:17 GMT

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!

Re: CIM Refund E00051

RichardH — Thu, 14 Aug 2014 20:13:04 GMT

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

Re: CIM Refund E00051

npiasecki — Thu, 14 Aug 2014 21:24:06 GMT

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.

Re: CIM Refund E00051

npiasecki — Thu, 14 Aug 2014 22:42:33 GMT

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.

Re: CIM Refund E00051

npiasecki — Fri, 15 Aug 2014 14:26:40 GMT

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.

Re: CIM Refund E00051

npiasecki — Wed, 20 Aug 2014 11:10:59 GMT

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.

Re: CIM Refund E00051

martyacks — Wed, 11 Mar 2015 19:12:49 GMT

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

Re: CIM Refund E00051

RichardH — Wed, 11 Mar 2015 21:57:39 GMT

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

Re: CIM Refund E00051

martyacks — Thu, 12 Mar 2015 10:32:31 GMT

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.

Re: CIM Refund E00051

martyacks — Fri, 13 Mar 2015 11:36:29 GMT

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

Marty Acks

Re: CIM Refund E00051

martyacks — Fri, 13 Mar 2015 11:45:55 GMT

@RichardHYes we can duplicate this in the sandbox.

Re: CIM Refund E00051

RichardH — Fri, 13 Mar 2015 14:47:45 GMT

@martyacks

Thanks for re-creating the problems in the sandbox. Our next step would be to get more details on how your system is setup, what software is involved (commercial or custom), the stpes you've taken to reproduce the problem and some transaction IDs we can review. If you've logged the request/response for these transactions, it will help us as well.

Richard

Re: CIM Refund E00051

martyacks — Fri, 20 Mar 2015 12:02:17 GMT

@RichardH We have had numerous e-mail responses saying we working on it. I also had a phone call with a "Jamie Lynn" on Tuesday, March 17th. She was very friendly. She assured me I would get a call back from "engineering" within 24 hours. That did not happen. We had similar escalation conversations two weeks ago. We have submitted multiple examples of the problem of exactly what we are sending into Authorize.Net This problem happens on every credit memo request we initiate through the API interface. It has been happening since January consistently.

The ongoing e-mail follow up always come from a different person and are generally vague and non-responsive. We have requested a single point of contact. to resolve this matter. (We have gotten e-mails from Nathan, Brandon, Julius, Kristi, and others). It appears they just read the latest thread and quickly respond and move on without looking at the backgound of the issue. Our request had been declined. All the details are in the call 1-132325771 or 1-132928515.

Here is the latest that I asked for on March 14th, I have not got a reasonable response to this question. "What we really need is to have you look at this SPECIFIC transaction on your system and tell us EXACTLY what Authorize.Net is seeing that different on the credit we are submitting for the original sale for this SPECIFIC example. You have agreed to have your engineering team look at this matter. I see no evidence that has happened. Please do not respond generically again that there is mismatch in the data. Please do not respond to this message suggesting we do this through the Authorize.net payment portal. We knows it work there. The requirement is that this credit works through the e-commerce application."

What do you recommend as next steps?

Marty Acks

Re: CIM Refund E00051

RichardH — Fri, 20 Mar 2015 18:12:59 GMT

Hi Marty,

I'm coordinating with our product support specialist teams to look at your issue to ensure it receives the proper attention. Thanks for providing the details for your service requests.

Richard

Re: CIM Refund E00051

martyacks — Fri, 20 Mar 2015 20:24:53 GMT

@RichardYour help is much appreciated.

Marty

Re: CIM Refund E00051

npiasecki — Mon, 30 Mar 2015 19:46:57 GMT

Hi @martyacks we've had the same issue in August and started up again in January, had ticket 1-86594811 reopened since then and had the same issue where they weren't convinced they had a problem until I uploaded a video of me creating it on their web site ... checked in with them today and they say they're working on it, just letting you know that you're not alone!

Re: CIM Refund E00051

martyacks — Mon, 30 Mar 2015 21:24:00 GMT

@npiasecki Wow. The timing matches ours also. Did you send the video to authorize.net support e-mail? Ours occurs as part of an e-commerce transaction so a video on the Virtual Terminal would not work. Is that what you sent? We have submitted more detailed logs that show exactly what we are sending via SOAP. I've had numerous people working on this at Authorize.Net, theres has been some frustration with very friendly we are working on it messages and aksing for the same information multiple times. The moderator at this board Richard is also helping expedite but just found out he is out of office for a week. Feel free to contact me if you want more details at martya @ cditechnology . com.

Marty Acks

Re: CIM Refund E00051

martyacks — Thu, 16 Apr 2015 17:36:54 GMT

RichardH, one of the moderators here, was able to bring very knowledgable resources to the table to resolve the refund/credit problem finally.

We ended up using a different approach to issuing refunds. We were using the approach described on page 47 in the Merchant Web Services API Customer Information Manager (CIM) SOAP Guide (March 2015 edition) for previous CIM transactions.

The original guidance we followed was this:

- include customerProfileId, customerPaymentProfileId, and transId.

- customerShippingAddressId is optional.

- creditCardNumberMasked, bankRoutingNumberMasked, and bankAccountNumberMasked do not need to be included, but they will be validated if they are included.

This worked fine until January 2015. It stopped working for some reason.

We changed to use this approach that is suggested just below there. (This supposed to be for non_CIM transaction):

- you must include transId, creditCardNumberMasked (or bankRoutingNumberMasked and bankAccountNumberMasked).
- do not include customerProfileId, customerPaymentProfileId, or

- customerShippingAddressId

It is now working for our customer! Thanks again!

Marty

Re: CIM Refund E00051

testing — Thu, 16 Jul 2015 10:28:50 GMT

Hi,

I have one question for refund can that particular transaction's status "Settled"?

Re: CIM Refund E00051

alexbob — Wed, 10 Nov 2021 00:18:37 GMT

I have a similar problem. There is an open ticket for Authorize.Net on this subject. You will see the exact same message. I was asked for the same information several times. I just want Authorize.Net to tell me that they consider their side different. Provided what to send in approval, capture, and credit events. I believe the information is consistent.