Incorrect MD5 hash information in ARB Guide pdf?

[stevelabyrinth]

Hi,

In the ARB_guide.pdf document, there is the following (colors added by me)...

The payment gateway creates the MD5 Hash using the following pieces of account and transaction information as input:

• MD5 Hash value—this is the value set by the merchant in the Merchant Interface
• API Login ID (x_login)
• Transaction ID (x_trans_id)
• Amount (x_amount)

... and directly below, it says ...

For example, if the MD5 Hash value configured by the merchant in the Merchant Interface is “wilson,” and the transaction ID is “9876543210” with an amount of $1.00, then the field order used by the payment gateway to generate the MD5 Hash would be as follows:
wilson98765432101.00

... I used the second example in my development and keep getting an "Invalid hash" error, but when I look at it now it seems like the second block should have the API Login Id after the MD5 Hash value

Which is correct?

If the wilson98765432101.00 example is incorrect, has it always been incorrect or is this a recent change?

[RaynorC1emen7]

The top one is probably the correct.

http://developer.authorize.net/guides/SIM/Transaction_Response/Using_the_MD5_Hash_Feature.htm

[stevelabyrinth]

I've been logging the x_MD5_Hash values posted from Authorize.Net and it seems to be expecting different hashing inputs depending on the transaction response. Sometimes it's using the API Login Id and sometimes it isn't

It'd be great if this were documented somewhere

[RaynorC1emen7]

The other possibility that I know of is instead of the API LoginID is the Login for the authorize.net site when you generate the transaction thru virtual terminal.

[Trevor]

The transaction hash is provided in transaction results for SIM, DPM, and throught he Silent Posts generated by ARB.  For SIM and DPM, the correct hash is generated with pattern SecretKeyAPILoginIDTransactionIDAmount.  Because ARB transactions are generated internally within Authorize.Net, they are not associated with your API Login ID and the correct pattern becomes simply SecretKeyTransactionIDAmount. You can think of this as ARB transactions having a blank or null login ID associated with them.