x_SHA2_Hash missing in silent post for void/refund transactions

[tchamness]

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',
  ),
)

[Renaissance]

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.

[msykes]

@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.

[msykes]

@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.

[Renaissance]

@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.

[msykes]

---

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!