DPM MD5 to SHA512, relay response not redirecting

[phpsmith]

Hello all,

We have a fairly legacy system (C#) running DPM with MD5 hash, with the recent news we moved the MD5 to SHA512, and everything seemed to still be working fine.

We implemented the SHA512 hash under this guide:

https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD...

We did have query parameters in our x_relay_reponse url, but that never seemed to be problem. We were getting successful sandbox transactions just yesterday with the query parameters before the MD5 cutoff on the sandbox. Our query parameters include a session id and step, 

Now that MD5 is no longer returning on the sandbox environment, we went with another test to make sure it was working, and now the transaction is getting approved but not returning.

My questions are, with DPM, do I need to have x_SHA512_Hash or have the SHA512 hash on the x_fp_hash?

Also, it seems like with either hash method, the transaction will go through and get approved but not return.

Anyone else on DPM experiencing anything like this?

[Renaissance]

The x_fp_hash will work with either hash as of now. Authorize will recognize which hash you are using based on the number of characters in the string. If you have sha512 working I say keep using that because at some point md5 is probably getting deprecated.

With your relay response, have you successfully validated using sha512 on any one transaction? If you have then your relay response may be the issue. What I have found with the relay response is that it cannot be set dynamically. The API call has to match what is in the interface. Keep in mind that I have only worked on one SIM/DPM integration and it was this past week. So something may have indeed changed since you have been using it.

My client actually swore the same thing, that a dynamic relay url was working before. I set the app back up with md5 response validation and the dynamic relay url still wouldn’t work. So it has nothing to do with which validation you are using (other than the fact that as of yesterday md5 was axed). What we ended up doing is setting up a dynamic receipt url and turning off the relay response. It has a button that my client doesn’t like but it’s all we could do.

My advice to you would be to give up on a dynamic relay url. This is based on several hours of hair pulling on my part trying to get one to work in every conceivable way I could think of. If you do keep trying and figure out how please post it here though. I’d really like to see it be done bc I’m not sure that it can be.

[Renaissance]

We did get a response however. In both cases our dB updates were happening. The response was getting validated it was just that the parameters on the url were being ignored. On her application the ignoring of the parameters caused the customer to see a page that said “done with errors” and had several other errors. So the decider for you is have you ever validated a sha512 response. If yes, it is your relay url, if no it’s your validation failing. That’s my wager.