I have a problem with a shopping cart not working with a payment service provider. The shopping cart is hosted on a 3rd party webserver, the payment service provider on a different HTTPS server. The shopping cart is on a non secure webserver as no confidential data is transferred to the HTTPS payment service providers site.
This is the process
1) HTML shopping cart on an HTTP site sends post with order details(ie amount,order number), and the a return script url (on the cart site) to HTTPS payment service provider.
2) The HTTPS service provider then sends the order details to the Perl script on the cart server.
3) The perl script on the HTTP cart site needs to send the data back to the HTTPS as confirmation of connection.
4) The HTTPS then sends confirmation of payment to the HTTP site's perl script.
5) The HTTP shopping cart records that the goods have been paid for.
The process for me seems to be breaking down from step 3.
Can anyone say what firewall rules and Ports would need to be open to allow this to happen?
As I understand it people have said port 443 would not need to be open on the shopping cart server, but i thought as the initial connection was from the HTTPS site to the script on the shopping cart server, port 443 would need to be open to incoming traffic?
I would love to be able to use a sniffer, on this but unfortunatly, the cart site is hosted on a 3rd party webserver.
I had originally thought it was outbound, but then I thought as the HTTPS site is initiating contact to the script it would have to be inbound?
Just to confuse things further, the inbound contact appears to come from the payment sites firewall, which is a different IP to the address that the cart initially sends data to.
Until you said outbound I was getting convinced it needed to be inbound?
So what makes you believe that the payment site is connecting to your script on HTTPS? Does your site have an SSL cert configured for the server? Have you confirmed with them *how* it will connect back?
The system seems to have been developed jointly somehow between the PSP and the shopping cart company.
The payment service provider have said that as they are an HTTPS site, the communication will be incomming on port 443.
The shopping cart people have said that is wrong.
The payment service provider say, they are right, and the shopping cart people are wrong.
The shopping cart people say they are right and PSP comany wrong
And on it goes.....
My hosting company says they will not open port 443 unless i move to a dedicated server and pay a huge amount extra.
Thats why I'm trying to understand it for myself.
My site doesnt have, or need an SSL certificate, both companies agree on that one!
essentially it works by:
step 1) HTTP Cart server -> order number,amount,cust email -> HTTPS payment server x.x.x.97) step 2) HTTPS payment server takes credit card details and takes money from customers bank step 3) HTTPS payment server(x.x.x.124) -> order number, transaction id ->HTTP Cart server step 4) HTTP Cart server -> order number, transaction id -> HTTPS payment server(x.x.x.124) step 5) HTTPS payment server(x.x.x.124) ->authorised or declined ->HTTP Cart server
The IP address for the PSP change, as according to the PSP, one is their firewall (124) address, the other their IP.
snipped-for-privacy@hotmail.com wrote on 8 Aug 2006 07:35:33 -0700:
What you need to do is confirm that the process you've outlined is the real process. You list it there as coming to your site using HTTP. You've said earlier that it's HTTPS. You need to find out for sure. Looking at your process, the things I can think of for failing at step 3 are:
(a) requires a HTTPS connection to your cart,
(b) the connecting software from the PSP uses HTTP but doesn't pass a Host: HTTP header so the connection never makes it to the cart software on your site
(c) your cart is not responding to the incoming connection because it's misconfigured
The reason your hosting company will charge you more to enable incoming SSL is that an SSL site requires a dedicated IP - SSL handshaking is done before the hostheader is passed and so only the IP address can be used to determine which SSL certificate to serve to the connecting client.
If the above is correct then then are connecting to you on HTTP. If they were connecting on HTTPS then you would require SSL termination and therefore an SSL cert on the server (unless it was being done an SSL card on a firewall or load balancer etc). If your server isn't running a HTTPS site then you don't need TCP 443 open to your server.
As this type of set up would need to be. Before delving in to details, I suspect that your cart server (here on known as CS) and payment server (here on known as PS) are stateless web servers that are behind a load balancer which may or may not include a firewall. Any and all traffic to the PS will likely be HTTPS. Any and all traffic to the CS will likely be HTTP.
*nod* Any communications coming in to the PS will be coming in to port 443 on the PS. However this traffic can be coming from any port on the sending side.
I suspect that the CS support staff is saying that any traffic coming in to your cart on their server will be HTTP. However the CS staff and PS staff are talking about two different sets of traffic.
This is usually the case when confusion over what is being discussed is involved.
Indeed.
This does not surprise me at all. Reference Spack's post for a reason why.
You may or may not need / want an SSL certificate your self. However that is neither hear nor there in this discussion.
I would be willing to bet that the process is more along these lines:
0) Client requests (blank) order form from CS via HTTP.
1) Client submits (complete) order form to CS via HTTP.
2) CS submits order notification to PS via HTTPS. CS redirects the client to the PS.
3) Client requests (blank) payment form from PS via HTTPS.
4) Client submits (complete) payment form to PS via HTTPS. PS submits payment notification to CS via HTTP. PS redirects the client to the CS.
5) Client requests (blank) order status from CS via HTTP. CS requests order status from PS via HTTPS. CS responds to the client to indicate the status of the order.
If either the CS or PS are a load balanced cluster of any sort, you could quite likely connect to one of many IPs at any given time. I suspect that these IPs are servers that are a front end to a back end database that they all share and communicate with each other through.
This process is workable and I have seen it done before. However prone to confusion this is, it will work.
In regards to the original question: - As long as your firewall at the client side will allow you to connect to port 80 and 443 you are fine. - As long as the firewall at your CS side will allow the CS to connect to port 443, you are fine. - As long as the firewall at your PS side will allow the PS to connect to port 80, you are fine.
Beyond that more information is needed to track down where / why this situation is not working.
(1) *is* HTTPS outbound, from the cart to the PSP server.
And it could have the PSP to cart connection back on SSL, even if the original cart to PSP wasn't. If you read the original post fully, you'll see that the initial posting of data sends a URL for the PSP to connect to for passing back the response - it's not passed back over the connection that the cart initiates.
that's all well and good, except the PSP-cart session can not be passed thru to the client browser as the reply to the end-user, as the client does not have the certificate to perform the 3way handshake for the PSP->client data flow.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.