Checkout complete actions not triggered

I had this too and think I have understood why this happens and how to fix it... BUT unfortunately it involves hacking ubercart's cart module but I'm not sure how to do it without doing this.

Why is this happening
It's because of the way RBS Worldpay's callback mechanism works. Worldpay's server request the completion page from your site to show the completion page to the user. Their server's generate the request and not the user's so Drupal does not have access to the correct $user. This breaks the logic in the uc_cart_complete_sale function - specifically the line

  ca_pull_trigger('uc_checkout_complete', $order, $user->uid == 0 ? $account : $user);

As user uid does equal 0 but $account as not been set because $order->uid is not 0. Therefore a null is passed in where a drupal user account should be.

Solution
Edit the part of the function that deals with existing account...

  if ($order->uid == 0) {
    //.... leave all the stuff for anonymous user's alone
  }
  else {
    //If the order is not anonymous but the $user is anon load up the order's uid - this probably from a RBS worldpay callback
    if ($user->uid == 0){
      
      $account = user_load(array('uid' => $order->uid));
      $message_type = 'logged_in';
    }
    else {
      if ($order->uid == $user->uid) {
        $message_type = 'logged_in';
      }
      else {
        $message_type = 'existing_user';
      }
    }
  }

A possible other solution

• Save the $user global in the uc_ubercart.module to $anon_user
• Load the correct user into $user
• Call uc_cart_complete_sale
• Set the $user back to $anon_user

However I'm not sure of the security aspects of this...

Thanks alexpott! You're my hero!

I was having the exact same problem and had no clue what was going on until I saw your fix (which worked wonders) :)))

Hi,

Thanks for this alexplot ! I would rather not patch ubercart itself, and would rather patch only uc_worldpay - less maintenance in the future. So starting from your idea, I did something different : I made it so that uc_worldpay doesn't call uc_cart_complete_sale function, but instead moved the relevant bit of logic from uc_cart_complete_sale into uc_worldpay.

The downside is that uc_worldpay will be more sensitive to changes within ubercart - but since the only current alternative is to patch ubercart itself, that does not make a difference.

This patch also allows the uc_worldpay messages to be themed. It doesn't use the 'page' template but allows to use another one - people might want to use another template, as the cookies are not avaiable.

I'm setting this on "needs review" - it would be good if people could have a look at the various solutions, or propose other solutions, so we could have a working uc_worldpay module !

Anselm

I've discussing this issue with ubercart people here http://drupal.org/node/487698... from my investigation I think that other payment methods might have the problem too...

Anselm

Thanks for posting this patch.

I am currently trying to implement the worldpay payment gateway on a 5.12 site with Ubercart 1.2 and uc_worldpay 1.x dev

I am assuming that the patch above was specifically designed for 6.x 1.0 module. Whilst I have manually patched the module, the final section confuses me. What was the purpose of this change so I can create a patch for the development shot?

@@ -334,5 +435,8 @@
'uc_worldpay_cards' = array(
'arguments' = array(),
),
+ 'uc_worldpay_redirect' = array(
+ 'arguments' = array('message' = ''),
+ ),
);
}
No newline at end of file

Ok - I have patched the file for the 5.x 1.x dev version and I still get the same response - ie no callback from worldpay to complete the order. This is more of an fyi for people trying to use the patch more than anything else.

OK - this took a LOT of time to find.

For those people who are still struggling. RBS changed their ltest server address to:

https://secure-test.wp3.rbsworldpay.com/wcc/purchase

I currently don't know what the live server is because my account has not gone into production.

The SECOND thing that I had to do was add the call back address to the profile. This HAS to be done inside worldpay, and I currently can't see a way to force send this from the website side of things.

The call back address is: (payment response address)

cart/worldpay/complete

I still have a few problems, but I will hopefully get to the bottom of these soon.

This was fixed in uc_cart.module, exactly a month ago today :) see #487698: Not getting order notification e-mails - Checkout completion action not triggered?

Please see my notes here:
#614136: UC_Worldpay module - a few issues.

I have this problem.

I can complete payment on Worldpay, but nothing happens on my site. No order is registered, the cart isn't emptied, no emails are sent. I have the latest revision of uc_worldpay from CVS and ubercart 6x2.2.

I've set the Payment response URL within Worldpay, enabled payment response and shopper response. Is there something else I should be doing?

I've read mtraherne's notes, but that issue seems to be for v5, and it's been closed.

Should this be working?

When the processing is complete on the Worldpay server does it pull in a page from your site and display it?

Do you get any error information at all?

No, no page is displayed. I just get the Worldpay completion page saying the payment has been completed. I'm using Worldpay's test interface by the way.

Can you confirm that your payment response URL is publicly accessible?

No, it's not at the moment because my site is in maintenance mode. But I'm testing payments and orders while logged on as admin so I should be able to access it. Unless I'm misunderstanding you. My payment response URL is /cart/worldpay/complete - I haven't done anything to configure this page. Should I have?
Sorry if I'm being dense...

I suspect that's your problem. When Worldpay completes the processing on it's server it calls your response URL in the background firing the cart complete code etc, your server serves it some HTML and it pulls it across the line and displays it as if your site is on RBS's server, check the URL at this point and you'll see what I mean.

So in short I don't think you'll have much just in maintenance mode.

Ok, yes I see. The response url is now working. The problem with logged in users being shown as logged out after payment remains. Comment #8 in this issue http://drupal.org/node/369096 mentions it and gives a solution here in #3. Has the patch been tested?

Yep that problem occurs because of the way RBS Worldpay works, you're actually on their server at that point hence the view you see is that of an anonymous user.

I must confess, I haven't properly looked at the patch in comment 3.

Hi all,

Sorry for posting as I feel I may have missed something along the way...I'm having great difficulty in getting products out of "in checkout" on my site now that I'm using the production side of RBS after everything was working OK on their test environment.

Is there a definitive version of uc_worldpay or patches to use? I'm currently up to date with Drupal and Ubercart as of todays date and I'm using uc_worldpay from head following the issue found with the dev version using the D5 menu hook.

I thought the problem was related to anonymous checkout but after disabling that and making sure users register first and I also have "Login users when new customer accounts are created at checkout" enabled in /admin/store/settings/checkout/edit....I'm not so sure now.

One other thing that was a concern when I was speaking to tech support at RBS was the fact they told me to disable Google Analytics as it's now on some sort of untrusted list with the credit people :S

I did disable the Ubercart GA side of things as I thought it may just be that, but have since had another transaction not go through to "Payment Received" since then. I will try a test payment later with GA fully disabled but somehow feel this is not going to be the cause.

All settings from the RBS test account were transferred over to the production side so in theory everything should be fine, including the response address.

Any help would be greatly appreciated as always.

Many thanks

Hi Axel,

I'll take a look this evening.

Hi matason,

Thanks for getting back so quickly. I'll be running some tests and will be online as much as possible over the next couple days so if there's anything I can do to help then please let me know.

Thanks again :)

Hi Axel,

I've just re-read your comment:

I'm having great difficulty in getting products out of "in checkout" on my site now that I'm using the production side of RBS after everything was working OK on their test environment.

Could you double everything is set correctly in the production merchant interface? In particular the Payment Response URL... it should be something like http://www.example.com/cart/worldpay/complete and this should be publicly accessible.

Hi matason,

I've triple checked the response url in the Production Environment and can confirm that the url is definitely;

http://www.sitename.com/cart/worldpay/complete

This information worked perfectly when using the test environment and I used the transfer settings option within RBS to set the Production values.

I have just switched back to test and carried out purchases as the following;

Superuser
Pre-registered user
New account registration via purchase

..and all OK

Just testing live again now...

Update:

Carried out numerous tests on live for different scenarios, one or two failed and then everything just started to work. We were happy that everything was going OK...BUT there has just been another sale and it is stuck "In Checkout"!

This is appearing to be random now as to whether or not sales go through!!! Everything looks OK in the RBS interface with the payment, apart from the fact that there was a 16 minute delay between payment AUTHORIZED and payment CAPTURED - could this possible make a difference?

Thanks for any help

Still having major problems with this. Even RBS are are running out of ideas... especially seeing as the last two tests carried out with their tech support guy involved resulted in one failure and one success!

Both payments were made by same user with same card details.

RBS tech support are requesting the logs and will check over them tomorrow to see if there's an issue with the 3D secure responses.

Is anyone else currently having problems?

Hi Axel, the intermittent problems are the hardest to track down :( and it seems like this could be specific to your environment/configuration if no-one else is experiencing it.

Maybe some other module is interfering?

Are you a coder? Add some debugging and following the process through till you identify the point in the code at which you get the intermittent behaviour. I usually pick a point at the start of the process and prove to myself the function is getting the values it's expecting then I trace those values through function by function.

Maybe there are configuration changes you can make, change one thing at a time, see if that tells you something about the problem ie. If I switch this option off it always works, switch it back on and the problem comes back etc...

I hope some of this is helpful and you get to the bottom of the issue.

I'm only using test environment at the moment and am not having problems. But will be switching to production soon, so will report back if I experience anything similar.

@matason - Thanks for getting back to me. I've just tried another purchase using the RBS test environment and the first purchase failed with "There was an error with the transaction. The host did not match."...I have a feeling this may have happened before as well but can't be sure. The other odd thing with this transaction was that after the process had failed and I returned to my site from RBS's I'd been logged out!!! Every test purchase since that happened has been successful.

I have a feeling this is what is happening with the production environment as well.

I must admit, I'm not sure how I would debug this at code level. Not sure which modules to try and disable...The site uses uc_edi but at the minute this isn't being utilised so I could try that one.

@freatida - Thanks for your feedback. Can I ask which version you are using, 1.0-beta1, 1.x-dev (which I assume still has the D5 menu bits in?) or HEAD?

I don't think I mentioned it yesterday but RBS told me to disable just about every bit of JS on the callback page and their logs that were sent through had been busy stripping out loads of other bits as well. As a result I had to disable Google Analytics for the callback page and create a page-cart-worldpay-complete.tpl.php page that stripped out the following from the default page.tpl.php (from an old version of the Basic theme);

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $language->language ?>" lang="<?php echo $language->language ?>" dir="<?php echo $language->dir ?>">

<?php echo $scripts; ?>

This was more of a proof of concept for RBS's benefit but even with this we still had failure followed by success

:'(

@Axel I'm using HEAD

Great, thanks for that info!

I've just got off the phone to RBS 'again' and we think we've narrowed it right down...the problem appears to be with the value given in M_http_host

When response fails to trigger the address is given without www. - even when the user is on www.sitename.com, successful responses include www. in M_http_host.

Does anyone have any idea why this could be randomly flipping between the two?? I've just added a mod_rewrite to force the site to use www. - Not sure this will help though as I know for a fact that failed responses have been sent when physically on www.

Hi Axel,

Just wondered whether you had resolved this issue or whether you're still experiencing problems?

Closing, assuming no longer an issue - please re-open if necessary.