reubenwilcock Posted September 26, 2007 Posted September 26, 2007 I'm not on GoDaddy hosting... Quote
Guest Posted September 26, 2007 Posted September 26, 2007 the reason I asked is the only other person i've known with a blank screen with no errors on checkout_process.php was on GoDaddy. They needed a specific curl setting to work. The info is here it may apply to you (but with a different proxy server) - it would be worth checking with your hosts Tom Quote
Guest Posted September 26, 2007 Posted September 26, 2007 Thanks for another great Protx module, been using it since 2.0. I installed the latest update about 2 weeks ago and tested it with as many different cards as I could including maestro with 3d secure. Everything is working fine, but today Ive had a customer atempt payment twice and both times he's been forwarded to his account page and not checkout success. The payment has gone through in the protx admin but doesnt show on the site. Ive tried to repeat the problem with the same products and card but couldnt. Could it be his cookie setings are to blame? Quote
reubenwilcock Posted September 26, 2007 Posted September 26, 2007 I am trying to debug it now - I have established that it happily gets all the way to almost the end of the checkout_process.php file. I have altered the end so that it echos the link it is about to go to: echo('this is the link:' . tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL')); tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL')); require(DIR_WS_INCLUDES . 'application_bottom.php'); ?> This confirms that the link is created correctly - but it doesnt actually go to that link. I.e. it gets to checkout_process.php, does all the stuff in there (hence order goes through fine) and prints the link it wants to go to e.g. <mystore>/shop/checkout_success.php?osCsid=7b24f576ac592fc7b12e94b11ddaf14c but doesnt actually go there. If I copy and paste that link in the address bar it goes there fine and the successful checkout is reported etc... So, tep_redirect() doesnt seem to be making the page redirect to that link... Quote
reubenwilcock Posted September 27, 2007 Posted September 27, 2007 Ok, finally fixed it. My fault. I must have inadvertantly added some whitespace after the ?> in the protx_direct.php lanuguage file so there are a newline being outputted before the link was done. Sorted. Quote
Guest Posted September 28, 2007 Posted September 28, 2007 Reuben - glad it's sorted, thanks for letting us know. Cai - when you say account details - do you mean the account login? The module will redirect to the login and the order not processed if the session is dropped (which shouldn't happen) or the customer isn't logged in (which would only happen if the session was dropped). It certainly could be related to a bad cookie though if cookies are blocked it should be using the osCsid in the urls Tom Quote
brownowl Posted October 1, 2007 Posted October 1, 2007 (edited) Hi Tom, I have a strange problem here with V4.4. I have a shop that's working inasmuch as the dosh is being taken from the customer's card, the db table for protx_direct is being updated, but the order doesn't process at all. I've really tried to solve this, but would appreciate some help, please (it's a live site). What's happening is that I'm getting 'Credit Card Error!' on paying with a card, so have modified that string in includes/languages/english.php to change the Protx error message from 'Credit Card Error!' to 'Credit Card Error in Protx!', which message now appears after posting to Protx. I did that because there are several files with that string in, and I wanted to narrow down whence it comes. Protx takes the money from the card, but nothing seems to come back to the shop, no order, no emails, nothing. A valid record is written in the protx_direct table, however. In test mode, using a test card, it returns to the credit card page with this URL: https://shop.playwoodtoys.com/checkout_paym...c_expires_year= Another trip through the payment process, with a real card, AND via 3DSecure (which worked, the money was taken, db updated properly) led to this URL: https://shop.playwoodtoys.com/checkout_paym...c_expires_year= which is exactly the same as the one above! I'm sure that there's a clue in the fact that it keeps thinking the expiry date is incorrect (it isn't). At all stages the user interaction seems ok, and all forms, fields and confirmations are also correct. I've ripped out and reinstalled protex direct, checked and re-checked, and I can't find the cause. HELP!!! Cheers, Laurie. Edited October 1, 2007 by brownowl Quote
Thieving_Gypsy Posted October 2, 2007 Posted October 2, 2007 Hello My client is still getting large numbers of failed transactions (£2600 last month) due to the order not being completed. More investigation leads us to believe that the problem occurs on this page; protx_process.php?action=process And that just seems to be the new meastro cards without issue numbers! Any ideas anybody? My client is a bit frantic now and is considering going back to Protx Form... Andy Quote
brownowl Posted October 2, 2007 Posted October 2, 2007 In view of Thieving_Gypsy's comment above, I feel I should mention that the errors I have described were on a Mastercard, with and without 3DSecure. Cheers, Laurie. Quote
brownowl Posted October 2, 2007 Posted October 2, 2007 We've just put a card through the protx management screens successfully, and then tried the same card through the site. We get the usual error as described above. This is not good, and I'm at my wit's end to see where this might be going wrong. Cheers, Laurie. Quote
brownowl Posted October 3, 2007 Posted October 3, 2007 I've just done a test transaction and a live transaction, both failed as described above, but this time, here's the debug info: Test transaction with "test" card: Request URL=https://ukvpstest.protx.com/vspgateway/service/vspdirect-register.vsp Data string sent=VPSProtocol=2.22&TxType=PAYMENT&Vendor=******&VendorTxCode=25**-74669753405113456032259062******&Amount=3.00&Currency=GBP&Description=Order+Number%3A+2532&CardHolder=*****+***&CardNumber=5404000000000001&StartDate=0103&ExpiryDate=0108&IssueNumber=&CV2=123&CardType=MC&BillingAddress=********%2C+************+**%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&BillingPostCode=IP**+***&DeliveryAddress=********%2C+Grundisburgh+Rd%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&DeliveryPostCode=IP**+***&CustomerName=*********&ContactNumber=07736******&CustomerEMail=*********%40*******************&ClientIPAddress=10.0.1.152&Basket=2%3AColoured+Bookmarks%3A1%3A1.00%3A0.00%3A1.00%3A1.00%3AShipping%3A1%3A2%3A----%3A2%3A2&AccountType=E&Apply3DSecure=0 Protx response=VPSProtocol=2.22 Status=OK StatusDetail=0000 : The Authorisation was Successful. VPSTxId={954A6DC6-CCE4-2694-1ED1-EE82BF7*****} SecurityKey=W8AKPS**** TxAuthNo=3583*** AVSCV2=SECURITY CODE MATCH ONLY AddressResult=NOTMATCHED PostCodeResult=NOTMATCHED CV2Result=MATCHED 3DSecureStatus=NOTCHECKED Response array=Array ( [VPSProtocol] => 2.22 [status] => OK [statusDetail] => 0000 : The Authorisation was Successful. [VPSTxId] => {954A6DC6-CCE4-2694-1ED1-EE82BF7*****} [securityKey] => W8AKPS**** [TxAuthNo] => 3583*** [AVSCV2] => SECURITY CODE MATCH ONLY [AddressResult] => NOTMATCHED [PostCodeResult] => NOTMATCHED [CV2Result] => MATCHED [3DSecureStatus] => NOTCHECKED ) curl_error= Live card, live transaction: Request URL=https://ukvps.protx.com/vspgateway/service/vspdirect-register.vsp Data string sent=VPSProtocol=2.22&TxType=PAYMENT&Vendor=******&VendorTxCode=25**-52881278035046185963675275******&Amount=5.70&Currency=GBP&Description=Order+Number%3A+2532&CardHolder=*****+***&CardNumber=****************&StartDate=&ExpiryDate=0909&IssueNumber=7&CV2=802&CardType=MAESTRO&BillingAddress=********%2C+************+Rd%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&BillingPostCode=IP**+***&DeliveryAddress=********%2C+************+**%2C%0D%0AGt.+Bealings%2C%0D%0AWoodbridge%2C%0D%0ASuffolk%2C%0D%0AUnited+Kingdom&DeliveryPostCode=IP**+***&CustomerName=*****+***&ContactNumber=07736******&CustomerEMail=*********%40*******************&ClientIPAddress=10.0.1.182&Basket=2%3ABells%3A1%3A2.99%3A0.00%3A2.99%3A2.99%3AShipping%3A1%3A2.71%3A----%3A2.71%3A2.71&AccountType=E&Apply3DSecure=0 Protx response=VPSProtocol=2.22 Status=OK StatusDetail=0000 : The Authorisation was Successful. VPSTxId={5BA2D632-6DC6-AF80-D47C-1D38C47*****} SecurityKey=QY7EGN**** TxAuthNo=5868**** AVSCV2=SECURITY CODE MATCH ONLY AddressResult=NOTMATCHED PostCodeResult=NOTMATCHED CV2Result=MATCHED 3DSecureStatus=NOAUTH Response array=Array ( [VPSProtocol] => 2.22 [status] => OK [statusDetail] => 0000 : The Authorisation was Successful. [VPSTxId] => {5BA2D632-6DC6-AF80-D47C-1D38C47*****} [securityKey] => QY7EGN**** [TxAuthNo] => 5868**** [AVSCV2] => SECURITY CODE MATCH ONLY [AddressResult] => NOTMATCHED [PostCodeResult] => NOTMATCHED [CV2Result] => MATCHED [3DSecureStatus] => NOAUTH ) curl_error= Once upon a time I was a professional programmer, not in php unfortunately, and although I can mostly make sense of it, debugging it is difficult as it seems hard to get values and stuff at different stages of the processes. Cheers, Laurie. Quote
valerka1 Posted October 3, 2007 Posted October 3, 2007 Help Protx Direct v4.4 Fatal error: Call to undefined function: curl_init() in w:\home\test1.com\www\protx_process.php on line 339 Quote
brownowl Posted October 3, 2007 Posted October 3, 2007 HelpProtx Direct v4.4 Fatal error: Call to undefined function: curl_init() in w:\home\test1.com\www\protx_process.php on line 339 Post 210 onwards in this very topic (page 11) will answer your question. You need curl installed to use this plug-in, and you don't appear to have it. Cheers, Laurie. Quote
Guest Posted October 3, 2007 Posted October 3, 2007 sorry I haven't posted here for a little while - my net access is patchy at the moment! brownowl - I'm not sure what's going on here. To clarify from your posts: you attempt a transaction +/- 3D-Secure, it is successfully completed at the Protx end, the details are correctly recorded in the protx_direct table but the customer is directed back to checkout_payment.php with the "Invalid expiry date" error instead of checkout_success.php and there is no record of the order. This suggests something going wrong either in the protx_process.php file or early on in checkout_process.php. However, the expiry date message is only generated in one place in the module - the pre_confirmation() function and this is called between checkout_payment.php and checkout_confirmation.php (i.e. before anything is sent to Protx) therefore leading to my confusion. The debug is correct and should go through ok. Have I interpreted the situation correctly? thieving_gypsy can you confirm which version of php you are using? Just looking through the code today I've spotted a function that I've only recently discovered only works with PHP5 - it'll only come to light when there's a problem with either the issue number or start date (i.e with maestro cards) and will cause PHP to drop out with a fatal error in protx_process.php Tom Quote
brownowl Posted October 4, 2007 Posted October 4, 2007 sorry I haven't posted here for a little while - my net access is patchy at the moment! No problem, we all have our "challenges", but I must admit I was getting worried! brownowl - I'm not sure what's going on here. To clarify from your posts: you attempt a transaction +/- 3D-Secure, it is successfully completed at the Protx end, the details are correctly recorded in the protx_direct table but the customer is directed back to checkout_payment.php with the "Invalid expiry date" error instead of checkout_success.php and there is no record of the order. This suggests something going wrong either in the protx_process.php file or early on in checkout_process.php. However, the expiry date message is only generated in one place in the module - the pre_confirmation() function and this is called between checkout_payment.php and checkout_confirmation.php (i.e. before anything is sent to Protx) therefore leading to my confusion. The debug is correct and should go through ok. Have I interpreted the situation correctly? Tom Yes, you have. That is exactly what's happening. Thanks for the clues as to where this might be happening. I've checked the site, and I can confirm that the following files are unchanged: protx_process.php includes/languages/english/checkout_process.php These have been changed: checkout_confirmation.php checkout_payment.php checkout_process.php checkout_success.php They were changed for some plug-in or other, and I'll find out which and see if I can spot the problem. Cheers, Laurie. Quote
brownowl Posted October 4, 2007 Posted October 4, 2007 (edited) Just double-checked, and these have not been changed: checkout_payment.php checkout_process.php checkout_success.php This has been changed: checkout_confirmation.php It looks as if it's the change to force shoppers to accept the Ts & Cs prior to purchase, so I'll revert to the original code and re-test. Cheers, Laurie. Edited October 4, 2007 by brownowl Quote
brownowl Posted October 4, 2007 Posted October 4, 2007 Ok, I've reverted to the original code, and the error is just the same. Same message with a pink bar underneath. I'm sure there's supposed to be a message in there somewhere... Cheers, Laurie. Quote
Thieving_Gypsy Posted October 9, 2007 Posted October 9, 2007 sorry I haven't posted here for a little while - my net access is patchy at the moment! brownowl - I'm not sure what's going on here. To clarify from your posts: you attempt a transaction +/- 3D-Secure, it is successfully completed at the Protx end, the details are correctly recorded in the protx_direct table but the customer is directed back to checkout_payment.php with the "Invalid expiry date" error instead of checkout_success.php and there is no record of the order. This suggests something going wrong either in the protx_process.php file or early on in checkout_process.php. However, the expiry date message is only generated in one place in the module - the pre_confirmation() function and this is called between checkout_payment.php and checkout_confirmation.php (i.e. before anything is sent to Protx) therefore leading to my confusion. The debug is correct and should go through ok. Have I interpreted the situation correctly? thieving_gypsy can you confirm which version of php you are using? Just looking through the code today I've spotted a function that I've only recently discovered only works with PHP5 - it'll only come to light when there's a problem with either the issue number or start date (i.e with maestro cards) and will cause PHP to drop out with a fatal error in protx_process.php Tom Hi Tom The server is running php5.2 Andy Quote
Guest Posted October 11, 2007 Posted October 11, 2007 brownowl - if the error text is not appearing in the pink message box it may be due to a templating system such as STS. Do you have that installed? Thieving_gypsy - ignore my previous comment - I was looking at the wrong code - there shouldn't be any PHP5 issues (that I'm aware of). However there is a typo so that the error messages regarding start dates/issue numbers are incorrect. In protx_process.php find (164-169): if ($response_code == '5015') { if (stristr($responses['StatusDetail'],'Issue')) { $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_ISSUE; } elseif (stristr($responsed['StatusDetail'],'Start')) { $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_START; } and replace with if ($response_code == '5015') { if (stristr($responses['StatusDetail'],'Issue')) { $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_ISSUE; } elseif (stristr($responses['StatusDetail'],'Start')) { $error_detail = MODULE_PAYMENT_PROTX_DIRECT_TEXT_INVALID_START; } and again further down (497-502) Tom Quote
Guest Posted October 17, 2007 Posted October 17, 2007 in reply to nahi_sonu's problem where he had just a blank page after confirming an order we have solved the problem. It affects anyone who uses GoDaddy shared hosting. You need to edit the protx_process.php file and add the line curl_setopt ($ch, CURLOPT_PROXY,"http://proxy.shr.secureserver.net:3128"); in the TWO curl_setopt sections Tom Hello, I am having a blank page problem, I have tried everything that has been talked about on the board but with no success, done the usual settings changes and looked at the curl on and off options in protex_process I get as far as protx_process.php/action/process and the page goes blank Server info is HTTP Server: Apache/1.3.37 PHP Version: 4.4.4 (Zend: 1.3.0) CURL support enabled CURL Information libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 ** (IS THIS VERSION OKAY? ) ** No information is being stored on the site and no information is being sent to Protx test server My Host is Xcalibre and is using a dedicated SSL on a shared server. I would be so grateful if anyone could help I have been going round in circles for hours. Thanks Peter Quote
Guest Posted October 17, 2007 Posted October 17, 2007 protx_process.php/action/process implies you have "Use Search Engine Safe URLs (still in development)" set to true in your admin (Configuration -> My Store) - set to false and you should be fine. I recommend Chemo's Ultimate SEO URLs contrib. Tom Quote
brownowl Posted October 18, 2007 Posted October 18, 2007 brownowl - if the error text is not appearing in the pink message box it may be due to a templating system such as STS. Do you have that installed?Tom No! Thanks for your help, Laurie. Quote
Guest Posted October 19, 2007 Posted October 19, 2007 i am having problems using protx through test. I have transferred my website to a test domain and hosting service. the setting I have are: Vendor name: testvendor transaction mode: test any ideas? Quote
Guest Posted October 19, 2007 Posted October 19, 2007 you need to change "testvendor" to your actual vendorname Tom Quote
Guest Posted October 20, 2007 Posted October 20, 2007 you need to change "testvendor" to your actual vendorname Tom Hi Tom Yes I tried that but get this error: Your credit card could not be authorised. Please correct any information and try again or contact us for further assistance. (4020 : Information received from an Invalid IP address. The value was 212.**.**.***.) Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.