topic Re: Working php hash verification in Integration and Testing

Working php hash verification

Renaissance — Wed, 16 Jan 2019 05:13:57 GMT

**If you find this helpful please kudo this post. This has consumed a huge chunk of my day and you will help me build credibility for when I enroll in the authorize.net certified developer program. **

Here is 100% tested, working php hash verification code for the php SDK. I believe this will also work with SIM/AIM, etc.

You need the following to have an apples to apples setup with what I used:

1: The most recent php SDK package from GitHub. I downloaded this today and installed. I believe it is a few days old.

2: If you have not generated a signature key from your production or sandbox merchant interface to use for testing, do so. You won’t get the hash in the response without it. Generate it and copy it for use in this script.

3: An API call script for some payment transaction that returns the hash. With the SDK I am getting this for voidTransaction, refundTransaction, capture, etc. I believe that any payment function that directly charges or affects a transaction will contain this. The Accept Hosted form API call obviously does not.

For requirement 1, the SIM/DPM, etc. users do not have this, if my understanding is correct. You should be able to use this as well, only substituting my method for extracting the transHashSha2 value from the response with however you accomplish this using your integration. You may also have to use different parameters in your delimited string, I would try this method first, but I have seen other developers posting attempts with more fields in the string than login, transId, and amount, and there is probably a good reason for this.

Here is the code (p.s. do not follow the hyperlink to the C# byte array description and try to implement a php equivalent to the C# byte array script. This makes things 100X harder than they have to be, as I know well at this point. Without further delay…..)

$login = "copy and paste your merchant login id here";
$signatureKey ="copy and paste your signature key here";
$signatureKey = hex2bin($signatureKey);
$amount = $amount;

//$response stands for the response object returned by your API call
//e.g.  $response = refundTransaction($refTransId,$amount,$lastFour);

$transId = $response->getTransactionResponse()->getTransId();
$string = '^'.$login.'^'.$transId.'^'.$amount.'^';


$hash = $response->getTransactionResponse()->getTransHashSha2();
$digest = strtoupper(HASH_HMAC('sha512',$string,$signatureKey));

if(hash_equals ($digest,$hash)){

    //This if statement is the verification piece 
    //Put whatever you want your app to do with the transaction here
    //to test you can do something like echo "Hash verification validated";
    //or try this:
    //$dump = print_r($string,true);
    //$fp = file_put_contents( 'transhash.log', $dump );
    //and if your directory populates with a file named transhash.log you know 
    //verification succeeded
    

}

Re: Working php hash verification

Vikas_chauhan — Wed, 16 Jan 2019 09:04:31 GMT

One question -

I am also going to update md5 to sha512.
Currently, in my application I use (save at my end)-

API Login ID -

Transaction Key -
MD5 -

For sha512 -

do I need transaction key or not? What will be the procedure to follow?

Thanks

Re: Working php hash verification

karenb — Wed, 16 Jan 2019 10:32:28 GMT

Renaissance, that's a good start at the problem! However, some questions remain.

ISSUE #1
========
Authorize.Net's "Transaction Hash Upgrade Guide" (hereinafter, the Guide) makes no mention whatsoever of the fact that for MD5, Authorize.Net required TWO different methods for creating $string...
1) Generally, e.g. for SIM, one would use $string = $md5SecretText . $login . $transId . $amount;
2) However, for silent post / recurring billing, $string = $md5SecretText . $transId . $amount;

One could then obtain md5($string) and use one's favorite built-in PHP string comparison function to test if one's calculated md5 hash matches the x_md5_hash string allegedly sent from Authorize.Net. The calculated md5 hashes (whether it's the one calculated by the merchant or the one sent by Authorize.net) both appear to be lower case hexadecimal strings.

For SHA512, I would guess that your post, in which you used
$string = '^'.$login.'^'.$transId.'^'.$amount.'^';
would cover case #1 above when transitioning to SHA512. But I don't think you've tested it for case #2 (recurring billing). Does it also work for case #2? If so, Authorize.net should announce and confirm that they've changed more than just MD5 to SHA512 by requiring that $login be included in $string when verifying recurring billings.

ISSUE #2
========
Meanwhile, Authorize.net uses still another method for generating $string for fingerprints...
3) $string = $login . '^' . $sequence . '^' . $timeStamp . '^' . $amount . '^';
With SHA512, that stays the same when generating the $string for fingerprints.
And previously, with MD5, one could then generate the SIM fingerprint...
$fingerprint = HASH_HMAC('md5',$string,$transactionKey);
Now, with SHA512...
$fingerprint = HASH_HMAC('sha512',$string,$signatureKey);
It might look like simply changing "md5" to "sha512" and "$transactionKey" to "$signatureKey", but there's another difference...
And as we've been told, the "$signatureKey = hex2bin($signatureKey);" line of code is needed for SHA512, but a comparable line of code is not needed for the MD5 version.

Your solution does not include the changes required to upgrade the fingerprints from MD5 to SHA512. I'm not sure that you intended to include that. There is a post on upgrading fingerprints at https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD5-to-HMAC-SHA512-and-how

ISSUE #3
========
Apparently Authorize.Net has not updated their documentation to disclose where the SHA512 hash is positioned within the character delimited transaction response string. For example, if the MD5 hash is being returned in the 38th element of the character delimited response, what is the position of the SHA512 hash?

Re: Working php hash verification

karenb — Wed, 16 Jan 2019 10:55:09 GMT

Still more issues...

ISSUE #4

=======

After the Signature Key has been created, the SHA512 hash is supposed to be sent to the merchant (along with the legacy MD5 hash for the time being) for each transaction. And that's normally true. However, it's not true for recurring billings. For example, when a recurring billing was declined, Authorize.Net included only the MD5 hash. The SHA512 hash element from Authorize.Net was empty. Authorize.Net needs to correct its system to include the SHA512 hash with recurring billings.

Re: Working php hash verification

lightwave365 — Wed, 16 Jan 2019 16:21:58 GMT

Do you have the hash being sent in the transaction? Before I would pull the x_MD5_Hash parameter from the response, hash the string on my end and compare.

Now I'm pulling transHashSha2 parameter from the response but it says null. Is this the same parameter you are pulling from the request or is it something else? Their API is crap in explaining this.

I already generated my Signature Key.

Edit: I found the parameter that I need to pull from the response. It is:

x_SHA2_Hash

Which is NO WHERE in their API or their schema. I had to query the parameters in the response myself. Why? Why? Why?

Re: Working php hash verification

Vikas_chauhan — Wed, 16 Jan 2019 16:17:40 GMT

I am using following format for HASH_HMAC using sha512

$string = '^'.$login.'^'.$transId.'^'.$amount.'^';

I am getting x_MD5_Hash but it is not generating the equal hash value;

Please help me out

Re: Working php hash verification

lightwave365 — Wed, 16 Jan 2019 16:23:15 GMT

I found the parameter that I need to pull from the response. It is:

x_SHA2_Hash

My values don't match either but at least I have a damn value to compare against now.

Re: Working php hash verification

Renaissance — Wed, 16 Jan 2019 16:58:42 GMT

Karen,

One at a time. The updating fingerprints is done simply by generating the signature key. Auth.net hashes the using the signature key on their end and you hash using it on your end. I just got up and am about to go get breakfast, when I’ll get there I’ll address more concerns.

And the link you posted explains why so many others were using different arguments in their hash function. For recurring billing, are you referring to the initial transaction that is created? I would imagine so.

Re: Working php hash verification

Renaissance — Wed, 16 Jan 2019 17:42:08 GMT

So again the trend is that everyone posting about this is using deprecated methods.

Per the link from Karen, the fingerprint is generated like this-

The construction of the HMAC-SHA512 hash is similar to the HMAC-MD5 hash. In particular, the input to be hashed is built from these values, in order, and separated by carets ("^"):
The API Login ID (x_login);
The unique merchant-generated sequence number (x_fp_sequence);
The transaction's timestamp in UNIX Epoch time, i.e. how many seconds have passed since Midnight UTC on January 1, 1970 (x_fp_timestamp);
The transaction amount (x_amount);
The currency code (x_currency_code), which should be blank if no currency code is submitted.
For example, if we presume an API Login ID of "authnettest", a sequence number of "789", a timestamp of "67897654," an amount of "10.50", and no currency code, the hash input would look like this:
authnettest^789^67897654^10.50^

If a currency code of "USD" were submitted, the hash input would look like this:

authnettest^789^67897654^10.50^USD

You would then hash this input with the HMAC-SHA512 algorithm, using the binary-encoded Signature Key as the HMAC key.

The resulting hash should be submitted to us as x_fp_hash, just as you do with the HMAC-MD5 hash. We will know which hashing algorithm you used, by the size of the value for x_fp_hash

So you sumbit your hash under x_fp_hash in your request it appears.

RE: MD5 hash, the whole point of this is that you don’t use the MD5 value. Use the value lightwave posted.

My pancakes just got here.. I’ll put some more info up while I’m waiting on my check if I have time. It looks like the SIM, etc method has some quirks. Stay tuned for tomorrow’s breakfast or tonight’s dinner. I’ll look at the link provided by Karen and see what the docs about the deprecated methods say and see if I can help you out.

Re: Working php hash verification

pudhgdfhgdf — Wed, 16 Jan 2019 18:12:41 GMT

If someone will stack w/ generating verification of "x_SHA2_Hash" on "x_relay_url"...

According to this PDF: https://www.authorize.net/content/dam/authorize/documents/SIM_guide.pdf page 73, working code will be like this

<?php

$signatureKey = '128-bit-length-key-generated-in-account';

$requiredHash = $_POST['x_SHA2_Hash'];

$hashData = implode('^', [
    $_POST['x_trans_id'],
    $_POST['x_test_request'],
    $_POST['x_response_code'],
    $_POST['x_auth_code'],
    $_POST['x_cvv2_resp_code'],
    $_POST['x_cavv_response'],
    $_POST['x_avs_code'],
    $_POST['x_method'],
    $_POST['x_account_number'],
    $_POST['x_amount'],
    $_POST['x_company'],
    $_POST['x_first_name'],
    $_POST['x_last_name'],
    $_POST['x_address'],
    $_POST['x_city'],
    $_POST['x_state'],
    $_POST['x_zip'],
    $_POST['x_country'],
    $_POST['x_phone'],
    $_POST['x_fax'],
    $_POST['x_email'],
    $_POST['x_ship_to_company'],
    $_POST['x_ship_to_first_name'],
    $_POST['x_ship_to_last_name'],
    $_POST['x_ship_to_address'],
    $_POST['x_ship_to_city'],
    $_POST['x_ship_to_state'],
    $_POST['x_ship_to_zip'],
    $_POST['x_ship_to_country'],
    $_POST['x_invoice_num'],
]);

$hash = hash_hmac('sha512', $hashData, pack('H*', $signatureKey)); // If you running on >=PHP5.4 you can use "hex2bin" function instead of "pack" 
$hash = strtoupper($hash);

if (method_exists('hash_equals')) {
    $equals = hash_equals($requiredHash, $hash)
} else {
   $equals = $requiredHash === $hash;
}

var_dump($equals);

P.S. Dear authorize.net...Burn in hell with such updates and docs.

P.P.S Nice idea give ability to write comment and then on submit require to sign up

Re: Working php hash verification

karenb — Wed, 16 Jan 2019 18:17:54 GMT

Lightwave365, in answer to your question, "Do you have the hash being sent in the transaction?" Authorize.Net is sending both x_MD5_Hash and x_SHA2_Hash as non-null values EXCEPT when a recurring billing is declined and then only x_MD5_Hash is non-null and x_SHA2_Hash is null, which appears to be a defect in Authorize.Net's system.

Renaissance, in regard to "The updating fingerprints is done simply by generating the signature key," the update requires that the transaction key no longer be used, that a binary version of the signature key be used instead, and to use the alternate hash (SHA512 instead of MD5).

Re: Working php hash verification

Alicia05 — Wed, 16 Jan 2019 19:34:07 GMT

Have you tested this with a sandbox account? Where the transaction id is returned as 0? I have essentially the same code, but my hash values do not match what authorize.net is returning.

Re: Working php hash verification

Renaissance — Wed, 16 Jan 2019 22:46:25 GMT

Yes,

I do all my testing on a sandbox. You shouldn’t be getting a transaction id of 0. You have a separate issue. Sandbox transactions will give you a transaction id.

What integration method are you using? If you’re using SIM or other deprecated methods then that may be the case. On my sandbox I have tested Accept Hosted transactions (which use webhooks to communicate responses), as well as manual API calls using the SDK for capturing, charging, refunding, voiding transactions, etc.. Each of those will generate a transaction id.

If you’re using the deprecated methods the exact script will not work in any case. Your string is different. I’ve got some code that should work or at the very least get people much closer for those methods. Will post that in a little.

Re: Working php hash verification

Renaissance — Wed, 16 Jan 2019 23:56:27 GMT

Here we go. First, a little housecleaning:

For the past week or 2, this forum has been hopping with developers in panic mode, seemingly under the impression that they have been seized upon, out of pitch darkness and without notice, by a new and mysterious signature signing method that has a million quirks to be worked out and doesn’t work, and also isn’t documented anywhere. About 95% are posting about SIM/DPM. This is a sort of new thing for the 5% on API based integrations, but for the remainder, when I looked this up the process for how to do this has been in place and recommended since at least September of 2017 in the below document.

https://www.authorize.net/content/dam/authorize/documents/SIM_guide.pdf

It is advisable to review your documentation on a more regular basis than once

every few years in my books. And when your docs say “we use recommend and use abc security method. xyz method is also supported but we don’t recommend it”, that’s a good heads up that down the road xyz method is going to be axed. The way technology works is it is always changing. What is secure today won’t be as secure 1 year from now, and eventually it won’t be secure at all. When new methods are introduced it’s not for no purpose at all. It’s not fun and not life’s main attraction, but it kind of comes with the territory.

2. I now realize why so many people with those methods are posting. This is required to submit your transactions, and seems to function the same way the token functions for Accept Hosted. The token is far easier than this. People are posting that they cannot upgrade to the API based integrations now, but this may be a good reminder to do that when you can. You may otherwise continually find yourself having to do things the hard way or not being able to do things at all that those using the current integration methods do easily.

Now that that’s out of the way, let me see if I can help my good friends here.

@karenb the signature key is totally different than the transaction key, in case you’re not clear on that. You have 3 API credentials, the login id, transaction key, and signature key. Everything you’ve ever done likely requires the first 2, but to this point you may have never had to use the SK. So in the code below you will generate a signature key to use.

For recurring billing, I looked at the webpage on that and it says to use webhooks. Am I correct that all recurring billing transactions are manually submitted?

@Vikas_chauhan see the code below. Looks like the transaction key plays no role in your product either.

Here is the code for SIM/DPM. I haven’t tested it at all, but I believe it should work or get you almost completely there.

date_default_timezone_set('UTC');
//^may not be necessary depending on your configuration

$login = "copy and paste your login here";
$signatureKey = "copy and paste your signature key here";
$signatureKey = hex2bin($signatureKey);

$amount = $amount;
//this assumes you have previously assigned the transaction 
//amount to a variable called $amount in your script

$sequence = "make up a number and paste it here."; 
//save whatever number you use for validation on your end.
//example in your docs uses 3 digit numbers

$timeStamp = strtotime("now");

$currency = "USD";
//looks like that you only use this 
//if you specify currency type in your form request
//you can use another value if you do things in a different currency

//use one of the two strings below. 

$string = "^$login^$sequence^$timeStamp^$amount^";
//the above seems to be what you use if you don't submit
//x_currency_code in your request

$string2 = "^$login^$sequence^$timeStamp^$amount^$currency";
//looks like you use this if you specify currency

$digest = strtoupper(HASH_HMAC('sha512',$string,$signatureKey));
//Looks like this value is submitted in your request under "x_fp_hash" 
//Look in the SIM/DPM developer guide on for what "x_" to to use for $sequence, etc.
//page 29. Test this without the strtoupper fuction as well 

//All of the above are what is submitted in your request. You can 
//use the first code I posted to validate the response in SIM/DPM
//you would retrieve the value lightwave posted x_sha2_hash instead
//of what I posted and you change your $string input to match this 
//(the string and value from my orignal post are for php API based integrations)

Re: Working php hash verification

Renaissance — Thu, 17 Jan 2019 00:21:27 GMT

^edit to the above. Looks like your verification procress requires a hash of 5 or more values from the request.

So what I posted will create your signature to send with the transaction, and then you will verify based on the values and instructions on page 73 of the guide I linked. I won't lose any sleep over not having to perform these acrobatics with my integration. There may be no choir to preach to on this thread, but accept hosted and the recent API based solutions are so much easier than this.

Re: Working php hash verification

Renaissance — Thu, 17 Jan 2019 04:46:13 GMT

@karenb,

To answer your question about recurring billing a little more, those use webhooks. For that string you would use your signature key as the key, without any modification. You would hash the webhooks payload that hits your endpoint in place of “$string” in the code I posted, and you would use a header that is sent along with the payload called X-Anet in place of $hash in my code.

Regarding silent post, I am not sure that I would be relying on that for anything at this point. I’m not the one to say, but it looks like that has vanished totally from the website. Another user was posting about that. And I am almost certain that I recall reading something about it being marked for upcoming deprecation when I started my first project in mid 2017. So that product may now be so unsupported and disregarded that you can’t safely rely on it.

Clients are like the rest of us in that they don’t like to spend money, but with things like this it is unavoidable. The lesson I am learning as a new developer watching this fiasco unfold is that I need to stay on top of the documentation as much as possible, and when new features come out advise my clients that they should go ahead and have them implemented, at least for security related measures.

If I were any one of the developers on here who are supporting customers with deprecated products I would be making the case to move to the current products like Accept Hosted. If I had several of them I’d offer some kind of “upgrade your API” special that had a time window, and it would be economical for both sides because you’d be doing something very similar on each site. It may take some time to come up with the code, but on each one there would be more and more that is reusable for the next ones, “spreading the overhead” in a digital sense.

I know not much about hashing, encryption, etc. but I know enough to know that MD5 is useless at this point. If you have a site that has MD5 hashed passwords and someone gets ahold of your database, those passwords might as well be plain text in most cases.

And be prepared for the day when sha512 is obsolete, and 2048 bit RSA encryption, etc. it may be 2 years from now or 10 or 20, but these types of changes will be recurring. It’s an arms race between the computing power of technology and the strength of the encryption/hashing techniques and it will likely go on for longer than I have to live.

Re: Working php hash verification

karenb — Thu, 17 Jan 2019 07:17:09 GMT

Renaissance, as far as I can tell, there has yet been no end of life announcement from Authorize.Net regarding Silent Post, Automatic Recurring Billing or SIM. The use of webhooks as an alternative is merely "suggested" by Authorize.Net, not required at this time. Silent Post still works today as it has in the past, and should continue to function after the hash upgrade as well, until some future as yet unannounced date when its end of life arrives.

Regarding "Am I correct that all recurring billing transactions are manually submitted?", yes and no. Subscriptions can be entered manually, but the recurring billings that flow from the subscription occur automatically.

Regarding "when I looked this up the process for how to do this has been in place and recommended since at least September of 2017 in the below document," that's not accurate. Authorize.Net's recently published Transaction Hash Upgrade Guide does not agree with that SIM guide. For example, the September 2017 SIM Guide says "A hash will always incorporate at least 31 caret (^) characters, even if only 5 fields are provided" while the Transaction Hash Upgrade Guide says that a hash can incorporate as few as 4 caret (^) characters.

Re: Working php hash verification

Renaissance — Thu, 17 Jan 2019 08:01:44 GMT

@karenb, I had to read that one twice. It got me as well. The difference is that you use one thing for your fingerprint to validate the transaction on submission and another to validate the receipt.

From what it looks like to me, you use the string of 4 values for the fingerprint to verify, and the string with 5+ values + 31 carets to validate ok your end. In my view the validation on your end probably isn’t as important. That’s what got me about the whole thing. I make api calls for all the backend stuff, and it seems like the chances of the response coming from someone other than authorize is pretty remote. For webhooks it is different because anyone that wants to can send stuff to my endpoint anytime they want. But I would still do it. For silent post I would say it is important, and you’re right. There is no end of life stated although it has been marked deprecated for a very long time. I searched in the support center and there is no mention of silent post having sha512, so to continue to use that product you would have yet another hash to keep up with. Looks like you’d keep MD5 for that, use one sha512 hash for your SIM fingerprint, and sha512 hash for your verification, and yet a third sha512 hash for webhooks and recurring billing. You say that you get a hash in the response, I don’t know if you mean the silent post response or the manual API call response, but when I look at the reference there is no mention of a hash in the response. The pattern I have noticed in looking at the existing api documentation is that every response that is documented as having the MD5 “transHash” will also now contain the sha512 hash, and those that don’t mention transHash will not. My guess is that if you’re using one of the older methods to do ARB and not using webhooks the you’ll be using the non-null hash you mentioned earlier, although at this point I cannot remember which it was (if I guess I’ve got an 1 in 15 chance of getting it right at this point, right ?).

If I remember right you are the business owner and not the developer from your earlier post. It may be well worth it to talk to your developer about upgrading your integration as soon as is practical at all. After researching this process today it is like tying yourself in a knot while walking on a tightrope compared to the process I use with my stuff. I got thrown off by the link to the C# function and it cost me about 3 or 4 hours of time, but once I abandoned that it was about 10 minutes to get it working. It was also about 10 minutes to get the webhooks verification working. I do no such acrobatics in the Hosted form call. I’ve touted the products I use to the point that I think I can probably let up now, but to me it seems well worth it. The immediate issue I see with the verification on your end with SIM is that if all of those values aren’t submitted in the request, you’re going to have to account for that on your server side. So it is possible that you will have a different hash string for different customers. One may have 10 values and one may have 7, or 5, etc. That’s just a first glance look and might be wrong. People will be finding out shortly I am sure.

Re: Working php hash verification

keksa — Thu, 17 Jan 2019 10:07:46 GMT

@pudhgdfhgdfThank you for the relay snippet, it's almost there, but not working as is. The $hashData variable must be enclosed in carets as well, not just imploded.

The following code works for me on sandbox (PHP 7):

$signatureKey = 'YOUR-SIGNATURE-KEY-128-CHARS';
$fields = [
    $_POST['x_trans_id'] ?? '',
    $_POST['x_test_request'] ?? '',
    $_POST['x_response_code'] ?? '',
    $_POST['x_auth_code'] ?? '',
    $_POST['x_cvv2_resp_code'] ?? '',
    $_POST['x_cavv_response'] ?? '',
    $_POST['x_avs_code'] ?? '',
    $_POST['x_method'] ?? '',
    $_POST['x_account_number'] ?? '',
    $_POST['x_amount'] ?? '',
    $_POST['x_company'] ?? '',
    $_POST['x_first_name'] ?? '',
    $_POST['x_last_name'] ?? '',
    $_POST['x_address'] ?? '',
    $_POST['x_city'] ?? '',
    $_POST['x_state'] ?? '',
    $_POST['x_zip'] ?? '',
    $_POST['x_country'] ?? '',
    $_POST['x_phone'] ?? '',
    $_POST['x_fax'] ?? '',
    $_POST['x_email'] ?? '',
    $_POST['x_ship_to_company'] ?? '',
    $_POST['x_ship_to_first_name'] ?? '',
    $_POST['x_ship_to_last_name'] ?? '',
    $_POST['x_ship_to_address'] ?? '',
    $_POST['x_ship_to_city'] ?? '',
    $_POST['x_ship_to_state'] ?? '',
    $_POST['x_ship_to_zip'] ?? '',
    $_POST['x_ship_to_country'] ?? '',
    $_POST['x_invoice_num'] ?? '',
];

$hash = strtoupper(
    hash_hmac(
        'sha512',
        '^' . implode('^', $fields) . '^',
        hex2bin($signatureKey)
    )
);

var_dump(hash_equals($hash, $_POST['x_SHA2_Hash'] ?? ''));

Re: Working php hash verification

karenb — Thu, 17 Jan 2019 10:48:05 GMT

Renaissance, you say "The difference is that you use one thing for your fingerprint to validate the transaction on submission and another to validate the receipt," but I'm not sure to what you're referring, as my most recent post was not discussing fingerprints, only the verification after information is received from Authorize.Net.

You say you "searched in the support center and there is no mention of silent post having sha512, so to continue to use that product you would have yet another hash to keep up with," but for me, the evidence does not fully support that conclusion. For example, the Transaction Hash Upgrade Guide clearly applies to MD5 transaction hashes, and it is a fact that Authorize.Net is sending a MD5 transaction hash to the Silent Post program, and there is nothing in the Transaction Hash Upgrade Guide saying that the upgrade does not apply to all MD5 transaction hashes including that provided to the Silent Post program. But it's possible, because Authorize.Net is not strong on its documentation, to put it mildly.

You say "I don’t know if you mean the silent post response or the manual API call response," but there is no "manual API call" involved and thus no "manual API call response". That someone might manually enter subscriptions into the Merchant interface does not activate the Silent Post program. The Silent Post program is only activated after a payment transaction has been processed. And that too needs verification like every other payment transaction.

You say "when I look at the reference there is no mention of a hash in the response," but perhaps you are not looking at the correct response reference, which is the response to the (automatic) payment transaction, not responses to creating and managing subscriptions. It's a payment transaction response, almost identical to the payment transaction response sent after a customer manually makes a payment. But the hash is calculated differently for Silent Post than for a customer's manual payment. For a customer's manual payment, the string used to calculate the MD5 hash includes the API Login ID, but for a Silent Post, it does not.

In regard to "My guess is that if you’re using one of the older methods to do ARB and not using webhooks," yes, I've been talking about the Silent Post method for handling the transaction responses for recurring billing, not webhooks.

In regard to "if all of those values aren’t submitted in the request," that raises the other issue... the Transaction Hash Upgrade Guide and SIM Guide are inconsistent with one another. The former claims a string of just 4 or 5 carets is correct while the latter insists there must be a minimum of 32 carets in the string.