topic Re: x_SHA2_Hash missing in silent post for void/refund transactions in Integration and Testing

x_SHA2_Hash missing in silent post for void/refund transactions

tchamness — Tue, 12 Mar 2019 15:22:07 GMT

While converting some existing software to use the new hash method we encountered a problem where x_SHA2_Hash is not being populated in the silent post request when the transaction is voided or refunded. It is populated as expected when the transaction is originally submitted.

I'm trying to determine whether this is a configuration issue, a bug, or intentional behavior? Is anyone else able to replicate this behavior?

(This is on the sandbox environment)

Partial contents of the silent post for the original transaction:

'2019-03-12 3:05:52 pm UTC'
  array (
    'x_response_code' => '1',
    'x_response_reason_code' => '1',
    'x_response_reason_text' => 'This transaction has been approved.',
    'x_avs_code' => 'Y',
    'x_method' => 'CC',
    'x_card_type' => 'Visa',
    'x_account_number' => 'XXXX1111',
    'x_invoice_num' => '10488',
    'x_type' => 'auth_capture',
    'x_amount' => '11.00',
    'x_MD5_Hash' => '',
    'x_SHA2_Hash' => 'AF85966DFC3021C341CA3AF4FCBBC0E973E3AE810385B29AB7825A4265BAE59D5BC5299CCF1D2ABFA298D9FBED619513C012C9931261059E86634F26E09523D3',
    'x_cvv2_resp_code' => 'P',
    'x_cavv_response' => '2',
    'x_test_request' => 'false',
  ),
)

Partial contents of the silent post for the void:

'2019-03-12 3:06:38 pm UTC',
  array (
    'x_response_code' => '1',
    'x_response_reason_code' => '1',
    'x_response_reason_text' => 'This transaction has been approved.',
    'x_avs_code' => 'P',
    'x_method' => 'CC',
    'x_card_type' => 'Visa',
    'x_account_number' => 'XXXX1111',
    'x_invoice_num' => '10488',
    'x_type' => 'void',
    'x_amount' => '0.00',
    'x_MD5_Hash' => '',
    'x_SHA2_Hash' => '',
    'x_cvv2_resp_code' => '',
    'x_cavv_response' => '',
    'x_test_request' => 'false',
  ),
)

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Tue, 12 Mar 2019 17:52:16 GMT

Can't say much about this one other than that for modern API integrations the hash comes back on everything. So it may well be a bug. If you have backend scripts executing for refunds and voids it's kind of an issue.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Wed, 26 Jun 2019 06:42:36 GMT

I can confirm the exact same behaviour, whereas previously MD5 hashes had worked since my software only needed to monitor voids/refunds.

I'm using AIM for transactions which end up voided/refunded, if that helps.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Wed, 26 Jun 2019 15:28:16 GMT

@msykes

You are using Silent Post for AIM? I would simply disable hashing because you’re over a TLS encryption with AIM.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Sat, 29 Jun 2019 12:36:46 GMT

@Renaissance thanks for the reply, yes it is via AIM.

Do you mean disable hashing to receive a refund/void notice? I don't use hashing to send payment info of course, but I think some sort of verification would be prudent. This is for distributed software, so I can't take the risk on behalf of 1000s of individual clients.

Is this an official stance from a.net on security for handling silent posts from AIM or just a suggestion?

I do agree that it'd be hard to guess a transaction number for a specific booking (it's event ticket sales), so it might be a viable solution if a.net really doesn't provide sha hashes on purpose. I'd be recommending webhooks anyway since I've implemented them anyway.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Sat, 29 Jun 2019 18:29:41 GMT

@msykes

Not an official stance but the guide does say that it is a redundant security check. When you are over TLS you are encrypted. For sure webhooks are terrific. I don’t think anyone would not be using them if they knew how easy they are to set up and how well they work. I’m far past the point where I can count the number I have tested. Well over 1,000 for sure. Never had a failure from auth.net and had about 7 failures that were my servers fault. Never had a failure on a live site and haven’t had a single failure on my test remote server since moving to AWS many months ago.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Sun, 30 Jun 2019 11:38:12 GMT

@Renaissance could you point me to where it mentions being redundant? I'm curious.

I don't see how receiving a silent post vs. webhook for a void/refund is any different, therefore requiring a simple verification of ownership (MD5 would have been better than nothing!).

Yes, definitely I do agree that webhooks are the way to go, it's maybe 2-3 more clicks to set up.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Sun, 30 Jun 2019 12:27:43 GMT

@msykes

It is in the previous version of the AIM developer guide. Refers to md5, which sha512 replaces.

Here is an image.

https://ibb.co/z21MQMm

With AIM, I believe you can capture the response from the API call. Have you considered this? Silent Post is what SIM/DPM users use, but I think a good number of the AIM folks use what they get directly from authorize when the transaction is submitted. That is why it is redundant. If you use Silent Post to process then it is not redundant.

My hunch is that voids/refunds do not have an amount in the response and that is why the hash isn't calculated and returned.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Sun, 30 Jun 2019 12:53:00 GMT

@Renaissance thanks.

Thing is, it'd make sense if you're INITIATING a void/refund server-side, but not if someone goes into the authorize.net cpanel and initiates it there, since the only way your server will know is via a silent post or webhook.

I'd still disagree that it's redundant, maybe MD5 over SHA but the fact that it's SSL/TLS doesn't matter given someone can ping your endpoint/listener either way. It's highly improbable they get the combination of transaction ID with (in my case at least) an invoice ID matching our records anyway, but still...

Or am I missing something more obvious here?

The silent post provides an amount which is 0.00 for voided settlements, not sure about refunds, waiting on a test settlement to go through and see what happens.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Sun, 30 Jun 2019 13:43:49 GMT

@msykes

Not sure I follow how your software and you work together. You have a distributed ecommerce software, correct? And when you say they go into the cpanel, you mean your users? I am confused as to who needs the response. The way you word it, it almost sounds like you have third parties who use your software, and you yourself need to know the results of their transactions. So you are the developer, your customer is the merchant, and when the merchant initiates a refund or void for one of their customers, you need to get a response from auth.net. Is that the case? If so then for sure you need webhooks or silent post and the hash is not redundant.

I do not think the major concern is a rouge customer trying to hack your app to mark their order paid. I think the real threat is malicious requests that aim to compromise your application, either automated or flesh and blood person. You can be exposed to all kinds of security issues if you don’t block or frisk post data coming to your endpoint.

If you initiate a void server side then for you, the person initiating the void, it is redundant if over TLS. You are getting a direct HTTP response with a TLS handshake. If a third party needs notified then that person will need to have security measures on their endpoint.

https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-handshake-protocol

It is similarly redundant using modern API but the value is in the response so I verify everything too. Every extra layer of security helps, if the added layers are only at a cost of a few lines of code.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Sun, 30 Jun 2019 13:52:04 GMT

I think I see what you’re saying. Cpanel you mean the merchant interface. Yes, there for sure you have no choice. I have designed my clients backend to process transactions without the need to use the merchant interface. That’s what I thought you were meaning when you say cpanel, something similar to that.

Then yep, webhooks it is. You get a hash with every response that comes your way. I see no way around it.
Either that or program the backend to do transactions, which is 10X the work.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Sun, 30 Jun 2019 17:56:45 GMT

@Renaissance not exactly. It's distributed software, people install it on their site and their customers/visitors can book event tickets with it. We have no control over what they do on their site with the software at that point, all communication is between them and a.net.

If they book an event using AIM, all good, but if the site owner wants to void/refund a payment, they do it from the authorize.net control panel, therefore the site with the software gets notified via silent post or webhook to then cancel the booking. Hope that clarifies!

That's why TLS/SSL is irrelevant. The voiding/refunding is done on authorize.net, any further consequence happens once a webhook/silent post reaches the site. Whether we implement voiding/refunding server side in the future, this scenario still needs to be accounted for regardless.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Sun, 30 Jun 2019 18:01:18 GMT

@Renaissance oops, didn't see your last reply :) OK so we're in agreement then!

Now.. the question is, whether there should be a value in x_SHA2_Hash for refunds/voids?

I think there should be, and it's a bug. It's entirely possible someone initiates a refund directly via authorize.net so we need to account for that.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

Renaissance — Mon, 01 Jul 2019 01:52:42 GMT

@msykes

For sure I would say you would want to verify the response. As for a bug, I am not sure that auth.net deliberately excludes it, though they may. What you have in your way is that silent post is no longer a supported product. So whether or not they will fix it is up for grabs and I’d say it’s a decent bet they will not.

On my clients backend we initiate calls server side. There is something a little different about voids and refunds. The hash is already in the response but you have to make adjustments when you calculate it on your end. Took me a minute to figure that out. I think that may be why there is that bug on anets side for your product. Our server side calls are made through the modern API.

For you I think you should save yourself the trouble and just recommend your clients to webhooks. The hash is in the response every single time there too.

Re: x_SHA2_Hash missing in silent post for void/refund transactions

msykes — Mon, 01 Jul 2019 09:09:39 GMT

For you I think you should save yourself the trouble and just recommend your clients to webhooks. The hash is in the response every single time there too.

Yup, I agree, we'll just drop support for silent posts and move to webhooks completely, little point in trying to 'fix' something that is going to get deprecated anyway.

For anyone reading this who's absolutely relying on silent posts immediately, the only workaround I can think of is as @Renaissance said, which is to double-check the void/refund by making an API transaction call. That way, the silent post triggers your server to make the check and you have a definite/secure answer for the transaction status.

Thanks for your help!