Announcement

**caite** · 04-Aug-2006, 11:09 AM

Hi all, getting back to the actual problem in hand ...

My latest is that my host company (34sp) have confirmed they don't have any kind of firewall on the server, which was what nochex had first suggested might be a problem. They have given me an exact URL which they were posting to (15 times before giving up) without getting confirmation back.

34sp told me to look in my logs - so I have, and the url is there in my log. So now waiting to see what the next thing to check is. Presumably something going on with Actinic/My server means the response isn't being sent - but why???

I've bought an awful lot of rubber needle grippers from myself in testing this function!

**TraceyHand** · 04-Aug-2006, 11:44 AM

Originally posted by cbarling

I personally wasn't aware that Nochex enabled people to take credit cards in the way that you are doing, so I suspect that this has been introduced since the original integration. When we issue new releases (major and maintenence) we do test the payment service interfaces, but of course we don't test new capability which we don't even know about. This needs to be bottomed out to see if the problem is that this particular usage has never been programmed in.

Chris
CEO, Actinic

It is a relatively new thing. Certainly introduced since the original Nochex integration with Actinic.
I think the Nochex version of amerchant account is a good thing as it does enable buyers to pay with their debit/credit cards without signing up, much like the Paypal merchant account does (except the Paypal merchant account is only available in the US)

**petesouthwest** · 04-Aug-2006, 11:55 AM

Originally posted by caite

Hi all, getting back to the actual problem in hand ...

My latest is that my host company (34sp) have confirmed they don't have any kind of firewall on the server, which was what nochex had first suggested might be a problem. They have given me an exact URL which they were posting to (15 times before giving up) without getting confirmation back.

34sp told me to look in my logs - so I have, and the url is there in my log. So now waiting to see what the next thing to check is. Presumably something going on with Actinic/My server means the response isn't being sent - but why???

I've bought an awful lot of rubber needle grippers from myself in testing this function!

It would worry me that your host has said they dont have a firewall? I have both a hardware and software firewall on my home network, so I'm surprised they say they dont have one at all?

It sounds like you may be having the same problem as me. Looked briefly at their site but cant see the info I would be interetsed in.

Try the emailing them the following:

Can you please tell me whether my package is hosted on a windows or linux server? Could you tell me whether the crypt::SSLeay or equivalent module is installed and whether port 443 is open?

I did notice http://www.34sp.com/hostingfeatures.php
says they offer SSL supoort at �10/year.

if they asnwer no to the above question, try asking them if they would try enabling SSL support for you so that you may test whether it solves your problem.

We are in the process of swapping to Techno-web as they seemed to know what I was talking about and have been replying almost instantly to all my emails. Even the one I sent at 11.45 last night!

Pete

**petesouthwest** · 04-Aug-2006, 12:09 PM

Originally posted by cbarling

Hi Pete and Caite,

Thought that it was worth commenting here. I would like to talk generally, not to provide excuses but to explain the problems that we face.

This is the sort of issue that is a complete nightmare for us, as it us for you. Let me explain why. For these types of issue, there are always at least six possible causes - our software has a bug, the payment service software has a bug, the web server has some unusual configuration, the user has mis-configured things, or the payment service provider has changed things / introduced new capabilities and we didn't know about it. Even standard software can be changed and cause problems (e.g. new releases of Apache, IIS, Norton, Internet Explorer etc).

Issues similar to this arise all of the time, and most of the time the explanation is to do with the web host or user configuration (I'm not saying that this is the case here). They are usually sorted out fairly quickly. Occasionally, they are never sorted. From our side, that's when we have reached the point where we have done everything that we can. There are lot's of things that are out of our control so we can't guarantee 100% resolution.

Looking at this particular case, the Nochex integration was done by Nochex and tested by us before being included in the software. I personally wasn't aware that Nochex enabled people to take credit cards in the way that you are doing, so I suspect that this has been introduced since the original integration. When we issue new releases (major and maintenence) we do test the payment service interfaces, but of course we don't test new capability which we don't even know about. This needs to be bottomed out to see if the problem is that this particular usage has never been programmed in.

Please don't assume that no-one cares, either in Actinic or on the community, or indeed at Nochex. You've been unlucky enough to hit one of the more difficult problems. An issue with Paypal took absolutely ages to solve and from my memory turned out to be because Paypal very occasionally sent its responses back in a different order than that it usually did. It always sent them in one particular order when we tested it, so we could never reproduce the problem.

By the way, the reason why you had to provide us with a telephone number for Nochex (thanks for that) was because when we tried the number that we had, it no longer worked, and no number seemed to be available on their site.

Tamas Viola is now looking into this. He's the best person we have in Actinic for these types of issues.

Chris
CEO, Actinic

Many thanks Chris I appreciate your honest answer. As you can imagine I do fully appreciate the problems your technical people are experiencing. I think the problem here is not that Actinic have not solved the problem, but rather that there has been a lack of answers to our questions and information regarding progress. I�m sure if you were losing sales, you would not be happy to be simply told �someone is looking into it�, once a day. The fact that I have been asking questions that are not answered, I believe would leave most customers frustrated.

From most customers� viewpoint I would have thought they would have appreciated an email on a more regular basis. Having worked in the software business for many years, I for one can understand why some of my questions may be difficult answer; Staff leave, some do not document their code as well as they should, contract staff are brought in for short term contracts etc. Its better for people to reply saying they are not sure of the exact answer at the moment but they are trying to work it out than to say nothing at all. At least then the customer knows they are talking to a real person and not getting an automated reply.

For example I have still not heard whether Actinic have actually tested the Business package on a server that does not support SSL, ie like the published requirements state, even though I have asked several times. The only reason that I can guess for this lack of reply, is that nobody knows.

Can I suggest that as Actinic Business is so dependent on payment service providers that a direct line of communication is set up between yourselves and each PSP. This would benefit both companies as it would seem that your existence is symbiotic. As Actinic�s reputation is also at stake, could you not make it a condition in the contract with them? Initiate a policy that would mean that any changes to the PSP functionality is reported directly to Actinic. Within Actinic, setup a testing policy to ensure that each product is tested on a webserver that matches the specification you have on the website. When a PSP informs you of a change, re-test on the appropriate server to ensure compatibility.

Pete

**Bruce** · 04-Aug-2006, 12:11 PM

Pete,

I hope this post answers some of your questions.

Taking the data from your PSP bounce page...

This is the address to begin the CC detail entry.

This is the Authorisation call back URL

This is the Transaction Completed URL

Both of the above URLs are non-SSL and these are what Nochex use to respond to your server. If the response received by your server is using SSL then Nochex have modified the URLs. You should ask Nochex why the URLs are being modified as this is not how they usually respond to Nochex enabled Actinic sites.

What we are sending Nochex is correct and will work with a normal Nochex account. We need to know from Nochex why they are sending an HTTPS request to your server. If this is the behaviour of the Merchant Account callback then this is a new protocol and one we are not aware of. We are looking for information on this to be able to help you, if you can get this information from Nochex and share it with us here it would be helpful.

Kind regards,

**caite** · 04-Aug-2006, 12:12 PM

I had no idea I was doing anything unusual. I just looked at it and thought it was basically the same as paypal, but run by a British company and minus all the horror stories!

But if this is new - all the more reason for us to track down solutions because there are likely to be more and more people starting to use Nochex in this way.

**caite** · 04-Aug-2006, 12:26 PM

Bruce - firstly apologies if I don't make sense - I'm working way outside my comfort zone of technical knowledge here.

This is the URL Nochex have been asking me to check is being sent to my site

http://www.tuppys.co.uk/cgi-bin/os00...httpdocs%2faca
talog%2f&SEQUENCE=3&ACTION=AUTHORIZE_52&CARTID=62Z252Z64Z19A1154430073B2
8686&ON=CP61RH10000011&TM=0&TO_EMAIL=confirmation@tuppys.co.uk&ACT_POSTP
ROCESS=1&

It's appearing in my logs, but nochex are getting no response. And have now asked me to check whether my site "has the ability to perform an outbound https post"

Is that what you'd expect?

(this is the using the standard nochex seller account rather than the merchant like pete)

**petesouthwest** · 04-Aug-2006, 12:44 PM

Originally posted by Bruce

Pete,

I hope this post answers some of your questions.

Taking the data from your PSP bounce page...

This is the address to begin the CC detail entry.

This is the Authorisation call back URL

This is the Transaction Completed URL

Both of the above URLs are non-SSL and these are what Nochex use to respond to your server. If the response received by your server is using SSL then Nochex have modified the URLs. You should ask Nochex why the URLs are being modified as this is not how they usually respond to Nochex enabled Actinic sites.

What we are sending Nochex is correct and will work with a normal Nochex account. We need to know from Nochex why they are sending an HTTPS request to your server. If this is the behaviour of the Merchant Account callback then this is a new protocol and one we are not aware of. We are looking for information on this to be able to help you, if you can get this information from Nochex and share it with us here it would be helpful.

Kind regards,

Hi Bruce

I appreciate your reply, what you have described is also as I understand the functionality regarding the shopping cart post action to nochex, and I agree this does not involve SSL, but that is not AIUI where the problem lies. The problem lies with the APC functionality. Tomas has described that very well and cleared up some of the areas I did not understand. Look at what he says:

When the payment is accepted by Nochex server, then it sends the authorisation callback to the OrderScript.pl which is called osxxxxxx.pl where xxxxx is your script ID. OrderScript checks if AC_POSTPROCESS parameter exists. As it exists in case of Nochex, it passes the control to perl routine in PostOCCNOCHEX.fil located in acatalog dir.
This program will handle the call, by calling back Nochex server via HTTPS connection, sending back all parameters arrived. Then it waits for AUTHORISED or DECLINED message from Nochex server. If the answer is AUTHORISED, then it calls RecordAuthorisation routine of OrderScript.pl which creates the NNNNNNN.occ file, where NNNNNNN is the order number. The NNNNNNNN.ord file is the order details file, created when the checkout process was initiated. If both files are exist when you download the orders and contain proper data, then EC will state the order as 'Full Payment'.
If any error happens during the RecordAuthorisation routine, then an error message is generated and stored in the error.err file.

Lets just clarify, at this stage we are not talking about the events you have described, ie posting the initial data to Nochex and Nochex returning the browser to the return URL, but the events that happen between them.

If you look you will see that Tomas mentions:

This program will handle the call, by calling back Nochex server via HTTPS connection, sending back all parameters arrived.

This is what I believe is the part that requires SSL support. If you look at my posting here: http://community.actinic.com/showthr...t=22625&page=2
I have explained it in more detail. When you ask me, to ask Nochex for more details, I do not believe that is necessary, as I have already dug through the scripts and provided the flow of procedure calls that show where the problem lies in that thread.

Regarding Nochex, they have already explained to me that in their opinion SSL support is required. We are now acting on that basis and swapping our host to one that can offer SSL support. But I wonder why you seem so sure SSL support isn�t needed, and as I might be wrong, I would like to get to the bottom of the problem.

Although I�m happy to help in anyway I can, I would have thought it would be better for you to contact Nochex yourselves rather than going through me?

Pete

**Bruce** · 04-Aug-2006, 01:23 PM

Pete,

We are in touch with Nochex on this, just thought that if both you and our dev people approach them then we will get a quicker response. I will keep you posted.

Kind regards,

**Bruce** · 04-Aug-2006, 01:27 PM

Pete,

There is no need of open port 443 for the merchant's server, as the request sent by PostOCCNOCHEX.fil is a client request to Nochex server, so there is a need for an open 443 port only on the Nochex server.

The connection will be established in this way...

Merchant's server port X <-> Nochex server port 443

Where X is a random number above 1024. For connecting from a script to a server, the server must have a static port number, so the script will know where to connect to. The server will retrieve the client's port number from the TCP frame of the request.

Hope this clarifies the procedure.

Kind regards,

**caite** · 04-Aug-2006, 02:10 PM

Right, the latest word from 34sp is very simple.

"It looks like you just need to call
https://nochex where you are calling http://nochex at this time"

Is there somewhere I can go in and add that pesky little s to test this hypothosis?

**wjcampbe** · 04-Aug-2006, 02:27 PM

Caite - to be able to apply the correct fix, when it is found, its best you don't change anything at all in the maentime. The biggest danger facing Pete at the moment is that when the fix is published, he has to somehow get back to a standard installation as that will be the starting point from which the required changes will be documented.

Please, for your own sanity, and for ease of application of the eventual fix, just leave well alone for now.

**petesouthwest** · 04-Aug-2006, 03:03 PM

Originally posted by Bruce

Pete,

There is no need of open port 443 for the merchant's server, as the request sent by PostOCCNOCHEX.fil is a client request to Nochex server, so there is a need for an open 443 port only on the Nochex server.

The connection will be established in this way...

Merchant's server port X <-> Nochex server port 443

Where X is a random number above 1024. For connecting from a script to a server, the server must have a static port number, so the script will know where to connect to. The server will retrieve the client's port number from the TCP frame of the request.

Hope this clarifies the procedure.

Kind regards,

Hi Bruce

I appreciate the speedy answer and have emailed it to Nochex.

Can you help me further to understand?

Am I correct in understanding that the function/object/procedure or what ever a Perl programmer calls it, in script PostOCCNOCHEX.fil is:

Code:

($status, $sError, $sHttpStatus, $sResponse) = ACTINIC::HTTPS_SendAndReceive('www.nochex.com', 443, 
			'/nochex.dll/apc/apc', $sPostedData, 'POST', $::TRUE, $ssl_socket);

This appears to be using with SSL protocols?

Assuming that to be the case, it appears to be declared in alxxxxx.pm (where xxxxx is your script ID so can be different for each user)
and has paramamters:

Code:

my ($sServer, $sPort, $sPath, $sContent, $sMethod, $bCloseConnection, $ssl_socket) = @_;

therfore:
$sServer ='www.nochex.com'
$sPort=443
$sPath:=/nochex.dll/apc/apc
$sContent=$sPostedData
$sMethod='POST'
$bCloseConnection= TRUE
$ssl_socket=$ssl_socket

So when it is called from PostOCCNOCHEX.fil it is being told to POST on port 443?

Does that not mean that my server should have port 443 open for outgoing traffic?

Assuming that have not made any mistakes so far lets look at HTTPS_SendAndReceive:

Code:

#
# Second attempt: ActinicSSL connection
if ($@)									# Error occured - the SSL library is probably not available
			{
			require sc000001;
			($nResult, $sMessage, $ssl_socket) = new ActinicSSL($sServer, $sPort);
			}
		}

Notice

# Error occured - the SSL library is probably not available

I'm assuming that this comment is correct and that any calls to this procedure from scripts on servers where the SSL library is not present would go this route?

This results in the call:

Code:

new ActinicSSL($sServer, $sPort);

Assuming that to be the case, it appears to be declared in scxxxxx.pm (where xxxxx is your script ID so can be different for each user)

This would appear to be the 'end of the line' for the procedure calls. Therefore if a random port is being used to post data I would assume it happens here? Can you please explain where?

Am I correct in understanding it would be here:

Code:

my $Proto = shift;
	my $Class = ref($Proto) || $Proto;
	my $sServer = shift;
	my $sPort = shift;

So am i correct in thinking the scripts try to post out on port 443 and when it fails it starts hunting for a port that works?

To me this all points to the need for a port, other than 80, to be open to allow this connection.

However, this is all using SSL, from what you have said there should be an HTTP equivalent?

Can you please explain where I have gone wrong?

Pete

**petesouthwest** · 04-Aug-2006, 03:11 PM

Originally posted by caite

Right, the latest word from 34sp is very simple.

"It looks like you just need to call
https://nochex where you are calling http://nochex at this time"

Is there somewhere I can go in and add that pesky little s to test this hypothosis?

Caite have you modified anything other than to configure Nochex using the Actinc software?

As I understand it the standard setup posts to HTTPS.

In my humble opinion I think your server has got the it the wrong way around. The work around suggested to me (that we tried and couldnt get working, but that may be to do with our hosts firewall settings) was to change the Actinic so that the initial post is to HTTP not HTTPS.

I can tell you how if you want me to.

Pete

**Bruce** · 04-Aug-2006, 03:26 PM

Pete,

I think you are over complicating this. There is no need of SSL support on the merchant's server, Actinic perl module will provide the SSL support. This is done by calling on scxxxxxx.pm in PostOCCNOCHEX.fil, as you have posted above. This script provides the SSL module. You do not need SSL port 443 turned on.

Kind regards,

Announcement

Integrating Nochex

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment