I have a freelance client that wants me to integrate a payment gateway into their Woocommerce site but I am being increasingly concerned about their choice of provider and the project as a whole.
The Issues
Against my advice the client has selected the gateway provider. The provider is a far eastern one that I have never heard of before called Payforasia. The first warning flag is the fact the english and chinese (I think it is Chinese) version of their website doesn't appear to load images correctly.
I was provided documentation for the gateway API as a PDF and a simple PHP demo. They also gave me a login to the merchant front-end so I could monitor my test transactions. All fairly normal.
I ran the demo on my localhost and managed to connect to the payment gateway but got a failure error response. The error was not listed in the documentation, in fact the possible errors list goes from 0001 to 0067. I was getting error 0068. The second warning flag. When I contacted the provider, through my client, to ask for up-to-date docs and for advice on the error. I was told that the docs are the latest and that the office was closed for over week due to a national holiday (!?!?!). They finally got back to me today and said the error was "probably" due to them not whitelisting the server IP and that they had resolved that now. I still get the same error.
While I wait for them to come back to me on that I started digging into the demo code and rereading their documentation to see if I had missed something obvious. I noticed this line in their docs:

csid String 100 Yes Capture the value through
http://cm.js.dl.saferconnectdirect.com/csid.js

Since the original testing, and while waiting for them to come off their week long national holiday, I had applied an SSL to my client's site and obviously the browser wouldn't load the insecure connection to the javascript. The URL to this is in the demo but right at the bottom after a huge number of returns between it and demo form markup. Another flag waves at me.
Turns out after trying the protocol agnostic url and HTTPS that the csid.js is not available over a secure connection. So I copy the JS to the server and amended the link in the markup. This is where the flag waving really starts going mental.
The script populates the CSID field with my user-agent string, my screen resolution, origin server and hashed data. It also, more worryingly, adds an iframe that appears to be a tracking image or something similar. The iframe fires off six strange connections using a wss:// protocol to localhost.

I will admit at this point I panicked and came here to ask for advice. The JS is minified and appears to have a PHP eval() in it and what looks like encoded characters. I don't know how to decode this and I'm unsure if it is safe to continue digging further into the code.
My Questions
I need some advice.

Am I being overly paranoid or do I have a genuine concern?
Is it normal for a gateway provider to obfuscate their code like this?
Should I advise my client to immediately change supplier?
Should I walk away and chalk it up to experience?

Any advice, suggestions or comments on this will be hugely appreciated. Sorry if my question is rambling and a bit long, I wanted to get as much background in as possible.
Update
After all the excellent advice, I just wanted to give you all a quick update.
I brought up a lot of my concerns with my client, who did not react in the way I expect. I was accused of deliberately dragging my feet, inventing problems, being incompetent and received less professional questions as to my parentage. Relations between me and my client have definitely frosted.
They insisted that I implement the gateway without SSL on the site AT ALL. When I refused and invited them to find another developer they backed down almost straight away and became a little more cordial, although I have not yet received an apology.
Since then they have revealed that the gateway provider had whitelisted the wrong IP which was why I was still receiving the mysterious 0068 error. The gateway provider tried to pin that one on me until I provided Skype logs to the contrary. My client won't let me speak to the gateway provider directly, so the the IP address was garbled at some point between them.
With regards to the insecure JavaScript, my client has suddenly provided me, late yesterday, with this URL https://online-safest.com/pub/csid.js. They haven't provided any further documentation or where they have got this script from. I have not tested this script yet.
I'm not sure I want to continue with it so I've been dragging my feet. I need to have a think about it today. I will accept an answer tomorrow, unfortunately I can't accept multiple answers even though I have used the content of several.
Update 2
Just a final update. I completed this project for my client but I fear my relationship with them is now irrecoverably damaged. They insisted that I put the gateway live without any testing beyond the fact a single test transaction went through. I've told them that any post-live issues they have they will need to find another developer as they have gone live without testing and forfeited my normal support period.
You could argue that it is unethical for me to release code into the wild that could be buggy and dangerous for end-users, however I saw no other way to easily exit the contract. I have given them full access to the private GIT repo containing the source which contains all the documented interaction between me and the client. Any future developer should be able to view it and make a decision from there.
I further discovered that they have actually sub-contracted the job to me. All in all it is a project I am glad to be rid of.


  
  Am I being overly paranoid or do I have a genuine concern?
  


You have a genuine concern.  Something is not right here.


  
  Is it normal for a gateway provider to obfuscate their code like this?
  


Obfuscation is not, all by itself, abnormal.  However, at the point they're trying to open localhost connections to RDP, VNC, and other ports, that's not obfuscation, that's completely inappropriate and malicious.


  
  Should I advise my client to immediately change supplier?
  


I would advise your client that the code provided for integration appears to be malicious and that you cannot assume the supplier is either a) legitimate or b) capable of securing their business (and by extension, your client's).  In addition, the supplier does not appear to integrate properly into a secure purchasing environment (the http: only js link), which calls into question their appropriateness even if legitimate.

As per @JaimeCastells's comment to the question, there is no "payforasia" service provider listed at http://www.visa.com/splisting/searchGrsp.do.  That could mean they're doing business under that name but are certified under a different name, or it could mean they're a "Level 2 Service Provider".  Neither of those options is reassuring, quite frankly.


  
  Should I walk away and chalk it up to experience?
  


If the client wants to continue with this supplier, I would definitely consider walking away.  You can't make the client do the right thing, but you can choose not to be the one doing the wrong thing for them.

Javascript analysis

The intent of the obfuscated Javascript seems important.  I've tried to untangle what's happening in the Javascript, and I'll link to readable partially de-obfuscated copies in this section.

Overall, my impression is that the level of obfuscation used in these scripts exceeds what is commercially reasonable and becomes suspicious as a result.  The limited amount of inferences I can draw about what it does are not inline with normal payments processing.  Lacking better information, I presume this is malicious javascript.

Here are files I'm looking at should you wish to explore the same question.  These files have been run through the Online Javascript Beautifier  and I've also used the Online Javascript Editor to pick apart bits of what the  scripts do.  You can see that even with the basic de-obfuscation applied, there's still a lot of obfuscation in place - check.js is full of arrays of integers which get processed by the code, and which are presumably more text or code to be executed.

There are at least four scripts involved:


csid.js
tags.js
check.js
checkcid.js


It's clear, for example, that the five ports the OP saw getting connection attempts are hardwired into check.js:

td_0a = ['REF:63333', 'VNC:5900', 'VNC:5901', 'VNC:5902', 'VNC:5903', 'RDP:3389'];


I will continue to poke at them, and may pastebin some copies, but I think it's reasonable to be distrustful of this code at this point.
