Jump to content


  • Content count

  • Joined

  • Last visited

1 Follower

Profile Information

  1. srarden

    Authorize.net Gateway problem

    Well, then I assume we weren't having the same problem. :) In our case, this was in NO way related to osCommerce - I even asked the authorize.net tech if some misconfiguration of our shopping cart could have caused this, but it seems that you actually have to call and request this kind of change. The unfortunate thing is that there are quite a few specific errors that authorize.net may return, but the output to the store is a standard error message in osCommerce, not the actual error authorize.net returned. The store admin may track those actual errors somehow which I didn't notice, but in my case I didn't get to the point of finding out the cause until I added code to log it. So, in my case, I am going to try and add better code to store those error codes from authorize.net, or email them to me, when they occur -- since in my case the problem seems to be due to a mistake on the authorize.net side can't be sure it won't reoccur. Especially since they didn't seem concerned with tracking down why the setting was changed without our request.
  2. srarden

    Authorize.net Gateway problem

    I added code myself to output this to the error_log on my server -- and it turns out in my case they were giving me a 'The merchant does not accept this type of credit card.'. In finally talking to a tech on their end, somehow the types of credit cards the store would accept set in the profile authorize.net keeps on their end had been set to only 'JCB' (whatever that is). So it was dumping all other credit cards. We did not request the change, and have no idea what happened, but have the suspicion that the problem was caused by some kind of error on their end. We have to have the actual store owner call and request that this be reset. So -- maybe this happened to you as well.
  3. srarden

    Authorize.net Gateway problem

    Has anyone else found this to work? Recently realized that one of our stores was having this problem. Tried this fixOr h, but it didn't seem to do anything -- I added code to change: $timestamp = time (); to $timestamp = time () - 3600; is this incorrect? Where in authorize.net module does this need changed? Or has anyone else tried something and gotten it fixed? Thanks!
  4. I am running OSC 2.2 MS1, using the built-in Authorize.net module. Store has worked wonderfully for a year now. I am creating an order reporting system that my client will use to enter the ordering information into an offline database they use to track all orders, including online (QuickFill if that helps). The system exports a delimited file which they will then import into the offline database. There is some information that they need that the store doesn't track as far as I can tell and I need to see if I can add tracking for it. Two questions: 1) Is there an easy way to add a cc type tracking? There are 4 report fields that I can fill in with dummy information, if I can track the cc type (Visa, MC, etc) -- the dummy information is different per card type. 2) Does authorize.net return a transaction identifier after it processes its part of the order? Is this tracked currently, and if not, what file could be capturing it? I have searched for an answer, and read the guides, but if I missed it, kindly point me in the direction of what contains the answer and tell me to RTFM. :D
  5. Just to update in case someone else does something stupid like I did -- started with one store, working perfectly. Made an exact duplicate of original store. Made minor changes to differentiate the two. Installed gv/dc module. Had problem where order would choke at authorize.net. Uninstalled gv/dc code, same problem. Only difference between the stores? One is behind .htaccess files. When the response comes back from authorize.net it is getting a 401 HTTP code (basically saying the response isn't authorized to access this server). My apologies to Strider for misdiagnosing it as a 404! Looking into a solution now, but at least I know I can put the gv/dc code back in! :)
  6. Coming back it should hit the order success page. I also don't think the problem is with GV/DC. Am going to roll-back the code and see if it is still having the same problem. Running 2 stores on the same server, with minor text and code changes between them, one with GV/DC and one without. The one without is still working, so it isn't the Authorize system. Thanks for your help!
  7. I haven't rolled it back yet to see if removing the code clears up the problem. If you don't enter a coupon or gift voucher, it does the same thing -- gets all the way to confirming order, then can see it hit the secure Authorize.net server, and then a 404.
  8. Just installed this module and after rechecking the code 2-3 times and then figuring out that I didn't actually install the Gift Vouchers and Discount Coupons in the admin -- well, let's just say I felt stupid. So, in an attempt to not have that happen again -- here is my question. gv/dc is working, showing up great, updating the price correctly, etc. But now when the store sends the payment info to Authorize.net, it comes back to a 404. I can't see why this would be affected by gv/dc but that is the only code that has changed. Has anyone else run into this? I am using a CVS snapshot from June 11, 2003 (by now it is heavily modified for the client, time prohibitive to come up to MS2), the included Authorize.Net module, and GV/DC 5.05. Thanks!