Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorize.Net is phasing out the MD5 based transHash element #674

Closed
BenParizek opened this issue Jan 31, 2019 · 1 comment
Closed

Authorize.Net is phasing out the MD5 based transHash element #674

BenParizek opened this issue Jan 31, 2019 · 1 comment
Labels
ℹ️ status: need more info When waiting for user to supply database or more information.

Comments

@BenParizek
Copy link
Contributor

BenParizek commented Jan 31, 2019

Description

The general question: Do Craft Commerce 1 users on Craft 2 using the Authorize.Net gateway need to do anything to keep Craft Commerce working after the upcoming MD5 based transHash element change?

For more context, Authorize.Net has shared the following news:

Authorize.Net is phasing out the MD5 based transHash element in favor of the SHA-256 based transHashSHA2. The setting in the Merchant Interface which controls the MD5 Hash option will be removed by the end of January 2019, and the transHash element will stop returning values at a later date to be determined.

We have identified that you have this feature configured and may be relying on MD5 based transHash in transaction responses for verifying the sender is Authorize.Net.

Please contact and work with your web developer or solutions provider to verify if you are still utilizing MD5 based hash and if still needed to move to SHA-256 hash via Signature Key.

It seems that a lot of people are getting surprised by this message this month as the date it goes into effect is tomorrow. A related OmniPay ticket seems to be here: thephpleague/omnipay-authorizenet#123

And someone in that thread might be saying that it won't have an effect: If you do not upgrade the hash, this should not have any effects on your payments. (As we use non-hosted CIM)

Luke followed up with me on Slack and said:

We are aware, but getting conflicting reports on what we should do. Will keep watching of the omnipay repo.

Also noticed the DPM and SIM callbacks do not do a signature check on what is received from the gateway. I think when this was first written, there were no signatures at all. Then there was an md5 signature, and we didn't notice the change, and now that is being withdrawn in preference for the SHA-512 signature (which we don't use anyway - we should though).

TBH the documentation is pretty poorly managed, with mistakes and stuff missing all over the place, so it is easy to miss changes as they happen. Try to find your way to the webhook details from the new API reference? Yes, there are webhooks, and it's not even obvious. I can't find the details without stepping back into Google search. Stuff missing - I was trying to add the driving license model to the payment, and it's not in the docs at all. Makes me wonder what else is missing. Mind, many gateway docs are like this. It's frustrating.

@lukeholder lukeholder added the ℹ️ status: need more info When waiting for user to supply database or more information. label Jan 31, 2019
@lukeholder
Copy link
Member

Look like for those customers on the older MD5 hash the requests are continuing to work.

Closing this for now, unless we get reports of payments being rejected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ℹ️ status: need more info When waiting for user to supply database or more information.
Projects
None yet
Development

No branches or pull requests

2 participants