Ubercart

Two problems I found implementing this module, that I was able to fix.

line 300 users hash_hmac which is only in php 5. If you're running php4 you can add this function

function hmac ($key, $data){
return (bin2hex (mhash(MHASH_MD5, $data, $key)));
}

and then use $fingerprint = hmac($txn_key, $login . "^" . $sequence . "^" . $tstamp . "^" . $amount . "^" . $ccode);

instead of $fingerprint = hash_hmac('md5', $login . "^" . $sequence . "^" . $tstamp . "^" . $amount . "^" . $ccode, $txn_key);

Second problem is that the amount wasn't formatted correctly so authnet was rejecting it, so to fix that underneath
$amount = $order->order_total;
I added:

$amount = uc_currency_format($amount, FALSE, FALSE, '.');

Could anyone be able to port this to DRUPAL6? I've tried, but keep running into problems

Some of these instructions can get really complicated if you are not familiar with the the programming language. But we have been recommending ubercart because of the simple integration with Authorize.net

-Join the best
http://menexis.com

I am going to attempt porting this to D6. Are there any known issues with doing so? It looks like this had been attempted before with no luck. Any pointers are helpful.

Any luck Torgo's? I need to accomplish something similar and was wondering if you have made any progress. Thanks bud.

Unfortunately I haven't, time hasn't been on my side lately. Feel free to pick it up if you like.

Hey y'all,

Ported this to Drupal 6 for a client site. It was a fast job, but it works fine as far I've tested it. Let me know how it works for you.

Dominic
http://beardedstudio.com

Hi Dominic,

Thanks for posting the D6 module.

Unfortunately I'm getting an error when I try to submit my order (the transition from my Drupal site to the Authorize.net server). It's error code 99, which means "The server-generated fingerprint does not match the merchant-specified fingerprint in the x_fp_hash field."

Authorize.net has a help page about response code 99 at https://developer.authorize.net/tools/responsecode99/

Also, is there a newer version of this module I should be using? On my Modules screen, the description of your module is "Authorize.net SIM only OLD UNSUPPORTED." Is there a different one I should download?

Best wishes,
Andrea

I have attached the updated and working Drupal 6 (UCv2) version. It had the same problem as mentioned about with the currency casting.

Zach Ferres,
Bouncehost

Hello:

First thanks for everyone working on this module, it was really helpful for me. I tested the module and it works fine, I managed to be redirected to the payment form on the Authorize.net servers, so I guess it should not be a problem to proceed on the payment (Currently on live test mode - ubercart, and test mode on my merchant account). I just want to know if this is a stable version, is it safe to use on a production site, I have not gone live with my shop, I am still in testing mode, but just wanna be sure is safe to use in a production mode.

Thanks

Has anyone else encountered problems with this module not updating the order status after the payment is processed? The order status should be updated to "payment received" but it stays at "in checkout".

Also, when a payment is accepted the customer is directed to an authorize.net receipt page with a link that says ist goes to cart/authorize_net/complete but it actually goes to the cart.

Another problem is customer accounts are no longer being setup and all transactions are added under customer id 0

I am also not getting the customer and admin invoices emailed with this.

Anyone else experience these issues and/or have tips?

OK, I solved my problem with the payment info not returning and posting to my site. It turns out I had a merchant defined field that was interfering with the order id which interfered it from posting to my database.

So everything works except I am noticing that the customer and admin invoice emails from ubercart are not going out and the payment status is not posted unless the customer clicks the defined "continue" link on the receipt page. I have customized the text in that link button to state "CLICK HERE to FINALIZE and EMAIL RECEIPT" to try and help encouragement of customers clicking it and not just closing the browser. Is there another way to get the payment info posted or has no one else ran into this problem?

Is there any reason why this hasn't been contributed to drupal.org?

I've modified this module to work with the HostedCheckout solution from e-xact.com & ChasePaymentech. It only required a few code changes and I'd be happy to share with anyone that needs it.

We are having a problem with users not finalizing the transaction from the e-xact receipt page to return to Ubercart. As a result, the order, though successfully processed, never gets updated beyond "in checkout".

HostedCheckout offers a "silent post" option that will send the required info to Ubercart without user input but it requires (as far as I can tell) a static URL to post the results to. Since this module expects the order number at the end, it doesn't work.

Any thoughts or help on how to proceed?

We're about to integrate a client's e-xact processor and would like to see what you've done already. We'd share back any knowledge we gain, of course.

Has anyone got the Authorize.net SIM module to work with an anonymous checkout?

I am about to create a custom module to integrate with chase paymentech's exact hosted checkout service too. Are you willing to share the code you have so far? I would contribute back of course.

I've attached the zip file of what we threw together. Help yourself and hopefully someone can properly contribute it back to the community.

As VISA et. al. begin to tighten the PCI screws, I'd like to move my authorize.net AIM payment users to SIM (and/or PayPal Standard and Google Checkout) to make it someone else's problem. This module looks useful, but I've noted that it relies on a manual action by the user (clicking on the return link on the authorize receipt page) to complete the transaction. A quick look at the SIM spec suggests that using a "relay response" post instead might avoid that problem. Has anyone looked into that yet?

Also, to repeat the question above: any reason why this hasn't been formally released on d.o? Anyone already working on that?

Hi Jerry,

Sorry, I just saw a whole bunch of the messages now. To answer your question, the reason it hasn't been added to d.o is because I basically just made this module to satisfy a client's setup. And beyond testing it on that setup, haven't really made any new changes and have not had the time to port it to d6 or manage it since.

~Sarah/Tanjerine

Thanks, Sarah. I'll set this up in a test account and see if I can do something useful with the relay response.

Hello all,

For those of you interested in a chase module. I have uploaded my implementation here: http://www.ubercart.org/project/uc_chasepaymentech

It is possible to use the REDI (automatic redirect) response mode in this module. If I find the time I'll try and put up a patch in this thread for those interested in using the REDI response for the Authorize.net sim module. In the meantime you can checkout the code in uc_chasepaymentech to see how I implemented the REDI response.

Sarah, I took a look at your authorize_sim module and recycled some of your code for this, so thanks. uc_paypal was very useful as well.

Also, I have applied to add this to drupal.org, so hopefully the module will be up there soon as well. http://drupal.org/node/927932

cheers,
Jesse.

Alas, the authorize.net SIM documentation doesn't indicate any support for the REDI option (or some other useful things) provided by the Chase API.

However, I've modified Sarah's module to use the relay response option instead of generating a receipt with a link back to the store. This will notify Ubercart of the transaction's outcome without the need for user interaction, though it will still require a click to get back to the originating site. The difference is that the user may safely abandon the session after submitting the payment information.

The relay response mechanism expects the site to which it posts the transaction data to return an HTML status or receipt page, which it will display in its own context. The attached module provides a very simple page to display the Ubercart transaction messaging using the same formatting authorize.net uses for its payment form. Others may wish to construct something more elaborate. A couple of notes about this:

1) Auto-login of new users isn't supported due to the context situation.
2) Ubercart's checkout completion messages for new and existing users should reference "[site-url]user", not "/user".

I don't presently have a live authorize.net account suitable for testing this using live or live-test modes, but it seems to be working fine with their test server. I encourage other folks to give it a try, and perhaps we can get it submitted to d.o when/if it's confirmed to be stable.

I've now tested my relay-response variant of this module with the live authorize.net server, and it's working fine there as well.

While the module I posted above does seem to work fine in production, there's a wrinkle - simulating the cart completion via the relay response in authorize's context doesn't allow reporting of Ubercart data to Google Analytics via the standard submodule. I haven't thought of a reliable workaround for this so far.

However, I note that authorize has just announced a new integration method they're calling Direct Post (DPM) that may well supersede the SIM approach for Ubercart. The payment form is generated by the merchant site but posted directly to authorize, which then uses a provided return URL on the merchant site to post the results and generates a redirect to the merchant site on success. The result would appear fully-integrated but would still avoid PCI card-handling issues on the merchant system. Anyone already working on that?

I am trying to use this module with relay response. The payment becomes successful., however the order status remains stuck at pending and does not go to payment received. The order log shows the last thing as

Credit card APPROVED: $xx.yy

What could I be missing?

Thanks

Ok, figured it out. If you are using Discount Coupons, and apply a coupon, the order total has a fraction of a cent in the order total, however the approved amount from the payment gateway is in cents rounded off, so the don't match and hence the payment complete is not called. I changed the comparison ( $amount == $order->order_total) to (abs($amount - $order->order_total) < 0.01) and it works like a charm.

Very useful module. Also as mentioned in a couple post above anyone working on authorize.net DPM module?

Thanks

I am. Stay tuned.

Looks like the code is not authenticating the relay response from authorize.net using the x_MD5_Hash provided by authorize.net. Is it safe to not validate that? Couldn't someone craft a response back to server as valid payment without actually entering any CC info at authorize.net?

Thanks

FWIW, I took the module in post #23 and added validating relay response from authorize.net (only if you set md5 hash value in the payment gateway settings. The module is enclosed. I tested it and it seems to work. Can someone please take a look.

Thanks

Looks OK to me, FWIW. I'd planned to do something similar myself, and just hadn't gotten around to it yet as I'm working on the DPM replacement.

I got around to write the module. Can you/someone take a look and give it a shot.
To use:
- Enable the uc_credit module (I could set it up to not require the uc_credit module, but currently I am using this to figure out which cards are enabled)
- Setup the authorze.net settings for DPM

test. I also have added a javascript file to validate that credit card number, type, expiry and cvv codes are entered and credit card passes the luhn's test (right checksum) before submitting it to authorize.net.

Thanks; you've saved me some work here. I'd gotten buried in other things before Christmas, and was planning to finish my own version of this up over the holidays.

I had a quick look at your implementation, and here are a few observations:

1) There's a typo at line 415 of the .module file; preg_match() needs delimiters around its regular expression.

2) There's a string typo in line 211 of the .module file ('DIM' should be 'DPM').

3) The CSS formatting of the new cart review pane for the CC data entry should match the rest of the table.

4) I understand why you supplied client-side checking for the CC data, but the result is (of course) inconsistent with the normal Drupal server-side form validation and looks a bit jarring. Since authorize.net is already checking the data and gets the final say anyway, perhaps it would be best to dispense with the JS checks and simply try to parse or reformat its error response data to present to the user via the normal drupal_set_message() mechanism. Also, it will save the customer some data re-entry if uc_authorizenet_dpm_order_complete() redirects errors via:

rather than:

5) Since we can (hopefully) rely on authorize.net to redirect back to the site after you send back the post response, you might want to modify the processing in uc_authorizenet_dpm_complete() and uc_authorizenet_dpm_order_complete() to look more like the original (i.e. like PayPal Standard). This is worth doing because the current logic, like that of its relay-response predecessor, doesn't execute the standard:

Failing to do this circumvents the processing of Ubercart's Google Analytics sub-module. It's necessary in the relay-response case, but probably not here. We ought to be able to avoid calling uc_cart_complete_sale() in the _dpm_complete() function, and instead execute the code above in _dpm_order_complete() to finish up the transaction normally. Correct me on this if I'm missing something; I haven't looked at it in detail in a few weeks.

Finally, nice work! We should polish this up and get it released for wider use. I can help you with that, if you don't have developer access on drupal.org yet.

Thanks for the feedback. Very useful

Regarding, first 3 points, I will fix those typos etc.
Regarding 4th, I haven't seen what checks php server side code does on the CC data, but I can take a look and match that with javascript code. The idea of javascript code is to catch basic errors on the form before sending to authorize.net, which I am sure some of those are being done by server side code. If the user enters data correctly, the javascript will be a no-op anyways.

Regarding 5, I am not sure if sending to car/checkout/complete will work, as we need to send the redirect code back to authorize.net unless we modify the callback function. What I could do is to copy the uc_cart_checkout_complete function or instead of goto, call the function and ignore the output and send the redirect output to authorize.net. If we don't do complete sale in _dpm_complete() instead we want to postpone it till user is redirected to _dpm_order_complete, we have to somehow maintain state between the 2 calls (save something in the order?), so that we know call to _dpm_order_complete is a legitimate call. The problem with redirects is that, there is no way of telling who redirected. May be we can generate a unique hash and redirect to /cart/authorizenet_dpm/order_complete/unique_hash and use that as link. Or am I totall mis-understanding what you are asking?

definitely as you said, let's polish it up and we can release it to wide audience.

I think that it would be more consistent with other payment modules (and thus less likely to introduce unanticipated problems, such as the aforementioned Google Analytics issue) to wait until _dpm_order_complete() to goto cart/checkout/complete and allow it to call uc_cart_complete_sale(). I like the idea of using a hash as a redirect argument for this in order to validate the redirect.

OK, so did some rewrite so that I can call cart/checkout/complete and realized the same code could be used for SIM method as well (SIM and DPM are essentially the same with the only difference where you collect the credit card number). You can choose SIM vs DPM in the module settings page. I changed the name of module to uc_authorizenet_redirect. The module now

1. Collects the credit card number (if using DPM)
2. submits the form to authorize.net
3. User enters credit card number on authorize.net site (if SIM)
4. authorize.net does a call back to cart/authorizenet_redirect/complete
5. Module validates the call and enters the payment if valid call. Generates a hidden form with action to siteurl/car/authorizenet_redirect/complete (again) with an additional form field x_after_redirect set to 1 and a redirect validation hash
6. the returned html to authorize.net has the form with automatic form submission on load (form is hidden so user does not realize there was a form submission)
7. the module upon form submission sends user to cart/checkout/complete

Check it out. I have tested it and it works in both SIM/DPM.

Ran into a problem testing this against the authorize.net sandbox. In both SIM and DPM modes, according to the log, the transaction failed with an MD5 hash check. No hash was set in the module preferences, as there's no way to configure the hash on the authorize side for the sandbox, so it shouldn't have been checking this at all. Your previous version didn't exhibit this behavior, for what it's worth. Can you duplicate this?

Couldn't get far enough to check, but has the SIM mode reverted to the behavior where a customer can bail out on the relay response form without clicking to return to the site, and thus avoid the cart/checkout/complete processing? Avoiding that situation was point of enabling relay response for SIM - folks were successfully paying but their payments weren't recorded.

I was testing with live_test environment. But it should have worked in sandbox as well. Anyways, I have made some changes (basically created another key for validating redirect response instead of using authorize.net md5 hash) which is more secure (prevents anyone from collecting random data and hashed values + it is now independent of whether or not you want to use md5 hash on authorize.net. Test the new code. You will need to disable the module, then re-enable it and the go to settings and save it again (the redirect hash key is automatically generated with a random string). Please test it and let me know.

As for changes in SIM, there has been no change. Authorize.net basically throws back the html to the user that SIM redirect url sends to authorize.net. In that html, I have added a documnet.onLoad event which clicks the button (submit the form) without user intervention, so user never gets to see that page, instead they see the checkout complete page.

OK, that worked fine in both modes via the sandbox. The JS auto-submit removes my concern about incomplete orders in SIM mode. Both modes are now using the normal order completion path, which is considerable improvement, and DPM looks seamless (as it should).

It's probably about time to toss this up on d.o as a dev release and let folks hammer on it. Since this is mostly your own work now, you likely should release it there yourself. If you haven't applied for a CVS account on d.o, you can do that here:

http://drupal.org/node/59

Have you run it through the Coder module yet?

Nice work! This is a very helpful addition to the Ubercart payment options. I expect to use it heavily myself, to avoid dealing with PCI certification hassles.

Will do (CVS access). Should the module go in Drupal or Ubercart contributed modules?
I am going to clean the code a bit (Right now I am creating form with all of the POST fields from authorize.net, I will remove that and create the form with only necessary fields etc) and then run it through coder module.

Thanks and please feel free to make any changes to the code.

Made few more changes including some cleaning up

1. Option to include relay-response url in form to be submitted to authorize.net
2. Option to provide custom relay response url (like your/secret/path instead of default cart/authorizenet_redirect/complete)

For first option to work, you must specify the relay response url in your authorize.net account settings on authorize.net website. With the 2 options above, you can operate in a more secure mode where user does not get to know the url for reporting transactions back.

Dis some clean up. No longer including the response from authorize.net back to user. Only order_id/cart_id/message is sent back to user.

With these changes, I now feel comfortable to use it in production site.

Did some additional cleanup, fixed some HTML validation issues, ran it through Coder and tweaked it as required, etc. Results attached.

Happy to server as a co-maintainer on d.o if you like.

Thanks. Will take a look. Sure no problems from my side to be maintainer or co maintainer

Hello, I see you have made a CVS request on d.o. This will be a valuable new module, thank you.

I've been testing your module, good work.

I notice that when posting in test mode to the developer account, the code is setting x_test_request to TRUE. In this case, the transactions did not get logged and I could not see evidence in my test.authorize.net account of the transactions. However if x_test_request is set to FALSE, and the transaction is posted to https://test.authorize.net/gateway/transact.dll, then the transactions will appear. My suggestions: you could either create four modes (including test in test account and live in test account -- very confusing), or better, use the modes in the other authorize.net module: "Live transactions in a live account," "Test transactions in a live account," "Developer test account transactions" and make the the last submit with x_test_request =FALSE.

Hope that makes sense!

If I understand it right, you are asking

Test Mode - x_test_request = False
Test Mode in Live account - x_test_request = True
Live mode - x_test_request = False

Let me test and will make the change.

Thanks for the feedback.

Updated with x_test_mode set to false in Test mode. You can now check your transaction on authorize.net sandbox site,

Hi again, we're testing your module. I don't see your module on d.o. yet so getting in touch here. There is a small bug in the js that checks the CVV.

line 57:
var validcvvlen = 3;
if (form.cc_type.options[form.cc_type.selectedIndex].value == "AmEx") {
valdcvvlen = 4;
}
if (!(form.x_card_code.value.length == validcvvlen)) {

The variable is misspelled on line 59. 'valdcvvlen' should be 'validcvvlen '.

Thanks!

Hi Guys,

First, thanks so much for creating the module! This is saving me a lot of work, even though it's in dev. Can't wait to see it in contrib!

I was wondering though, why did you put the form for cc entry under order review. I'm working right now to see if I can take the billing info, the cc info and compile everything at once at the review page to submit to auth.net. That way it would be less steps for the user. What do you think? If you feel like changing it around I'd thank you a whole lot, since i'm not good enough to know how to work these things around.

The whole idea (in my mind) of SIM/DPM is that the credit info does not go to your site. If you collect the info on previous page and than consolidate at review page, you would have defeated the purpose because you would have received the credit card info at your site. The only two ways I can think of collecting the credit card info on the previous page would be either don't show the review page and directly submit to authorize.net from there (not a good idea) or create the review page on client side itself using javascript.

What do you think?

I agree that the review page should stay; it serves a useful purpose. My original idea for this was to put the payment form on a subsequent page, rather than the review page, as this is essentially how PayPal Standard and the SIM mode work. Tacking it onto the review page does save a step over that approach, and perhaps that's a good thing.

You are absolutely correct, of course, that the point of SIM/DPM is to avoid PCI scrutiny of the Drupal site by off-loading all card handling to Authorize.net. If you're willing to jump through the PCI compliance hoops, you should just use AIM.