Kristoff
-
Posts
86 -
Joined
-
Last visited
Posts posted by Kristoff
-
-
Yep. The last order before updating had:
b1d8******hVXOK £50.00 SagePay Oct 02 2014, 12:47 PM 0000 : The Authorisation was Successful.
The orders since the update:
Not Available £50.00 SagePay Yesterday, 23:35
Nothing in notes column -
The problem i'm having is that it's just leaving the order as Pending. How can I find any other details out on why it's not completing the payment?
Edit: My returning URL after payment is:
index.php?cart_order_id=141007-233451-7808&_a=complete
Second Edit:
Could this be related to the issue? Upon arriving at Sagepay the URL is:
cardselection?vpstxid={92AE6080-A594-3572-B9A0-529E92DD5DE3}
Would the curly brackets be playing havock with the processing?
-
Ok, apologies. Mac/Chrome, hid my scrollbar, looked like the bottom of the page!!
-
It's mentioned in 2 places. Configure Command and Registered Stream Filters.
-
Let's just double-check:
In admin, navigation panel, click PHP Info. Scroll down about half-way until you get to a section (in alphabetical order) that may or may not be there: mcrypt. It will be between mbstring and mhash.
If the mcrypt section is there, then we have a different problem with the module.
If the mcrypt section is not there, then please contact your hosting provider to have them enable this PHP extension for your hosting account.
'--with-mcrypt=/opt/libmcrypt/'?
-
I have no idea what that is or what it consists of?
-
How do we go about validating payments now then? Or can't we?
-
Thanks for that. Still pending unfortunately... I'm fairly sure from the return URL in sagepay that it's using AES again, which I need to be XOR
-
Hi guys, we had this issue before, but fixed it, see here:
http://forums.cubeca...s-with-sagepay/
However, this time, i've checked how I fixed it before, which is still the same, yet not working. Basically after payment, the order is just setting to pending... Nightmare. Any ideas?
Seems like it's not letting me set it to XOR?
-
Just to add to this, callback URL's in sagepay are now ending with an A again instead of an X, but I no longer see the AES or XOR choice in the sagepay module.
-
Hi guys, we had this issue before, but fixed it, see here:
'?do=embed' frameborder='0' data-embedContent>>
However, this time, i've checked how I fixed it before, which is still the same, yet not working. Basically after payment, the order is just setting to pending... Nightmare. Any ideas?
-
In CC5213, line 888 is within the CubeCart->_checkout() function. This is not where you want to be if you are trying to catch bogus registrants.
I assume you have edited the template file content.register.php by adding the hidden field middlename. (We will assume your tactic is valid.)
In the file /classes/user.class.php, line 659 (CC5213), we test for an empty first_name, or an empty last_name. You can add your test after this for an existing middlename.
Perfect, thank you.
As the field is not something anyone will ever see I simply added:
|| !empty($_POST['email1'])
To
if (empty($_POST['first_name']) || empty($_POST['last_name'])) {
And in my tests it seems to work. It does display "We need your name" error if the field is filled in, but that's fine as most people won't encounter it.
-
Hi guys, my client and I don't like or wish to use Captcha on the register form. Is it possible to add in a field to the registration form and check whether it's not empty and kill the registration? In cubecart.class.php on line 888 before:
// Check email is valid if (!filter_var($_POST['user']['email'], FILTER_VALIDATE_EMAIL)) { $errors['email'] = true; $error_messages[] = $GLOBALS['language']->common['error_email_invalid']; }
I've tried adding:
if ($_POST['user']['middlename'] != "") { die(); }
And then adding a hidden "middlename" field to the registration, but even if you complete middle name it lets you sign up.
Anyone got any ideas why my code isn't working?
Cheers
-
For now i've solved it by just adding it in the htaccess by redirecting http to https.
-
Won't that mean that it won't use https unless they navigate to it that way?
-
On our store in settings i've just noticed Enable SSL is reverting to no. Trying to force SSL. The settings are:
Enable SSL: Yes
Force SSL mode: Yes
SSL Root: ''
SSL URL: https://www.example.com
Standard URL: https://www.example.com
I've tried making SSL Root: / but that just ends up in a redirect loop?! Please help, cheers.
-
As far as I can see it's just categories on the navigation, but I can't be certain. To be honest I felt the need to clear the cache rather investigate as people may have been on the site! Next time I will investigate more.
-
Got a strange issue that's happened twice now, the store address has reverted back to the old store address, meaning there is an issue when you click on the links it tries to go to the old URL and causes an error because of the SSL Certificate being on the new address.
Anyone got any idea why this would happen? A cache clearing seems to sort it out, but it's a pain to have to keep checking it.
-
I don't know if i've got them in the wrong place, but i've just got:
902780b*****7dd2d9UHwLcDzD OK £0.50 SagePay Today, 14:40 0000 : The Authorisation was Successful.
-
It's working now buddy. Do you mean check and see what encryption it's using?
-
Guys, Success!! (I think!) Will post shortly...
Edit:
I've sussed it. I did a search for "XOR" and found this little fella:
private $_encryption = 'AES'; // can be XOR
Despite the setting on the gateway being XOR it said AES here. So I changed AES to XOR and it worked straight away!
-
Ok, that's not working then. Could it be what I said about the A or X at the end of the callback URL relating to AES or XOR? If so, it's not changing when I change between the 2 on the settings. Is there any way to manually change this?
-
Could the A or X relate to AES or XOR? if so, any idea why it was sending a callback with A on when I had XOR selected?!
-
By the way, i've just been sent a successful referring URL from the old successful transactions:
https://www.domain.com/index.php?_g=rm&type=gateway&cmd=process&module=Protx&cart_order_id=*OrderID*X
On 2 other old, successful transactions, there is an X at the end instead of an A. Not sure what relevance this does or doesn't have.
bssmither, just tried that code and got this:
"Decoding callback failed. Nothing to decrypt."
Erm, i've just noticed the old gateway also says Protx in the callback?! Could this be an error? I'm assuming that just tells the store which payment system was used?
Issue with SagePay 3.0 and digital downloads after update... again...
in Technical Help
Posted
"Notes: Crypt:"