WP Callback Problem - Intermittent

[MartinDay007]

Hi guys

 

We are using WorldPay's Select Junior product.

 

Starting on 11 Oct 2011 we have been having an intermittent problem with our WorldPay call back procedure.

 

Basically the transaction and payment is successful but the order is not always fulfilled, as it fails at the orders SQL insert statement.

 

There is nothing wrong with the insert statement, (it has been working for years and hasn't changed and is a simple SQL insert statement that seems to be passing all the correct information).

 

It fails for about 50% of the orders, there is no pattern that we can see as to what works and what fails, but when it fails for a customer it fails every time they try it (which would be good as a get rich quick scheme if only we didn't have to give it back).

 

When we reported the problem to WorldPay they traced the problem to the SQL insert statement so they passed the problem back to us.

 

Every time we try a test transaction it works 100% of the time.

 

Every time we try and reproduce the customers environment it works as a test transaction.

 

We have tried to look for a pattern with respect to types of order, return customers, new customers, browsers, operating systems, server response rate but there is nothing that is consistent other than the call back regularly fails.

 

We have considered a number of possibilities but all have been proved wrong to date, it is almost as though the SQL statement is being actions, but not always before control has been fully returned to our server.

 

Is anyone else suffering a similar problem, that started around 11 Oct 2011?

 

Does anyone have any suggestions as to how to trace and identify the problem.

 

Our suspicion is that this is a WorldPay problem, but it would help us rule out our side if other people are have similar problems.

 

Cheers

 

Martin

[Taipo]

Ask your webhost if they have recently installed Suhosin. If so the default setting for suhosin.get.max_value_length is 512 which is probably too short a limitation for most callback requests.

[wolfmann99]

Hi,

 

We are experiencing exactly the same problem...the failure appears to be around 10% of orders. We receive an email from Worldpay telling us the the purchase has been made but the user never reaches checkout_success.php, and there for the the osc admin does not wnow what the customer has pordered. This has been happening for some time now more than a year but has got worse in the last three months.

 

We have tried the solution above regarding the suhosin.get.max_value_length but it has not solved the issue.

 

Has anybody else experienced this issue or can offer a solution?

 

Thanks,

 

Nick.

[The Cleaner]

I cannot get the callback to work at all when I got in touch with worldpay they said it is because the https:// isn't on the url

I think it has to be edited here but don't know how

 

tep_draw_hidden_field('MC_callback', substr(tep_href_link('ext/modules/payment/worldpay/junior_callback.php', '', 'NONSSL', false, false), strpos(tep_href_link('ext/modules/payment/worldpay/junior_callback.php', '', 'NONSSL', false, false), '://')+3));

 

[Bob Terveuren]

Hi

 

Try swapping the two instances of NONSSL to SSL - should do the trick

[The Cleaner]

No didn't work. This is on the one page checkout it works fine on the multi page checkout

[justinswa]

Ask your webhost if they have recently installed Suhosin. If so the default setting for suhosin.get.max_value_length is 512 which is probably too short a limitation for most callback requests.

 

I've been having this intermittent problem with callback too. Site was OK for at least a year then it started happening a few months ago. Has anybody tried this Suhosin fix with any success?

[justinswa]

Hi guys

 

We are using WorldPay's Select Junior product.

 

Starting on 11 Oct 2011 we have been having an intermittent problem with our WorldPay call back procedure.

 

Basically the transaction and payment is successful but the order is not always fulfilled, as it fails at the orders SQL insert statement.

 

There is nothing wrong with the insert statement, (it has been working for years and hasn't changed and is a simple SQL insert statement that seems to be passing all the correct information).

 

It fails for about 50% of the orders, there is no pattern that we can see as to what works and what fails, but when it fails for a customer it fails every time they try it (which would be good as a get rich quick scheme if only we didn't have to give it back).

 

When we reported the problem to WorldPay they traced the problem to the SQL insert statement so they passed the problem back to us.

 

Every time we try a test transaction it works 100% of the time.

 

Every time we try and reproduce the customers environment it works as a test transaction.

 

We have tried to look for a pattern with respect to types of order, return customers, new customers, browsers, operating systems, server response rate but there is nothing that is consistent other than the call back regularly fails.

 

We have considered a number of possibilities but all have been proved wrong to date, it is almost as though the SQL statement is being actions, but not always before control has been fully returned to our server.

 

Is anyone else suffering a similar problem, that started around 11 Oct 2011?

 

Does anyone have any suggestions as to how to trace and identify the problem.

 

Our suspicion is that this is a WorldPay problem, but it would help us rule out our side if other people are have similar problems.

 

Cheers

 

Martin

 

long time ago, but did you find a solution?

[Taipo]

I've been having this intermittent problem with callback too. Site was OK for at least a year then it started happening a few months ago. Has anybody tried this Suhosin fix with any success?

 

When Suhosin is installed, the string length for the suhosin.get.max_value_length is 512. In order for a callback to succeed that setting would need to be something closer to 2000+.

 

The problem I believe is that Suhosin is applied at a server level and server admins will probably not allow a change in their server configurations merely because one of the many thousands of websites on their server has a malfunctioning callback.

 

But there is no harm in trying.

[justinswa]

When Suhosin is installed, the string length for the suhosin.get.max_value_length is 512. In order for a callback to succeed that setting would need to be something closer to 2000+.

 

The problem I believe is that Suhosin is applied at a server level and server admins will probably not allow a change in their server configurations merely because one of the many thousands of websites on their server has a malfunctioning callback.

 

But there is no harm in trying.

 

Thanks, but found that suhosin isn't on my server anway. Currently waiting to hear back from Worldpay (who aren't exactly quick...) about failed callback logs

[justinswa]

OK, I may bet getting somewhere....,this is the Worlpay log for a failed callback:

 

[2013-09-09 20:23:01.919 (TID:msg2Conn3-375162)] Starting callback handling

[2013-09-09 20:23:01.930 (TID:msg2Conn3-375162)] LegacyCallbackURLProcessor: Converted from '<WPDISPLAY ITEM=MC_callback>' to 'www.mysite.com/catalog/ext/modules/payment/rbsworldpay/hosted_callback.php'

[2013-09-09 20:23:01.930 (TID:msg2Conn3-375162)] --- Exception in Callback handling ---

[2013-09-09 20:23:01.930 (TID:msg2Conn3-375162)] com.worldpay.aequitas.message.callback.CallbackException: Relative URLs are NOT supported as callbacks

 

well I thought that www.mysite.com/catalog/ext/modules/payment/rbsworldpay/hosted_callback.php was an absloute URL. But is the problem that the actual callback URL in worldpay admin is <WPDISPLAY ITEM=MC_callback>, which is then converted to the absolute URL? Will it work if I enter www.mysite.com/catalog/ext/modules/payment/rbsworldpay/hosted_callback.php in worldpay as the callback URL?