XML is too difficult


  • Trolleybus Mechanic

    Oh for the love of Vishna fisting Buddah, this just gets better.

    Allow me to present this perfectly reasonable line from their very own documentation, under the section of "Values to post to us during a transaction"

    @TFM said:

    [b]rtype[/b] -  Sets the format for the response. Possible values: [i]nvp – name value pair (default), xml – XML format, json – json format  [/i]

    Cool. I already have an XML parser ready from the other payment processors the system uses. I'll select that. I send out rtype=xml, and get back... name/value pairs. Not what I was expecting, given, y'know-- the documentation.

    So I email support. Simple query, paraphrased: "I'm sending rtype=xml, as per page xx on your document. I'm getting back nvp. What key and/or value should I be sending?"

    The response I get. [i](Note: return_url is the verification/reciept page on my system where users land after making a payment)[/i]

    @Holy shit are you fucking seriously serious? said:

     Hello Lorne,

    We’ve received this inquiry before and our investigation returned the same result.  Additional research is being done by Development on JSON. However you can get a complete xml return response to your return_url on successful transactions by adding following code under return_url which will create a new file named op.txt and save the received data in it.

    <?php
    $raw = file_get_contents('php://input');
    $file = "op.txt";
    $fp = fopen($file, 'w');
    fwrite($fp, $raw);
    fclose($fp);
    ?>


    Let me know if I miss anything, but:

    1) Grammar, motherfucker. Do you speak it?
    2) I'm not using PHP. I'm not surprised they do.
    3) This is a known problem, yet it's still in their documentation that was last revised May 2012.
    4) The known problem is how to send XML! Once again, let's check the calendar. Yup, it's still 2013.
    5) Rather than fixing the problem, they're working on sending JSON instead (which doesn't work other, BTW)
    6) php://input is "a read-only stream that allows you to read raw data from the request body". Even if I translated that to .Net, why the goatfuck would I ever want to directly touch the raw stream? And that's ignoring the fact that I looked at the raw stream, and there's no XML there.
    7) Save the raw stream to a raw text file. What's a database?

    Let's say, just for a second, I copypasta'd their code as is. I would end up with a text file, on a public-facing webserver, containing customer data-- that could very well be overwritten with other customer data in the interval between saving it, and applying the payment.

    For the record, every other payment provider I've ever dealt with either posts the XML back as the body of the response, or includes a POST variable along the lines of rxml=<response...>


  • Why are you still implementing this?



  • I must admit - I have some sympathy with Blakeyrat's question there...

    I would prepare a short summary on the multitude of reason why they shouldn't be using this payment processor, and then kick it towards management with enough force that it reaches someone intelligent enough to query whether you really should be in bed with these guys.


  • Trolleybus Mechanic

    @DumbByAssociation said:

    I must admit - I have some sympathy with Blakeyrat's question there...

     So do I. At the moment, it's because the client picked this payment provider. The project's been in limbo for several months while we waited for them to get their act together-- order a ecommerce account, get access to the docs, set up the test accounts. I'm only touching code over the last couple days.


    I would prepare a short summary on the multitude of reason why they shouldn't be using this payment processor, and then kick it towards management with enough force that it reaches someone intelligent enough to query whether you really should be in bed with these guys.

     

    I've been keeping my boss in the loop as to these details (with slightly less swearing). I replied to the support email with a mildly less caustic version of this post-- along the lines of "Not acceptable. Here's why. Also, you didn't answer my question. Why is it documented but not supported? If you can't figure it out, let me know. Did you try .Serialize()?!?".

    If I don't get an acceptable response, I'll make the recommendation to my boss to make to the client.  Chances are I'll be stuck with this, but at least it'll be on record I'm opposed to it. I think the client either does their offline payments/credit card processing with this provider-- or Global Payments has one hell of a shiny pamphlet.

     

     



  •  Ahh Global Payments. We used to have them to handle the card terminal. Only bothered contacting us once we decided to switch to another provider, and not in a pleasant manner.



  • @Lorne Kates said:

    php://input

    That is a stream that lets you read the data sent in the HTTP request. I'll assume you know how HTTP works. This is the stuff that comes after the headers in the request.
    @Lorne Kates said:
    return_url

    This is an async callback URL they want you to provide.

    Summary: TRWTF is async confirmation of shit that happens during a HTTP request.

    And Lorne not understanding English.


  • Trolleybus Mechanic

    @Ben L. said:

    @Lorne Kates said:
    php://input
    That is a stream that lets you read the data sent in the HTTP request. I'll assume you know how HTTP works. This is the stuff that comes after the headers in the request.
     

    Yes. All that stuff is a single string consisting of name/value pairs deliminted by & and =. In other words, rather than the HTTP request containing XML, it contains name value pairs. Like I said. You do know how reading works, right?

    @Ben L. said:

    @Lorne Kates said:
    return_url
    This is an async callback URL they want you to provide.

     It's cute that you can guess like that. Keep it up and you might get a few.

    return_url is a variable I pass to them during the initial post to their hosted pay page. It is the URL that the customer is redirected to after they complete their transaction on the hosted pay page.  They get a 301 to return_url with the result of their transaction in the query string.

    I take the results, and make a server-side call to their verification page to confirm the end user input is correct. I POST to their page. In a REQUEST. A normal, everyday synchronouse request. The RESPONSE  from Global Pay contains verification data-- how much was actually paid, etc. That comes in a RESPONSE. The RESPONSE should contain all that data in XML, like I request. Instead it comes back as a string of name/value pairs. In the response. The synchronous response. That should contain XML. (In the response)

     @Ben L. said:

    Summary: TRWTF is async confirmation of shit that happens during a HTTP request.

    Ain't no async going on anywhere. Do you need me to invoke Blakey's shoulder aliens? 


    And Lorne not understanding English.



    Je t'aime la grande pamplemousse.

     

     



  • @TFM said:

    rtype -  Sets the format for the response. Possible values: nvp – name value pair (default), xml – XML format, json – json format 

     

      @Lorne Kates said:

    The response I get. (Note: return_url is the verification/reciept page on my system where users land after making a payment)

    @Holy shit are you fucking seriously serious? said:

     Hello Lorne,

    Glad I'm not the only one that experiences this huge reality gap between what was asked and what was returned.

    With an email like that, is there any wonder why your "rtype=xml" request is being met with a similarly ignored response?

     



  • Sure, their API's broken (or whatever you call such an HTTP-based protocol). But if the data can fit into the NVP format, why bother with XML? XML for the sake of XML is a management anti-pattern. I've come to expect development anti-patterns here, but I thought we were mostly solid on XML overkill and why it's a bad thing.


    Similarly... their little PHP snippet is an irrelevant abomination. But the notion of putting that crap in a database instead seems like overkill. It sound like you're just hoping for your favorite technologies even if they're overkill. That's not necessarily a WTF, but I do sort of understand your payment processor's mentality.


  • Trolleybus Mechanic

    @bridget99 said:

    But if the data can fit into the NVP format, why bother with XML?
     

    1) Because I already have an XML parser for every other payment processor in the system, and I know it works

    2) Because they have in their documentation that they can send XML

    3) Because I might need to send the XML downstream. (I personally don't, but I might need to)

    4) Because I don't know how the hell they'll escape "&" and "=" in their NVP implementation, so it's now more work for me to QA their format

    5) And speaking of which, I also need to figure out how they escape everything else. It looks like some quasi combination of URL encoding and something else. So not only do I have to implement a NVP parser, I also have to make sure to implement a decoder on the values.

    6) Because if this is just an honest hiccup in their DOCUMENTED system, I can buy that. "Sorry, XML parser was down during an upgrade, it's back up now as expected". If it isn't, then I lose all trust in their ability to do anything right, even the simplist things. I now have to assume that their entire documentation is wrong in every aspect-- from the fields I need to send them, to the meaning of their error codes, to the format things will come back to me in. I need to up my QA by an order of magnitude in order to feel secure in deploying this to a live website. And I have to ensure that my boss builds in 10x support costs into all contracts for the inevitable fuckups that will occur when they make changes to their live system without informing me in the future.

    7) FILE_NOT_FOUND



  • It's just as bad at the other end of the spectrum. We use a payment processor that supports a bunch of sane data formats, has good documentation, and they'll send us a sample implementation in pretty much any language. However, they charge $40,000 to turn on their gateway for us (and provide consulting services, but we needed like an hour of that). They're also considering adding such advanced features as the ability to query the status of a payment so we can see if it posted successfully (posting to the bank is asynchronous). They've been talking about adding this feature for two years now, but no progress yet.



  • 4) Because I don't know how the hell they'll escape "&" and "=" in their NVP implementation, so it's now more work for me to QA their format

    5) And speaking of which, I also need to figure out how they escape everything else. It looks like some quasi combination of URL encoding and something else. So not only do I have to implement a NVP parser, I also have to make sure to implement a decoder on the values.
    Actually, if they already decided to use their own home-grown not-quite-url-encoder, what makes you think they'd get escaping XML right?


  • I heard a certain popular payment system is slashing their fees which will make them cheaper than using a proper merchant facility and easier to get and will kill the competition. I'm not yet sure if this is a good thing or a bad thing. I haven't had major issues integrating with them in various systems but some people are allergic.


  • Trolleybus Mechanic

    @PSWorx said:

    Actually, if they already decided to use their own home-grown not-quite-url-encoder, what makes you think they'd get escaping XML right?
     

    It isn't even 9am, and you've managed to make me sad. Thanks.

    Now instead of enjoying my tea, I can only sit here, paralyzed with visions of code on their side:

    @You know this is what's fucking happening said:



    string xml = "";
    xml = "<Response>";
    xml = xml + "<order_id=" + chr(34) + ResultCollection["order_id"].replace(char(34), "\" + char(34)) + char(34) + ">";
    xml = xml + "<total_amt=" + chr(34) + ResultCollection["total_amt"].replace(char(34), "\" + char(34)) + char(34) + ">";
    // etc
    xml = xml + "</Response>";

     




  • @Lorne Kates said:

    @You know this is what's fucking happening said:



    $xml = "";
    $xml .= "<Response>";
    $xml .= "<order_id=\"" . preg_replace("\\'", "\'", addslashes($ResultArray["order_id"])) . "\">";
    $xml .= "<total_amt=\"" . preg_replace("\\'", "\'", addslashes($ResultArray["total_amt"])) . "\">";
    // etc
    $xml .= "</Response>";

     

     

    PHPTFY

     

     


Log in to reply