DPM Tying Callback Data to Transaction

[jasonjudge]

I am setting up a DPM gateway for a site, and have a few questions. I'll ask them on separate threads, but this one is stumpning me the most.

When using DPM, I first save the transaction details into the database (since it will be needed in the callback), then present the form for the user, who then POSTs the form to Authorize.Net

If the POSTed credit card details are authorised, Authorize.Net will POST those details back to my site. I need to check those details are for a a valid transaction, and then update the transaction in the database with the result of authorisation. This is where I am having some difficulty.

How do I know what transaction has just been approved or denied in the callback? There is no transaction ID that can be used - only the [brand new] ID generated by Authorize.Net So how do I match the callback POST to a transaction that the user had entered into? And how can I trust the transaction ID (whatever it may prove to be) has not been tampered with, when it is not a part of the MD5 hash that Authorize.Net provides in this POST?

-- Jason

[jasonjudge]

Just to add to this, the SDK does not make this link either. All it does to handle the callback is to check what the authorisation state is, then return a redirect fragment back to the Authorize.Net gateway. That fragment contains the authorisation state as a GET parameter.

So where doe security come into this? At what point does the applicatioib - the merchant site - save the result of the authentication to the application? It can't do it on the redirect of the user's browser, because that is an unhashed GET parameter that any end user could change. It can't do it within the callback, because there is no safe ID that can be used to match the transaction that was started in the user's session.

Am I missing something obvious here? I've looked at various implementations of this in a variety of ecommerce shops, and they all just do a redirect to a "success" or an "error" page from the callback fragment. The act of landing on one of these pages or the other, seems to be enough to tell the application whether the authorization succeeded or not. And that redierect goes through the user's browser, so the end user has control of which page it really goes to. WTF keeps ringing in my head at the moment. I must surely be seeing this wrong?

-- Jason

[RaynorC1emen7]

You can use mechant defined field

https://support.authorize.net/authkb/index?page=content&id=A135&actp=LIST

And how can I trust the transaction ID (whatever it may prove to be) has not been tampered with, when it is not a part of the MD5 hash that Authorize.Net provides in this POST?

can you create a onetime use only temp key in your database?

[jasonjudge]

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.

[RaynorC1emen7 · Accepted solution]

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.

Yeah that the place,  I guess I never paid attention to what it said.

[jasonjudge]

Thanks. I'll have a play with that.