cancel
Showing results for 
Search instead for 
Did you mean: 

CIM E00051

Hi @RichardH

 

Please escalate ticket 1-216949971.

 

When attempting a linked refund through CIM, either through the API or the Merchant Interface, it fails with E00051 - The original transaction was not issued for this payment profile. I can do it for three different profiles -- even for one which we successfully issued a partial refund for on 10/27 (the last time we attempted a refund).

 

You may recall that this problem appears and disappears every few months or so. Before, it was intermittent (retrying the request would succeed). Today, it fails on all of them, both through the API and the Merchant Interface.

npiasecki
Regular Contributor
1 ACCEPTED SOLUTION

Accepted Solutions

Update: The change worked. The merchant interface is still broken, so I honestly believe Authorize.Net has something to fix (especially considering that this problem has appeared off and on over the past year in a consistent way), but we can refund customers now. To others encountering this, don't send the customerPaymentProfileId and customerProfileId, as this seems to break from time to time. Instead, send the amount, creditCardNumberMasked, and the transId.

View solution in original post

npiasecki
Regular Contributor
7 REPLIES 7

Hello @npiasecki

 

I've asked our product support specialists to look into your report.  

 

Richard

RichardH
Administrator Administrator
Administrator

Thanks, I'm also going to try the recommendation that @martyacks posted when this last happened, and send creditCardNumberMasked instead of the IDs. https://community.developer.authorize.net/t5/Integration-and-Testing/CIM-Refund-E00051/td-p/46175/pa... That wouldn't fix the merchant interface, but if it works through the API that would be enough.

npiasecki
Regular Contributor

Update: The change worked. The merchant interface is still broken, so I honestly believe Authorize.Net has something to fix (especially considering that this problem has appeared off and on over the past year in a consistent way), but we can refund customers now. To others encountering this, don't send the customerPaymentProfileId and customerProfileId, as this seems to break from time to time. Instead, send the amount, creditCardNumberMasked, and the transId.

npiasecki
Regular Contributor

Update: Authorize.Net confirmed the issue and that they will deploy a fix on 11/12. However, I would recommend using the workaround posted above in the general case, as this issue has popped up time and again, and this seems to be a permanent fix.

npiasecki
Regular Contributor

Any updates on a fix for this issue? 

Has there been any confirmation that this has been fixed by Authorize.net?

oc_dw
Member

Hello @oc_dw

 

Yes, this specific error condition has been corrected.  However, we do recommend using the transactionID method instead of a customer profile for refunds.