Jump to content


  • Posts

  • Joined

  • Last visited

SecondCity's Achievements

Regular Member

Regular Member (3/5)



  1. I have been so busy defending myself against Jacques1 in another thread, I forgot all about this one! Am working on another problem now, but when I finish that I will try this out and get back to you. Thanks for the reminder!
  2. Is this why you hang around forums? To put people down and criticize? The places where I was getting hung up weren't that hard to understand if you read what I originally said. And I was thankfully able to figure things out. Ranting about how inferior my skills are doesn't add much to this website, and make me wonder why you feel the need to point out perceived shortcomings in others. Must be lonely being a forum guru...
  3. I do write secure code. I just don't know cURL, XML, or OOP - which this project requires. I did break down my code and look at things with a fresh head. The manual looks like most manuals written by developers - it is incoherent. (I even got an admin at the payment gateway to agree with me on that one!) Because the developers chose to write piss-poor documentation, and because the nuances of all of this is subtle, that matters I figured out the missing pieces that were not documented, AND I rewrote the code provided to me in several places to make it easier to understand and thus better. I know understand how this whole process works. Had the people doing the documentation done their jobs - read speak clean, clear English - I could have done all of this in a few hours. But through the struggle I guess I am better off in understanding. Of course I still have the cross to bear that @Jacques1 thinks I am an idiot!!
  4. I have it working. Looks like you are wrong again.
  5. Nothing. Will probably have a working website that accepts credit cards by end of the weekend. Just trying to better understand things so I don't make any mistakes and leave any holes in my code. You seem to flustered to help, and this thread has become too morphed. Clearly we aren't understanding each other. Sorry I asked.
  6. I guess the object created here... $xml = simplexml_load_string($xmlStr,'SimpleXMLElement', LIBXML_NOWARNING); Has no relation to this object... $response = new SimpleXMLElement($xml_response); ----------------- And I guess the XML string I send in the request have no relationship to the XML string that the payment gateway passes back to me. ----------------- If any of this was in the manual, I wouldn't be here bugging you!
  7. This thread has morphed... I understand what you said above. My latest posts were dealing with the objects created. Objects are not strings. public 'payment' => object(SimpleXMLElement)[4] public 'creditCard' => object(SimpleXMLElement)[6] public 'cardNumber' => string '5424000000000015' (length=16) public 'expirationDate' => string '0917' (length=4) public 'cardCode' => string '888' (length=3)
  8. I think the fact that 5 of my posts today got got truncated and you didn't see everything I said messed up a nice conversation. My confusion is around the quasi-object called SimpleXMLElement which the PHP manual says is not technically an object and you have to handle differently. I was concerned that there might be a collision using the same object for the request and response. I know PHP and procedural coding, but what has thrown me off in all of this is that the code I got is more OOP based' (I edited the post above.)
  9. Is there any relationship or conflict in my code between this SimpleXMLElement object which is used for the REQUEST... $xml = simplexml_load_string($xmlStr,'SimpleXMLElement', LIBXML_NOWARNING); ...and this SimpleXMLElement object which is used for the payment gateway RESPONSE... $response = new SimpleXMLElement($xml_response); I would have thought you would do this for $response... $response = simplexml_load_string($xml_response,'SimpleXMLElement', LIBXML_NOWARNING);
  10. I thought when I ran this code... $response = new SimpleXMLElement($xml_response); ...that it might use the same SimpleXMLElement object that I build above for the request? Or is $xml_response and entirely different XML document from the payment gateway? And so that would make $response a PHP object that is unrelated to my request SimpleXMLElement??
  11. If I have this... $xmlStr = <<<XML <?xml version="1.0" encoding="utf-8"?> <createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication></merchantAuthentication> <transactionRequest> <transactionType>authCaptureTransaction</transactionType> <payment> <creditCard> <cardNumber>$ccNumber</cardNumber> <expirationDate>$ccExpDate</expirationDate> <cardCode>$ccSecurityCode</cardCode> </creditCard> </payment> </transactionRequest> </createTransactionRequest> XML; $xml = simplexml_load_string($xmlStr,'SimpleXMLElement', LIBXML_NOWARNING); Then my XML string would have things like $amount, $CC_number, etc, right? When I run this, do I have to worry about $response containing any of the values above?? $xml_response = curl_exec($ch); I guess what I am still struggling with - because it is NOT in RTFM - is what happens to my original XML template when I get a response back from the payment gateway?
  12. My concern is that the variables embedded in my XML template might get returned in the payment gateway's response to me when I use this code... $xml = simplexml_load_string($xmlStr,'SimpleXMLElement', LIBXML_NOWARNING); $xml_response = curl_exec($ch); $response = new SimpleXMLElement($xml_response);
  13. Every time I try and post responses here they get CHOPPED OFF
  14. I was concerned that all of those request values might somehow end up hanging around in the XML template that I get back from the payment gateway. So when I run this... $response = new SimpleXMLElement($xml_response);
  15. I don't know or understand OOP. If I take an XML template that has variables in it - and thus values in it - and I run it through... $xml_response = curl_exec($ch);
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.