Latest News: (loading..)

fiodh

Members
  • Content count

    37
  • Joined

  • Last visited

About fiodh

Profile Information

  1. That answer, I am thrilled to say is "YES" just change that one snippet of code in the module and do everything else right. You should be good. Also, please disregard my previous posts rambling on trying to solve the problem, I would delete them if I could.
  2. Well this finally appears to be working. Gary the famous osCommerce developer helped me out with this. He pointed out the module was only able to accept a 16 character password. First Data generates passwords that are too long - you can abridge it, or you can select your own - if you select your own, make it complex, capitals, numbers, underlines, etc. The longer md5 hash seems to be working fine though. After that, it turns out the php version check was the culprit. Since we are past version 5.3 I removed the entire version-check from the code - replaced it only with the initialization bit -</p> $show_hkey = implode($hkey); $hmackey = "$show_hkey"; // HMAC Key $show_key = implode($idkey); $keyid = "$show_key"; // API Key ID $hashtime = date("c"); $hashstr = "POST\ntext/xml; charset=utf-8\n" . sha1($request) . "\n" . $hashtime . "\n" . parse_url($location,PHP_URL_PATH); $authstr = base64_encode(hash_hmac("sha1",$hashstr,$hmackey,TRUE)); ini_set("user_agent", "PHP-SOAP/" . PHP_VERSION . "\r\nAuthorization: GGE4_API " . $keyid . ":" . $authstr . "\r\nx-gge4-date: " . $hashtime . "\r\nx-gge4-content-sha1: " . sha1($request)); return parent::__doRequest($request, $location, $action, $version, $one_way); } } class gge4_cc_aim extends SoapClientHMAC { var $code, $title, $description, $enabled; // class constructor 5 hours later... Hope this help someone else.
  3. stream_context_set_option(PHP 4 >= 4.3.0, PHP 5, PHP 7) stream_context_set_option — Sets an option for a stream/wrapper/context Description ¶ bool stream_context_set_option ( resource $stream_or_context , string $wrapper , string $option , mixed $value ) bool stream_context_set_option ( resource $stream_or_context , array $options ) Sets an option on the specified context. value is set to option for wrapper Parameters ¶ stream_or_context The stream or context resource to apply the options to. options The options to set for the default context. Note: options must be an associative array of associative arrays in the format $arr['wrapper']['option'] = $value. Refer to context options and parameters for a listing of stream options. Return Values ¶Returns TRUE on success or FALSE on failure.
  4. also I made sure to set the CVS variables in the terminal at first data .. they have a setting on the first terminal info page that shows the password, ID, etc and also an option for expecting the card code verification number... Our old terminal was not using this CVS so it needed to be enabled for the new module instead of the SIM. this is the deal I am thinkin: Warning: stream_context_set_option(): called with wrong number or type of parameters; please RTM in /home/website/public_html/includes/modules/payment/gge4_cc_aim.php on line 43 "wrong number or type of parameters"
  5. turns out that error isn't really different. I switched back to php 5.5 I am thinking that the error is saying that the wrong number of variables are being passed in this array. I am now off to educate myself on arrays and will have a look to see maybe we could cut the variables because the first data is really only looking for the gateway and password, right?
  6. I downgraded the php version from 5.5 to 5.3 and received a different error: Fatal error: Uncaught SoapFault exception: [HTTP] Unauthorized in /home/website/public_html/includes/modules/payment/gge4_cc_aim.php:45 Stack trace: #0 /home/website/public_html/includes/modules/payment/gge4_cc_aim.php(45): SoapClient->__doRequest('<?xml version="...', 'https://api.glo...''http://secure2....' 1, 0) #1 [internal function]: SoapClientHMAC->__doRequest('<?xml version="...', 'https://api.glo...' 'http://secure2....' 1, 0) #2 /home/website/public_html/includes/modules/payment/gge4_cc_aim.php(185): SoapClient->__call('SendAndCommit', Array) #3 /home/website/public_html/includes/modules/payment/gge4_cc_aim.php(185): SoapClientHMAC->SendAndCommit(Array) #4 /home/website/public_html/includes/classes/payment.php(208): gge4_cc_aim->before_process() #5 /home/website/public_html/checkout_process.php(83): payment->before_process() #6 {main} thrown in /home/website/public_html/includes/modules/payment/gge4_cc_aim.php on line 45
  7. I am reading this to say something like: If version of php is not 5.3.1 then initialize SOAP else otherwise LINE 43 - "stream context set option" whatever... obviously I don't know what I am talking about except that the error may lie in the php version.
  8. if (version_compare(PHP_VERSION, '5.3.11') == -1) { ini_set("user_agent", "PHP-SOAP/" . PHP_VERSION . "\r\nAuthorization: GGE4_API " . $keyid . ":" . $authstr . "\r\nx-gge4-date: " . $hashtime . "\r\nx-gge4-content-sha1: " . sha1($request)); } else { stream_context_set_option($context,array("http" => array("header" => "authorization: GGE4_API " . $keyid . ":" . $authstr . "\r\nx-gge4-date: " . $hashtime . "\r\nx-gge4-content-sha1: " . sha1($request)))); } return parent::__doRequest($request, $location, $action, $version, $one_way); } } class gge4_cc_aim extends SoapClientHMAC { var $code, $title, $description, $enabled;
  9. I would prefer to use the AIM process here. Obviously SIM is outdated, we had to use it last time because I had no luck with this. I see that AIM apparently works if certain settings are correct but - what are the variables that are causing this soap error? The aftermarket module FirstData is suggesting only has two variables to enter into the config, the gateway ID and a generated password. This module here at OScommerce also requires the gateway key ID # and a hash code. They are named differently in the firstdata admin. I have installed SOAP so it should be available.... still looking... LostInNormalcy if you see this and have any ideas, don't be shy!!! LOL
  10. Well, a few years later and I am back updating to 2.3. Installed the module and it's giving me the same darn soap errors. Working on it now.
  11. To get it to send back, choose this on the Receipt Page Settings Return Link Method (for receipt page): - Automatic linking to the receipt page including result parameters using HTTP POST method (AUTO-POST) it works!
  12. I got it working finally after using the walkthrough at the link above. I am still working on some error occurring when auto-posting back to the OSC site. It does go back if the user clicks "Return to website" but otherwise not so much. Will post back here if I find the solution.
  13. This was a bust, I couldn't get it to work, even with hiring a more experienced programmer to hack at it. I called first data and they were very friendly, quite knowledgeable but stated they did not support AIM at all, and we should be using SIM. So I am working this right now, making changes to the authorize.net SIM module to point to the first data servers. Then I am working through this link a nice fellow was kind enough to post: http://globalcreations.com/blog/integrating-first-data-e4-sim-with-oscommerce/ I will post back if I get it all working.
  14. I seem to be been getting ahead of myself with that previous post, in fact the module is not working for me and I am getting the same soap error. Working on it right now.
  15. The module installed perfectly for me on an old 2.2 site - I copied the files into the includes/modules/payments/ and includes/languages/english/modules/payments, everything showed up in the admin payment module area OK. I then added the config info from the merchant account as the docs suggest. When testing, I got an error at first about about the account not being activated but after logging into "https://globalgatewaye4.firstdata.com" and changing the "terminal" settings, to enable this terminal as an "ecommerce" terminal, it worked fine. I did also see no payment type name so I edited the file as jhaugen stated above. (cheers for that) First Data actually wants users to go to their subcontractor and purchase a different module for $57, so this was a savings and works better because it is seamless and doesn't take the customer from the site. Many thanks to Lost_In_Normalcy!