Authorize.net CIM - "The original transaction was not issued for this payment profile" when trying to issue a refund

[jasonfb]

We're getting "E00051 - The original transaction was not issued for this payment profile" when trying to issue a refund on some (not all) of refund transactions.

The docs say "If the customer profile ID, payment profile ID, and shipping address ID are included, they must match the original transaction"

Digging into it a little, I have determined that what is happening here is that the shipping address being sent for the refund transaction is not the same as the shipping address that was originally sent for the transaction.

Has anyone seen this before?

[jasonfb]

We're on Spree & Spree gateway 2.1

[jasonfb]

I think this is related to #174 ?

Seems like the same root cause.

[jasonfb]

I'm still digging into this, trying to parse out what is going on. Although I do not have a specific root cause right now, please keep issue open until I have it fully investigated.

I noticed a change between 2.1 and 2.2

notice line 117 -- see how it is commented out in Spree 2.1

https://github.com/onedanshow/spree_gateway/blob/2-1-stable/app/models/spree/gateway/authorize_net_cim.rb#L117

but not in spree 2.2...

https://github.com/onedanshow/spree_gateway/blob/2-2-stable/app/models/spree/gateway/authorize_net_cim.rb

Does this line mean that when a CIM profile is created it is always created in Spree 2.1 it is always created without a billing address?

[JDutil]

Appears it is always created without a shipping address in 2.1.

[jasonfb]

Interesting. Seems related (in fact if not the same as?) #174 ?

I haven't debugged it deeply (in fact, it's pretty hard to since to recreate it I need to hit the actual Production gateway), maybe the original create profile creates a CIM credit card without a shipping address, and when the refund transaction goes through it then uses an address? This would cause the symptom.

We are upgrading to Spree 2.2 on Saturday morning, so I will keep an eye on this to see if the root cause is addressed there.

[JDutil]

Yea it does sound like the refund gets the address sent, but since it's not properly sent during the payment due to 174 it causes the mismatch. Let us know if upgrading to 2.2. helps.

[jasonfb]

We are still working on this, and we are still seeing these in Spree 2.2. However, my current working hypothesis is that this is caused by our code, not Spree code.

Either way I will leave documentation here for others (and close if it is in fact caused by our code)

[tamagokun]

I've had this problem occur only once in production when trying to do a refund, and it seems to be a confirmed bug after ticket placed with auth.net. Here's the response:

---

"Reviewing the code provide we see the merchants system is using an older method of submitting refunds using profile ids. There is a bug that has been identified with the two calls they are using createCustomerProfileTransactionRequest and profileTransRefund. This is also an older way of submitting refund/credit transactions.

The issue will appear only if these conditions are met:

The original transaction is an auth only
The prior auth capture transaction follow-on request is sent with NO profile ids
The refund is sent with profile ids.
It is recommended to use createTransactionRequest and provide the transaction id like in the example provided here: http://developer.authorize.net/api/reference/index.html#payment-transactions-refund-a-transaction"

---

Does ActiveMerchant even use any of their newer APIs?

[jasonfb]

Does ActiveMerchant even use any of their newer APIs?

AFAIK, no.

[tamagokun]

Oh no doubt, it's really frustrating having to deal with auth.net after using Braintree or Stripe for so many other projects. Client wanted to use auth.net since they were using it before, but I don't think they'll want to pay for me to update old code. We already use Braintree for Paypal express payments, so I think its time to recommend using Braintree for CC as well.

Thanks for the feedback. The fact that auth.net says there is a bug but then recommends ME to update code on my end is nuts. They should fix their product, right?

[tamagokun]

Makes sense! Thanks again