Payment is not created upon succesfull Ogone payment

Hmmz you are right. Kees, any reason for this not being in there?

I will need uc_Ogone soon and see if I can provide a patch if Kees doesn't have a particular reason for it not being in there.

Cheers

Erm the maintainer ;)

Hi,
Is this still the case on 1.8?

Could you say it in code please?

greetings,
Martijn

Its still a case. I will look into it and try to commit a patch, but for the version 1.9 module.

Hi,

This patch solves this issue.

Regards,

Hadrien

This patch solves the problem.

Nice, #6 works for me thanx!!!

Cheers

It seems like this patch creates another error:

Duplicate entry '10721' for key 'PRIMARY' query: INSERT INTO uc_payment_ogone (order_id, description, payment_method, order_status, sha1_test_succes) VALUES(*******) uc_ogone/uc_ogone_payment.module in Zeile 532.

This is the line in Function uc_ogone_return_ok():

 db_query("INSERT INTO {uc_payment_ogone} (order_id, description, payment_method, order_status, sha1_test_succes) VALUES('%d','%s','%s','%s','%s')", $orderid, $description ,$pm, $status, $sha_test);

I had that error often before applying the patch, didn't have it anymore after applying it?

Cheers

#6 worked for me as well. I am a bit confused because Ogone Ubercart did work before. Or did this started happening in 1.9?

Anyway I'd suggest changing the last line of the patch to:
uc_cart_complete_sale($order, variable_get('uc_new_customer_login', FALSE));

So automatic login for new users keeps working.

EDIT - further findings:

I found out that with this patch the order is completed twice and therefore sending emails twice as well.
I believe this very same line is causing this. It completes the checkout and immediately after that your are redirected to cart/checkout/complete where the same function is invoked.
Removing the line seems to work for me.

@wjroes you are right;

function uc_ogone_ok() {
    /////////// clipped code //////////
    uc_cart_complete_sale($order);
    
    // Ensure the cart we're looking at is the one that payment was attempted for.
    $_SESSION['cart_order'] = $_SESSION['ogone_order_id'];
    unset($_SESSION['ogone_order_id']);

    // This lets us know it's a legitimate access of the complete page.
    $_SESSION['do_complete'] = TRUE;

    drupal_goto('cart/checkout/complete');
  }else{
    drupal_goto('cart/ogone_false');
  }
}

After uc_ogone_ok() does a uc_cart_complete_sale() call it does a drupal_goto('cart/checkout/complete'); which calls the uc_cart_checkout_complete() function in uc_cart.pages.inc. In this function another uc_cart_complete_sale() call is made ( $output = uc_cart_complete_sale($order, variable_get('uc_new_customer_login', FALSE));)

So indeed uc_cart_complete_sale($order); does not need to be called by uc_cart_complete_sale($order);

New patch attached!

Cheers

After some more testing I found out that many Ogone transactions never get to a Completed state. Even though the Ogone transaction completed succesfully. Apparently a number of customers close the transaction window after it has been completed and before they return to the shop. This leaves the order in Checkout state.
I am wondering why the uc_ogone_return_ok function redirects to the uc_ogone_ok function where the transaction is completed. This involves another redirect that causes the transactions to not be completed in certain circumstances. Why isn't the transaction finished completely inside the uc_ogone_return_ok function?

I suggest that we move the order updating routines from uc_ogone_ok to uc_ogone_return_ok. This way the order is updated to a Payment Received status even if the user decides to close the browser in between. This will then match the actual Ogone status.

Any thoughts?

I've encountered the same issue as well, people don't wait on the redirect and close the window.
Moving the routines sounds like a solution, not sure what effect this change would have though.

Cheers

Has anyone looked into this yet? Getting more and more orders in checkout which actually have been payed for?!

Cheers

I moved most of the transaction completion code into the function uc_ogone_return_ok. This function is called by Ogone and will now update the status in Ubercart. You do still need the function uc_ogone_ok to make sure the session is kept alive.

@wjroes, could you provide a patch for testing?

Cheers

Euhhhmmm... probably but the file needs some cleaning up. Can I send you the file so you can roll it in a patch. It is just the .module file.

Did you clean up the file already? I am also interested in a fix for this problem :)

Hi Robbert,

No, not really. In the meantime I had to upgrade ubercart to 2.6 as well, so I ran into loads of new and old problems. See http://drupal.org/node/1304188

At the moment I seem to have it working again by changing some stuff. These are changes, however, on the latest dev and I cannot believe that this is the way to do it, because I don't think Ogone Payment does work without these changes at all.

Willem

Hi Willem,

I just made a fresh Drupal installation. So i am using the latest Ubercart as well. With the patch from #12 it is working, as long as the customers don't close the window (and dont wait till they get redirected), right after the payment is finished. I didnt find other bugs at the moment.
Do you know what you changed to solve my problem?

Payment is also not created after finishing a succesful payment and clicking on the button "Go back to shop". My order stays in the state 'In checkout' but receiving an confirmationmail of Ogone that i paid

You see. That's what I meant with all kind of problems :D

There were related problems caused by the Ogone configuration. I my case we're using different domains for the same shop, i.e. .nl/.de/com etc. With the standard Ogone configuration the redirects from Ogone were sent to the wrong domain leaving the orders in "Payment Received" state.

A different configuration problem was the fact that I had permissions granted to admin users to "show prices without tax" or something. That totally screwed up the order when you went to look at the order in the order list in Ubercart.

@wjroes, Can you send or attach the changed code? I will diff the files and create a patch file.
Does it also solve the duplicate entry errors (e.g.: user warning: Duplicate entry '0' for key 'PRIMARY' query: INSERT INTO uc_payment_ogone (order_id, description, payment_method, order_status, sha1_test_succes) VALUES('0','description','','','OK') in)

I think it does. Remember it is just a *dirty* fix that works in my instance. I am surprised that with the way the code was, it is working for others.

My uc_ogone_payment.module attached...

This is a patch based on the latest dev from the code of #25(@wjroes). Thank you wjroes

in funtion uc_ogone_return_ok i removed trim function. Ogone creates sha1 with untrimmed values while this modules creates sha1 with trimmed values. I fixed this in my project and that solved the problem. Please fix this in future release. Thanks

#27 Can you elabore how to reproduce this bug? Here its working without removing the trim function.
I just uploaded my changed uc_ogone_module, see http://drupal.org/node/1391626.
I renamed the function uc_ogone_return_ok to 'uc_ogone_update_status'.

It should be easy to reproduce. Just submit an order and add a space at the end of one of the fields you use for sha1 calculation. IMHO it's asking for troubles if you modify one of the parameters before sha1 compare.

#29 You are right. But this only occurs with production settings. I made a new patch as you can see in http://drupal.org/node/1391626

Fixed in the 6.x-2.x branch.
See http://drupal.org/node/1519734