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!

[martyacks]

@RichardHYes we can duplicate this in the sandbox.

[RichardH]

@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

[martyacks]

@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

[RichardH]

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

[martyacks]

@RichardYour help is much appreciated.

Marty

[npiasecki]

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!

[martyacks]

@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

[martyacks]

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

[testing]

Hi,

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

[alexbob]

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.