Yes, I tried a merchant (custom) ID and that does get passed through to the callback, which is good.
Once that ID (identifying a transaction) is used, then it will be marked as such, so it cannot be used again. But a user in the POST form will be able to see that ID before the form is posted, and if they don't POST the form then the transaction key will be hanging there ready to accept a POST, which could come from a different transaction form (with two seconds of FireBug hacking). I guess the amount (x_amount) is part of the MD5 hash, so that can be trusted and compared to the amount on the transaction to make sure someone isn't using a really small purchase to trigger a "success" on a really large purchase that they started but did not POST previously.
Just on the subject of the MD5 check (and this was going to be another thread) do you happen to know how the "MD5 value" is incorportated? From what I can see, for the gateway to crreate a hash, and for the merchant site to recreate the hash to check it, both sides need to know a shared secret that no third party can ever know. I can see that the merchant site just keeps that secret as a configuration item somewhere (or sends the fields off to another service to encode it for more security). But how do we tell Authorize.Net about it? I can see in the sandbox admin pages there is a page to add an "MD5-hash", but the page desctibes it as being used for *encryption* and hashes are certainly not encryption, so I'm not sure if they is supposed to be the same thing as the "MD5 Hash Value" that the merchant site uses. I'm guessing it probably is and it is just mislaballed on the admin pages.