Include omnipay_transaction_id in hidden fields for the DPM form.

[judgej]

This was missing from a previous PR. Without it, the transaction ID does not get sent to OmniPay in the DPM form, and so is not accessible in the notify handler using $request->getTransactionId() - assuming DPMResponse::getRedirectData() is used to get all the hidden fields for use on the DPM form.

The current workaround is to make the field hidden manually:

$gateway = Omnipay::create('AuthorizeNet_DPM');
$request = $gateway->purchase($details);
$response = $request->send();
$response->hideField('omnipay_transaction_id');

then all the data returned by this method should be put into the DPM form as hidden fields.

$response->getRedirectData();

In addition, the transaction ID is still being put into the invoiceNumber field - but don't rely on this long term - it ain't an invoice number.

More details and some tests to come. Just throwing this PR in as a placeholder, to come back to possibly in a few days.

[judgej]

Just as some background to this: DPM involves creating a form in your own site, which is then POSTed direct to Authorize.Net. The idea here is to give the OmniPay request object all the usual stuff, in the usual way, then after send() your application asks the response object, "tell me what all the hidden fields are that I need to add to my form to get this transaction request to work". The application should, in theory, not have to know what those fields are named - OmniPay knows that and just handles it for you. It would be nice to find a way to extend this idea more generically to all the drivers that involve a form on your own site and some fields that need to be named according to what the end gateway requires.

[delatbabel]

Is this still valid to merge @judgej ?

[judgej]

Ooh, yes. Without this the transaction ID could appear as a non-hidden field in the DPM payment POST form. I wondered why I wasn't seeing that problem on my production sites, and realised I had this to do the same thing just before rendering the payment form:

...
                    // The payment gateway driver.
                    $request = $gateway->purchase($auth_details);

                    // Send the details to OmniPay to get the next action and data for the form.
                    $response = $request->send();

                    // Set the transactinon ID custom field as a hidden field in the payment form.
                    $response->hideField('omnipay_transaction_id'); // <<-- THIS LINE

                    // The initial details for the form are available from the OmniPay driver response.
                    $default_form_details = $response->getVisibleData();
...

[judgej]

Just as some background, the DPM message gives you all the fields that need to go into the payment form that is POSTed direct to Authorize.Net. The fields are in two groups: hidden and non-hidden. The non-hidden fields can be changed by the end user, while the hidden fields are just standard hidden HTML form fields.

Allowing the user to change fields in this form is optional - so any non-hidden field can be moved to the hidden list. This is what my workaround in production did, but is what adding this field to the hidden list in this PR does by default.

The rendering of the fields is up to the website, but this list of fields conveniently just gives you the list of fields that the user can be shown and must be hidden. Of course, anyone looking at the browser source can change any of these fields, whether hidden or not, so the application still needs to check all the transaction details at the end to make sure fields it chose to hide have not actually been changed by the end user with debug tools.