topic Re: Hosted Payment md5 hash error 99 in Integration and Testing

Hosted Payment md5 hash error 99

cdrugly — Thu, 15 Sep 2016 20:45:23 GMT

No matter what I do, I cannot make my fingerprint match that generated by https://developer.authorize.net/api/reference/responseCode99.html

My PHP is below, and it used the hmac function from the SDK. I'm using fixed values for testing purposes. Despite beign obfuscated, I know for a fact my transaction_key is correct as is my x_login.

function hmac ($key, $data) {
	return (bin2hex (mhash(MHASH_MD5, $data, $key)));
} 
 
$transaction_key = "xxxxxxxxxxxxxxxxx";
$x_login = "yyyyyyyy";
$x_amount = "50";
$x_fp_sequence = "159383";
$x_fp_timestamp = "1473967216";

$hmac_data = $x_login . "^" . $x_fp_sequence . "^" . $x_fp_timestamp . "^" . $x_amount;

$x_fp_hash = hmac ($transaction_key,$hmac_data);

The result of the code 636fb8386946440d945390989aca6234.

When I feed those same numbers to https://developer.authorize.net/api/reference/responseCode99.html I get 0FCDB7701BE1FAE7B0CEF727344EF658.

What is going on here?

How do I generate a proper MD5 hash for a hosted payment form?

What's even more confusing is this link (https://support.authorize.net/authkb/index?page=content&id=A1706&actp=LIST_RECENT) says that the encryption method has been changed from MD5 to HMAC-SHA512 but nowhere in the downloadable guides does it mention this.

So is it MD5 ort SHA512?

Re: Hosted Payment md5 hash error 99

cdrugly — Thu, 15 Sep 2016 21:40:24 GMT

I was finally able to get the fingerprints to match by including the (optional) currency code.

I've found that it's not optional at all. If you do not include it in your fingerprint hash as well as your form data, it will results in an error 99.

I hope this helps someone else who has beating their head against the wall like I have.

Re: Hosted Payment md5 hash error 99

mkienenb — Fri, 16 Sep 2016 00:12:33 GMT

I've been fighting against failed MD5 checksums for awhile now with payment profiles, although they work fine for non-payment-profile transactions. Are you saying you got it working by prefixing your amount with a $ (or locale-equivalent)?

I had noticed that authorize.net stated somewhere that they would soon be providing some new transaction checksum down the road and I had assumed that md5 checksums was unfixably broken for payment profiles.

https://community.developer.authorize.net/t5/Integration-and-Testing/MD5-Hash-fails-for-CIM-profile-payment-method-but-works-for/m-p/53589#M28695