Hello all.

Wondering if someone could offer any tips as to where I might be going wrong.

We're working with a retail bit of software but have been provided with some code to work with the new Worldpay XML integration.

Standard purchases work fine but ones that require 3D Secure do not. The logic process is this;

1 > Order send to WP
2 < Order comes back from WP with URL to 3D Secure page
3 > We send user there
4 < We receive a further message from WP with a key that we pass back on the final request (to confirm the card was authorised).
5 > We submit a final order via a second php call back script, with the XML and the cookie from the initial submission.

Our code for the first order is;

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_FRESH_CONNECT,true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,false);
curl_setopt($ch, CURLOPT_POST,true);
curl_setopt($ch, CURLOPT_POSTFIELDS,$xml);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
curl_setopt($ch, CURLOPT_USERPWD, $merchantCode.":".$password);
curl_setopt($ch, CURLOPT_COOKIEJAR, "/home/path/dir/$invoiceID.cookie");
curl_setopt($ch, CURLOPT_TIMEOUT, 240);
$result_tmp = curl_exec ($ch);
if (curl_error($ch)) {
    $result_tmp = "Curl Error: ".curl_errno($ch)." - ".curl_error($ch);
}
curl_close ($ch);

which works fine as the initial order comes back ok.

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,false);
curl_setopt($ch, CURLOPT_POST,true);
curl_setopt($ch, CURLOPT_POSTFIELDS,$xml);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
curl_setopt($ch, CURLOPT_USERPWD, $merchantCode.":".$password);
curl_setopt($ch, CURLOPT_COOKIEFILE, "/home/path/dir/$invoiceID.cookie");
curl_setopt($ch, CURLOPT_TIMEOUT, 240);
$result_tmp = curl_exec ($ch);
if (curl_error($ch)) {
    $result_tmp = "Curl Error: ".curl_errno($ch)." - ".curl_error($ch);
}
curl_close ($ch);

The cookiejar file is created by the first script and checking the atime of the file, can see it being read by something (assuming the second script).

WP report "Internal error! Could not find bean(s) in session cache." and when asked about it - they say that we're not sending back the cookie information.

I've tried numerous code changes and after a 10 hour stint - have gotten no where.

Any help is really appreciated. Thanks.

Matt

    I'm not at all sure, but it sounds to me like this is a problem with a Java application. I've never heard of javascript referring to beans. Perhaps you could check the original web page in a browser and see if there are any Java apps in it?

    Another thing to check would be if a browser visiting the same page (assuming a browser can actually visit the page) has the same cookie as your cURL cookie.

    Lastly, are you certain that the path to the cookie file is the same in both scripts?

      Hi sneakyimp,

      Thanks for the reply.

      It's a JSP URL.. so I am going to guess yes. Although, we have no control over that as it is on the WP end.

      I've also checked it by logging into the page manually and do get the same format cookie as cURL.

      And yes, both cookie paths/files are exactly the same.

      I've just some some further testing with;

      curl_setopt($ch, CURLOPT_VERBOSE,true);
      curl_setopt($ch, CURLOPT_STDERR, $error_out);
      

      Which shows this on the curl that is having problems;

      * About to connect() to secure.ims.worldpay.com port 443 (#0)
      *   Trying 155.136.66.5... * connected
      * Connected to secure.ims.worldpay.com (155.136.66.5) port 443 (#0)
      * successfully set certificate verify locations:
      *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
        CApath: none
      * SSL connection using DES-CBC3-SHA
      * Server certificate:
      *        subject: /C=GB/ST=Lothian/L=Edinburgh/O=The Royal Bank of Scotland Group Plc/OU=Web Services/CN=secure.ims.worldpay.com
      *        start date: 2007-11-02 00:00:00 GMT
      *        expire date: 2010-11-01 23:59:59 GMT
      *        common name: secure.ims.worldpay.com (matched)
      *        issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
      * SSL certificate verify ok.
      POST /jsp/merchant/xml/paymentService.jsp HTTP/1.1
      Host: secure.ims.worldpay.com
      Accept: */*
      Cookie: machine=12345678
      Content-Length: 5598
      Content-Type: application/x-www-form-urlencoded
      Expect: 100-continue
      
      < HTTP/1.1 401 Authorization Required
      < Date: Wed, 11 Feb 2009 22:12:15 GMT
      < Server: Generic Webserver
      < WWW-Authenticate: Basic realm="Bibit Merchant XML Login"
      < Connection: close
      < Transfer-Encoding: chunked
      < Content-Type: text/html; charset=iso-8859-1
      < 
      * Closing connection #0
      * Issue another request to this URL: 'https://secure.ims.worldpay.com/jsp/merchant/xml/paymentService.jsp'
      * About to connect() to secure.ims.worldpay.com port 443 (#0)
      *   Trying 155.136.66.5... * connected
      * Connected to secure.ims.worldpay.com (155.136.66.5) port 443 (#0)
      * successfully set certificate verify locations:
      *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
        CApath: none
      * SSL re-using session ID
      * SSL connection using DES-CBC3-SHA
      * Server certificate:
      *        subject: /C=GB/ST=Lothian/L=Edinburgh/O=The Royal Bank of Scotland Group Plc/OU=Web Services/CN=secure.ims.worldpay.com
      *        start date: 2007-11-02 00:00:00 GMT
      *        expire date: 2010-11-01 23:59:59 GMT
      *        common name: secure.ims.worldpay.com (matched)
      *        issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
      * SSL certificate verify ok.
      * Server auth using Basic with user 'USERNAME'
      POST /jsp/merchant/xml/paymentService.jsp HTTP/1.1
      Authorization: Basic XXXXX
      Host: secure.ims.worldpay.com
      Accept: */*
      Cookie: machine=12345678
      Content-Length: 5598
      Content-Type: application/x-www-form-urlencoded
      Expect: 100-continue
      
      < HTTP/1.1 100 Continue
      < HTTP/1.1 200 OK
      < Date: Wed, 11 Feb 2009 22:12:16 GMT
      < Server: Generic Webserver
      < P3P: CP="NON"
      * Replaced cookie machine="12345678" for domain secure.ims.worldpay.com, path /, expire 0
      < Set-Cookie: machine=12345678;path=/
      < Content-Length: 441
      < Connection: close
      < Content-Type: text/plain
      < 
      * Closing connection #0

      12345678 = cookie ID

      To me, that looks perfectly fine and that it's setting the cookie on the first connect back - but I could be wrong.

      Thanks

      Matt

        Am I right in understanding that your CURL stuff executes successfully but that the remote payment gateway is reporting an error? If that's the case, it makes me wonder what is in $xml and what sort of data they are expecting. You might need to stick a value from the cookie into your POST fields or xml or something?

        It does look like the cookie is getting passed around. If you think you are handing them the cookie correctly, I would try to get more assistance from the payment gateway folks. I know this can be difficult sometimes.

        Sorry I can be of more assistance.

          Hi again 🙂

          As far as I can see (or understand from the logs that have been created).

          The $xml data is transactional and has no relation to the cookie - as far as I know and from reading their docs.

          No no, thanks for your help. I only added the verbose option after to see for myself that it does look like something their end - so that'll be my battle for tomorrow morning 🙂

          Wish me luck!

            3 months later

            Hi Matt,

            Did you have any luck with this in the end?

            Thanks

              17 days later

              Yes, I did finally get it working.

              It wasn't the cookie issue in the end - despite their very mis-leading error output.

              Within the WP docs there is a whole section missing, which is where we were getting caught out.

              There is a transaction ID you have to create at the start of the process (you create these now, instead of WP). This must stay the same throughout the whole transaction.

              The problem we had is that, we'd create one like E-timestamp-invoiceID, but on the second return, when we pass it back to WP again, the timestamp would change, thus giving us the problem.

              We then saved the transID into our database so the same value was passed throughout the whole transaction which fixed it!

              (then they added it to their docs - lovely eh!)

              Matt

                3 years later

                Hi Matt,

                We are running into the same problem and our developers can't seem to fix the problem.

                This is for a WorldPay integration on Magento. Would be something you could help with? Possibly some paid work

                Thanks, Pete

                  Never used Magento i'm afraid.

                  If you are having the same issue, just make sure the ID you set is the same on all calls as detailed in the above posts on how we fixed it.

                  Apart from that, can't really advise what it could be.

                  Matt

                    Write a Reply...