- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
โ11-05-2015 12:35 PM
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ11-05-2015 01:09 PM - edited โ11-05-2015 01:11 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ11-05-2015 12:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ11-05-2015 12:52 PM - edited โ11-05-2015 12:52 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ11-05-2015 01:09 PM - edited โ11-05-2015 01:11 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ11-10-2015 03:16 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any updates on a fix for this issue?
โ11-13-2015 10:59 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Has there been any confirmation that this has been fixed by Authorize.net?
โ01-21-2016 11:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ01-22-2016 12:19 PM