Jump to content

rlangton

Members
  • Content count

    17
  • Joined

  • Last visited

Profile Information

  • Real Name
    Ross Langton

Recent Profile Visitors

5,114 profile views
  1. rlangton

    Sage Pay Server

    Assuming you're trying to get this working on a test site, are there any access controls set up (password protected, firewall rules etc) that would prevent the sagepay server accessing your site? Our test site is password protected and I get a similar error until I disable the password protection.
  2. rlangton

    Sage Pay Server

    The redirection url is defined in catalog/includes/modules/payment/sage_pay_server.php as either:- tep_href_link(FILENAME_CHECKOUT_PAYMENT, 'payment_error=' . $this->code . (tep_not_null($error) ? '&error=' . $error : '') . '&' . tep_session_name() . '=' . tep_session_id(), 'SSL', false); or tep_href_link('ext/modules/payment/sage_pay/redirect.php', 'payment_error=' . $this->code . (tep_not_null($error) ? '&error=' . $error : '') . '&' . tep_session_name() . '=' . tep_session_id(), 'SSL', false); or tep_href_link(FILENAME_CHECKOUT_PROCESS, 'check=PROCESS&key=' . md5($sage_pay_server_securitykey) . '&VPSTxId=' . $HTTP_POST_VARS['VPSTxId'] . '&' . tep_session_name() . '=' . tep_session_id(), 'SSL', false); Might be worth checking in catalog/includes/filenames.php to make sure that FILENAME_CHECKOUT_PAYMENT and FILENAME_CHECKOUT_PROCESS are defined (although can't see why they wouldn't be unless you've got a non-standard checkout module installed) All the redirection URL's are SSL, so it might be worth checking your SSL settings in catalog/include/configure.php
  3. Does it work OK if you use disable the custom template in sagepay admin and use one of the standard payment page options (DEFAULT, ADDRESS READ ONLY or NO ADDRESS)?
  4. rlangton

    Any potential pitfalls using the new SagePay Direct module?

    The SagePay server module loads the payment pages within an iframe on your site, so the customer does not actually leave your site, but their payment info is still input directly onto sagepay hosted pages. It therefore only has the same PCI audit requirements as the form module whilst giving a similar feel to the server module (although not quite as slick)
  5. rlangton

    Sage Pay Form V1.1

    Hi, Unless you have a wildcard ssl certificate, 'HTTPS_SERVER' should be set to the exact domain you gave when you ordered your ssl certificate otherwise your customers may get an invalid certificate error when they view the secure parts of your website. This could just be mysite.co.uk, but I would think more likely www.mysite.co.uk If your HTTP_SERVER and HTTPS_SERVER addresses are both www.mysite.co.uk, then you could try changing both 'HTTP_COOKIE_DOMAIN' and 'HTTPS_COOKIE_DOMAIN' to be 'www.mysite.co.uk' rather than just 'mysite.co.uk'. As for your emails, do you have outlook running on another PC that might have already downloaded the mail from your server before you opened it? Cheers, Ross
  6. rlangton

    Sage Pay Form V1.1

    Could you clarify what you mean by "no longer on server"? - Do you mean that you've received a confirmation email from Sage Pay, but that you can't see the order on the sage pay system?
  7. rlangton

    Sage Pay Form V1.1

    Tigergirl, Have you tried pointing your test website to the live sage pay server and trying a small test order using your own card? Cheers, Ross
  8. rlangton

    Sage Pay Form V1.1

    Similar problem in server with the VendorTxCode, It's built up like this (I assume form and server are probably similar here):- 'VendorTxCode' => substr(date('YmdHis') . '-' . $customer_id . '-' . $cartID, 0, 40) For some reason the $cartID variable doesn't always seem to be set, which I guess is why the VendorTxCode sometimes ends in a '-', and sometimes in a number (the cartID)
  9. rlangton

    Sage Pay Form V1.1

    Hi, The way the orders are logged is more down to oscommerce than sagepay or these modules, i would imagine you'd find similar problems using osc with any payment provider where you're redirected to their own hosted payment pages. However, one of these contributions which log orders before the redirection might be what you're after:- http://addons.oscommerce.com/info/1168 http://addons.oscommerce.com/info/5749 http://addons.oscommerce.com/info/6239 http://addons.oscommerce.com/info/871 http://addons.oscommerce.com/info/1153 Cheers, Ross
  10. rlangton

    Sage Pay Form V1.1

    Hi, The server module still logs the order after the payment is complete, but it works differently so I think there is probably less chance of the payment going through but the order not being logged than there is with the form module, although I guess it could still happen, but we haven't had any problems yet. I haven't looked at the official release of the direct module, but we were using the previous version a while back and I think that eliminated the possibility of orders not being logged, but we moved away from that due to the PCI audit requirements. The server module isn't quite as slick as direct, but I personally think it's a big improvement over the form module, customers don't have to be directed away from your site to enter their payment details (which we found caused a few abandoned orders) it cuts down the number of payment steps and it only has the same PCI audit requirements as form. Depending on your web host, you might have issues getting server or direct to work, they both need curl installed and you need to provide sage pay with the ip address of the server sending the requests. I think there are contributions available that will change the checkout process to log the order when the customer click on confirm on the checkout confirmation page which might be what you're after. Never really liked the idea of this as you end up with orders logged that might not have actually been paid for. Cheers, Ross
  11. rlangton

    Sage Pay Form V1.1

    Hi, I think the VPS Transaction ID is probably totally unique on the sage pay system, whereas the VendorTxCode is only unique to your sagepay account, so I guess maybe if a customer queried the transaction directly with sage pay then they'd be able to find it easier with the VPS Transaction ID (but that's a bit of a guess) I've only been testing the server module, so not 100% sure this would work, but I think if you wanted to change it then you could try editing catalog/includes/modules/payment/sage_pay_form.php and change this line:- $order->info['comments'] = 'Sage Pay Reference ID: ' . $return['VPSTxId'] . (tep_not_null($order->info['comments']) ? "\n\n" . $order->info['comments'] : ''); to $order->info['comments'] = 'Sage Pay Reference ID: ' . $return['VendorTxCode'] . (tep_not_null($order->info['comments']) ? "\n\n" . $order->info['comments'] : '');
  12. rlangton

    Sage Pay Form V1.1

    That reference is the VPS Transaction ID, you can search for a transaction using that reference in My Sage Pay. (although i don't think it actually shows on the transaction detail page)
  13. rlangton

    Sage Pay Server

    The new custom templates have solved the problem mentioned in point 2. Thanks John and Harald for getting these issues sorted out so quickly. Everything seems to be working fine now. Cheers, Ross
  14. rlangton

    Sage Pay Server

    Thanks John, Have messaged you our vendor details. Cheers, Ross
  15. rlangton

    Sage Pay Server

    Hi Harald, Version 1.1 seem to be working fine. Thanks for releasing the update so quickly. I've downloaded the custom templates from the Sage Pay website and have sent unmodified versions back to Sage Pay to upload to our test account. I'll let you know if that solves the iframe issue once they've uploaded them. Thanks again. Cheers, Ross
×