I am setting up an Authorize.Net DPM (Direct Post Method) payment gateway for a site. There is something I am fundamentally not understanding, and can't tie up the pieces.
The basic operation of DPM is that the merchant site - my site - provides a credit card form. That form is posted direct to Authorize.Net. After the CC and other posted details are authorized, Authorize.Net will POST the results back to my site. I'll refer to this as the callback post. Now here is where things don't quite tie up for me.
The callback POST comes direct from Authorize.Net and does not share a session with the user, so the POST handler only has the information that has been posted to hand. The amount (x_amount) and the Authorize.Net generated transaction ID (x_trans_id) are hashed with a pre-agreed secret and the Authorize.Net account login ID. This can be used to check the authenticity of the system providing that callback. From what I can tell, it is really just checking that the sender knows the pre-agreed secret.
So the only data I can trust in the callback is the amount and the gateway generated transaction ID (and this is the first point at which that ID is available to my site, so its value is meaningless).
What I cannot see, is how to tie the results of the authorisation back to the transaction that the end user is paying. There is no other data in the POST that can be trusted not to have been changed, and it does not pass on the merchant-generated ID anyway (a combination of x_fp_sequence and x_timestamp).
What I am expecting to be able to do in the callback is to take the result of the card authorisation, be sure that the result can be trusted, tie it back to the pending transaction stored in the database before the user posted the form to Authorize.Net, so that the transaction can be confidently marked as complete. But how?
I have worked with the SagePay Server gateway, and that also has a callback. However, the callback contains all the fields needed to tie the result back to the transaction being processed (it includes the merchant-generated transaction ID) and importantly it provides a hash of ALL the POSTed fields that need to be trusted so they can be checked.
So what am I overlooking? I can provide sample data if that helps to explain the issue. I'm using OmniPay and am extending the driver for this gateway.