HSBC Secure Epayments to Global Iris (Realex)

[Mike Hughes]

From what I can see the process is ~

-> Send customer to realex
-> Customer pays
<- Success callback to your website
-> expect response from your site to display to customer*
<- optionally return customer to receipt page

* From what I can see the 'epage.cgi' reference is the page on realex that should display your response (getmerchantcontent) and the 'invalid data in merchant_ID' is the usual display text when there's an error in that response.

Mike

[gcamley]

I don't recall blaming anybody as yet.

My apologies re the URL. It is a request to os000001.pl from RealEx (I have checked the IP address belongs to them).

POST requests unfortunately do not show the request data, only the URL so I can't say for sure that it is the authorisation call back as the call back to get the receipt would look similar if not the same.

To see the data passed by RealEx and the response sent back to RealEx you will need to enable the debug suggestion I made earlier.

[feemish]

Realex have been blamed earlier in the thread.
The integration has been shown to have flaws already.

I have looked through the whole of my access logs for today and have matched the callbacks from other successful orders. The callbacks from successful orders are the same as the callback previously posted for the failed order. I can only surmise from this that the callbacks are indeed happening as Realex said, but for some reason sellerdeck is not passing these onto the orders.

I suspect an error in the integration.
The fact that the customer immediately after the failed callback order received the error message;

invalid data in merchant_ID

and yet his order was successful, seems to point to some kind of hangover from the previous order.. but of course I have no idea what I'm talking about,

I will enable the debug as suggested.

[feemish]

From what I can see the process is ~

-> Send customer to realex
-> Customer pays
<- Success callback to your website
-> expect response from your site to display to customer*
<- optionally return customer to receipt page

* From what I can see the 'epage.cgi' reference is the page on realex that should display your response (getmerchantcontent) and the 'invalid data in merchant_ID' is the usual display text when there's an error in that response.

Mike

thanks Mike thats how I read it too.

[Mike Hughes]

The fact that the customer immediately after the failed callback order received the error message;

Quote: invalid data in merchant_ID

and yet his order was successful, seems to point to some kind of hangover from the previous order.. but of course I have no idea what I'm talking about,

I wouldn't think there's any hangover from previous orders. These will all be running their own thread on the scripts making cross corruption unlikely.

I suspect it's just that his callback was successful but that the process in this case failed to send back the expected display response to realex.

It definitely looks like a problem at your end. What's causing it is still a mystery. Particularly as it appears intermittent which makes it hard to point a finger at any particular bit of the process.

Mike

[Mike Hughes]

By the way. This bit is bugging me:

121.75.145.47 - - [13/Dec/2012:06:39:50 +0000] GET /cgi-bin/os000001.pl?ACTION=GETPSPFORM&PAYMENTMETHOD=56&timestamp=1355293990427 HTTP/1.1 200 2288 http://www.arka-shop.co.uk/acatalog/ Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; MATP)

Why does it reference /acatalog/ in the url?

Surely all connections to and from realex will be via the cgi-bin so should acatalog be appearing at all?

Is this because you've set /acatalog/ as the homepage in your network settings or is this normal behaviour?

It could all be correct but it just looks out of place to me.

Mike

[feemish]

This is the customer clicking pay and going to Realex

121.75.145.47 - - [13/Dec/2012:06:39:50 +0000] GET /cgi-bin/os000001.pl?ACTION=GETPSPFORM&PAYMENTMETHOD=56&timestamp=1355293990427 HTTP/1.1 200 2288 http://www.arka-shop.co.uk/acatalog/ Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; MATP)

This is the successful call back from Realex

193.105.253.110 - - [13/Dec/2012:06:40:59 +0000] POST /cgi-bin/os000001.pl HTTP/1.1 200 262 - epage.cgi, getMerchantContent libwww-perl/5.805

this is an example of the customer clicking 'finish' and viewing the recipt page

87.112.147.232 - - [13/Dec/2012:09:19:46 +0000] GET /cgi-bin/os000001.pl?SEQUENCE=3&ACTION=Finish&ORDERNUMBER=DN28QS10028379&REFPAGE=http%3a%2f%2fwww%2earka%2dshop%2eco%2euk%2facatalog%2fprecious_stone_flesh_plugs%2ehtml& HTTP/1.1 200 7705 - Mozilla/5.0 (Linux; U; Android 2.3.3; en-gb; GT-P1000 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

the customer for the dodgy order did not click 'finish' and view receipt page.

I think its now pretty certain that Realex are correct and they are giving the callback, and it is reaching the server. The fault must lie within either the server or actinic. I have exhausted possible problems with the server, that leaves the actinic/sellerdeck integration.

Its been shown to be faulty already previously in this thread... Please.. its the INTEGRATION

I have used the HSBC SecureEpayments integration for 5 years on this server with not one single callback failure.

[gcamley]

We could make progress on this if you make the change for the debugging level.

ATM it looks like the request reaches the server but we don't know if it reaches the script or what the script is seeing in the POSTed data.

If the requests gets as far as the script then this debugging will tell us what the passed data is and what the response is.

If the authorisation request failed then there ought to have been a message in error.err. As there isn't then either the request did not reach the script or the script failed to record the error.

[feemish]

By the way. This bit is bugging me:



Why does it reference /acatalog/ in the url?

Surely all connections to and from realex will be via the cgi-bin so should acatalog be appearing at all?

Is this because you've set /acatalog/ as the homepage in your network settings or is this normal behaviour?

It could all be correct but it just looks out of place to me.

Mike

Thanks Mike I'll look into this and compare it to succesful orders.. back in a bit.

in my network settings I have
www.arka-shop.co.uk/acatalog/ as the catalogue URL
but I have
www.arka-shop.co.uk as the website URL

[feemish]

I have enabled debugging

[Mike Hughes]

I'm sure this will be same on all orders. It's just the kind of thing that might trip up the process somewhere. I'd be more interested to see if that's common all the realex integrations.

Mike

[gcamley]

I have enabled debugging

I can see we already have a couple of RealEx successes

The log shows:-

Program = ORDERSCR, Program version = 25252 , HTTP Server = Apache/2.2.22 (Unix) mod_ssl/2, Return code = 999                 , Date and Time = 2012/12/13 16:49, Internal Errors = AUTHORIZERESULT: 1

If you get a failure and the AUTHORIZERESULT is 0 (zero) it should be followed by an error message indicating the problem.

I'm on holiday until Tuesday next week but I will check on this thread from time to time.

[feemish]

Since I enabled debugging I have only had one Realex success. ?!? one at 16.49

and two failed orders which are in psp pending but which are not on the RealControl panel either.
both by the same person at 16.52

but I will check on this thread from time to time.

that would be very much appreciated.

[feemish]

By the way. This bit is bugging me:
Why does it reference /acatalog/ in the url?
Surely all connections to and from realex will be via the cgi-bin so should acatalog be appearing at all?

Hi Mike,

I've looked at lots of orders in my access logs and I can see that the paths in successful orders differ... sometimes saying /acatalog/ and sometimes saying /cgi-bin/

I dont know if thats correct or not. ?

These are some examples and these are all from successful orders that completed correctly.;

88.111.14.36 - - [12/Dec/2012:16:52:31 +0000] GET /cgi-bin/os000001.pl?ACTION=GETPSPFORM&PAYMENTMETHOD=56&timestamp=1355331145559 HTTP/1.1 200 2281 http://www.arka-shop.co.uk/acatalog/ Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)


81.83.130.231 - - [12/Dec/2012:19:01:34 +0000] GET /cgi-bin/os000001.pl?ACTION=GETPSPFORM&PAYMENTMETHOD=56&timestamp=1355338899045 HTTP/1.1 200 2242 http://www.arka-shop.co.uk/acatalog/ Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)


86.26.151.29 - - [12/Dec/2012:19:07:25 +0000] GET /cgi-bin/os000001.pl?ACTION=GETPSPFORM&PAYMENTMETHOD=56&timestamp=1355339251195 HTTP/1.1 200 2259 http://www.arka-shop.co.uk/cgi-bin/os000001.pl Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11


156.77.111.21 - - [12/Dec/2012:19:25:20 +0000] GET /cgi-bin/os000001.pl?ACTION=GETPSPFORM&PAYMENTMETHOD=56&timestamp=1355340322723 HTTP/1.1 200 2279 http://www.arka-shop.co.uk/cgi-bin/os000001.pl Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)

[gcamley]

Since I enabled debugging I have only had one Realex success. ?!? one at 16.49

Order ...28401 looks normal, paid via RealEX
Order ...28402 looks like the buyer submitted the payment request twice causing a second order to be created 28403 which was then paid for using RealEx

You should have payment confirmations for both 28401 and 28403 but not 28402.