404 error returned from Authnet's CIM testing transaction server

[WHeisenberg]

I'm using the test server and test account to build the code for CIM based transactions.

When I attempt to use the Hosted redirect method to allow a customer to input credit card information,  the page is displaying, but all of the CSS stylesheet and javascript page references are coming up 404.

The page is pulling the following (internally, at the authorizenet server end):

https://test.authorize.net/profile/manage/styles/profileCommon.css

https://test.authorize.net/profile/manage/styles/manage.css

https://test.authorize.net/profile/manage/scripts/jquery-1.5.2.min.js

https://test.authorize.net/profile/manage/scripts/profile.js

It appears that all of thoses scripts/pages, in some way, control the display and functions on the Hosted CIM page.

All of them come up with 404 errors.

I tried this particular function with our live account, which is currently in test mode, and I got back a message that told me the transaction couldn't proceed with a live account in test mode.

So, live account in test mode or actual test account.. both fail in one way or another.

How do I test this?

[WHeisenberg]

I've narrowed it down a bit..

The guide for setting up CIM tells me I have the option of either using a popup on my own site, or a redirect to a page on AuthNet to allow the customer to add/modify/delete the payment information stored in the CIM system.

The redirect version is really what I want to use,  if for nothing else than the ability to show https in the url box of the users browser.  It's the main reason we even signed up for the CIM system.   If we had SSL on our own site,  we could do everything the CIM system does, but then we would have to deal with the rediculous nitpicking of PCI... but that's another issue entirely :)

I managed to get the iframe popup working. The button that is supposed to return the user to a page on my site doesn't work correctly - it DOES return them to a page on my site,  but it does it within the iframe itself.  So I had to just make the return page say 'please click the X at the top right of this box'.   Inconvenient, but at least it's workable.

When trying to use the Hosted version,  by sending the customer to the page on AuthNet's site - I can see by viewing the source code for that page that it is pretty much identical to the code that comes up in an iFrame setup. 

The difference between the two is,  when using the iFrame setup all of the CSS sheets referenced in the process are on my own server, are found, and work.

When using the Hosted version,  those same CSS sheets are being referenced, but not from 'my' server.  They are requested from AuthNet's server...  and those pages aren't on AuthNet's server.   Or maybe they are on the server, but not in the location that they are being called from.

The way I see it,  there can only be two options for this to work with the Hosted version of this page.

1.  Authorizenet changes their code to reference the CSS scripts that are on my server (silly idea)

2.  Authorizenet puts the CSS files being requested on their system in the right locations (better idea)

I'm not sure why something as simple as "Hey, you have a file missing on your server that needs to be there" is such a difficult thing to fix or even respond to.

If the file IS there,  the fact that the page isn't working can't have anything to do with the code I have in place, because by the time that file is requested through the Hosted CIM system,  the user is no longer on my site using my code. 

Thankfully I got the iFrame window to work.  Not the greatest option, but at least we can continue with our testing.

WHeis