DPM Gateway Support about omnipay-authorizenet HOT 17 CLOSED

Branch I am working on is here, if you want to take a peek:

https://github.com/academe/omnipay-authorizenet/tree/dpm_support

from omnipay-authorizenet.

The DPM documentation is not quite right in some places. It lists transaction types such as VOID and CAPTURE, which really have nothing to do with DPM. It is just authorize and purchase (authorize+capture) that DPM supports directly, so far as I can see, and other transaction types are really for the AIM gateway to deal with.

from omnipay-authorizenet.

Just a note on that documentation (supplied by Authorize.Net) for DPM. They have now withdrawn that documentation, and point DPM users at the SIM guides instead. DPM functions like SIM, but with just a few tweaks. Some of those tweaks are now an appendix in the SIM documentation, and some is now missing (but I believe someone is now on the case and updating that).

My DPM branch, linked above, is in production and working great. It does not have all the tests I would like, but I'm happy to do a PR now if you are, and submit the tests later, or we can wait - let me know what you think.

It does need some documentation somewhere to explain just how to use it - how the DPM gateway helps in creating the direct-post form etc. I'm not sure where that would go? It seems too much to go into the driver, but then I cannot see anywhere else for it to go. Any ideas?

from omnipay-authorizenet.

@judgej I looked over that branch and it looks top notch. I do have a question about the Purchase request. It looks like that's the only DPM message that doesn't have it's own response class. Does purchase work with the AuthorizeResponse?

And I really can't merge it without tests. I can put it on my todo list to write tests against your branch, to help get things going.

from omnipay-authorizenet.

Yes, the response in the callback (relay URL, in Authorize.Net parlance) is the same regardless of whether it was an authorize or payment originally requested.

The callback does include an x_type POST field, which is either "auth_only" or whatever for auth+capture. If we had separate auth and payment responses, we could use that field value as a validation to check that someone has not switched a payment to an authorize request as they are sent to the DPM form (that field is not a part of the payment form hash (which only serves to prove the legitimate merchant site was involved in generating the request, and not that the end user has not fiddled with some of that data enroute), so they could do it - the more I work on these gateways, the more holes I find, all of which need extra checks in the application to make sure transactions are not being hacked).

What do you think? Split it up? It would mean the callback handler would need to know which transaction type it is expecting, but that's fine - you need to store most of the transaction initialisation data for the callback to refer to and for an audit trail anyway.

from omnipay-authorizenet.

I think I am confusing myself! I was thinking about splitting DPMCompleteRequest into DPMCompleteAuthorizeRequest and DPMCompletePurchaseRequest. Both of those would return the single DPMCompleteResponse, but each would keep an eye on x_type and raise an exception if it gets in the wrong transaction type. It does sound like overkill - the application could check for that.

from omnipay-authorizenet.

On DPMCompleteRequest (in your callback) you need to set the amount you were expecting before running send(). Along with the login ID and secret shared key, that is enough to determine the callback POST has legitimately come from Authorize.Net and that the amount has not been changed. Other fields could be modified by a man-in-the-middle attack, but can probably be trusted if the callback uses an SSL connection (and it must be a valid public certificate for Auth.Net to accept it). Non-SSL will work, but you then cannot really trust that any fields other than the amount have not been modified en-route. Unlikely though, but you need to know what the risks are. The transactionReference that we see for the first time in the callback is a part of the hash check, so you can trust that and go look up the transaction details through the AIM API, if you are worried about attacks like that.

I always wonder if the CompleteResponse objects need more get methods to access the data they contain. It is all very well checking the transaction was successful, but there is other useful data in the response that is all stuffed into getData() and indexed using the gateway's field names. So if I want the transaction reference, I would need to know it was in field "x_trans_id" (okay, bad example, as there is a getTransactionReference() method in this case, but x_type is a good example). It could be done with an array mapping gateway fields to OmniPay equivalents and a magic __get() method - not sure if that kind of thing is frowned upon here..?

from omnipay-authorizenet.

In short, here is the data in a relay notify, available in DPMCompleteResponse::getData():

Array
(
    [x_response_code] => 1
    [x_response_reason_code] => 1
    [x_response_reason_text] => (TESTMODE) This transaction has been approved.
    [x_avs_code] => P
    [x_auth_code] => 000000
    [x_trans_id] => 0
    [x_method] => CC
    [x_card_type] => Visa
    [x_account_number] => XXXX4242
    [x_first_name] => Joe
    [x_last_name] => Bloggs
    [x_company] => 
    [x_address] => 88 Address 2
    [x_city] => City
    [x_state] => State
    [x_zip] => 412
    [x_country] => GB
    [x_phone] => 01234 567 890
    [x_fax] => 
    [x_email] => [email protected]
    [x_invoice_num] => 563121241
    [x_description] => 
    [x_type] => auth_only
    [x_cust_id] => CUST123
    [x_ship_to_first_name] => Joe
    [x_ship_to_last_name] => Bloggs
    [x_ship_to_company] => 
    [x_ship_to_address] => 99 Address 2S
    [x_ship_to_city] => CityS
    [x_ship_to_state] => StateS
    [x_ship_to_zip] => 412S
    [x_ship_to_country] => GB
    [x_amount] => 10.00
    [x_tax] => 0.00
    [x_duty] => 0.00
    [x_freight] => 0.00
    [x_tax_exempt] => FALSE
    [x_po_num] => 
    [x_MD5_Hash] => 480AA04BE6E4BF0469B63D9E42BD568A
    [x_cvv2_resp_code] => 
    [x_cavv_response] => 
    [x_test_request] => true
    [transaction_id] => 563121241 (not this one - this is my custom field)
)

I want to get at all that juicy data using OmniPay field names. Would a magic __get() be acceptable? None of these need to be set - they are immutable. The "transaction_id" is my local transactionId put into the direct POST form as a custom field. I think SIM requisitions the x_invoice_num (invoiceNumber) field for that, but that would not work if you had real invoices numbers to put in there.

Upon returning from the callback, and sending the user back to the merchant site, I want to be able to get all all that data again, also using OmniPay field names. If that data can be stored in the callback, then fed into a new instance of DPMCompleteResponse on return to the main site (with the user's session) that would be ideal. Not sure how that would work at this point.

from omnipay-authorizenet.

Generally wouldn't you just do getData(), get the array and then access it by key? Is a __get needed?

from omnipay-authorizenet.

You could, but then you would need to know all the index values, which is something that OmniPay abstracts away from the specific gateway everywhere else. I'm just exploring the areas that could be abstracted a little more, to help reduce the amount of custom code needed to wrap each payment gateway.

from omnipay-authorizenet.

Good point. I'm a little hesitant to use __get and magic methods, simply because they're generally a bit harder to debug and test.

If you can provide tests to cover it though, I'll merge it.

from omnipay-authorizenet.

Okay, I'll do that on a different branch, as we have on the dpm_support branch now is usable, given some examples to show how. Needs more tests though.

from omnipay-authorizenet.

Should I renamed DPMAuthorizeResponse to DPMResponse? It makes sense. I was thinking more about the DPMCompleteResponse earlier.

Edit: I'll just do it.

from omnipay-authorizenet.

There isn't a stable release number that includes DPM right now. Has it just been overlooked, or is it being held off for later?

from omnipay-authorizenet.

Just tagged a release, so it should be good now.

from omnipay-authorizenet.

You are a star :-)

from omnipay-authorizenet.

Working nicely.

from omnipay-authorizenet.