Jump to content
Sign in to follow this  
perfectpassion

Protx Direct v2.22

Recommended Posts

@stubbsy - I have had a request from someone else for repeat payment functionality and have added it to it - you'll see it in the next update (soon)! With regards to the error messages not displaying I'm a bit stumped - It passed the checkout_payment.php by the module files as prat of the url and then it is the responsibility of checkout_payment.php to extract the error message from the url and display it on the page. Do you get anything displayed at all?

 

@kdenby - I have seen a couple of transactions like this over the weekend - after speaking to Protx apparently they have had issues with their X25 lines to the bank which has caused various problems with time outs etc so it may be related to this. I also think (but haven't yet proven!) that it may sometimes be caused by customers clicking to submit the "3D Complete" form whilst it also self-submits hence the duplication - I've tweaked the code to stop this - I'm just checking that it works ok before uploading (another version).

 

@future1 - I've sorted the problem with transaction not found that sometimes happens. With the blank page issue however - what happens if you switch "debug" to true and try the transaction?

 

Tom

Share this post


Link to post
Share on other sites
@stubbsy - I have had a request from someone else for repeat payment functionality and have added it to it - you'll see it in the next update (soon)! With regards to the error messages not displaying I'm a bit stumped - It passed the checkout_payment.php by the module files as prat of the url and then it is the responsibility of checkout_payment.php to extract the error message from the url and display it on the page. Do you get anything displayed at all?

 

Hi Tom,

 

great news about the repeat function, I shall look forward to that being added.

 

With regards the error messages, I get the red/pink box displayed on the page with the words 'credit card error!' above it but I'm assuming the error text should be in that box?

 

I've just double checked (again) and uploaded a clean checkout_payment file and I still get nothing in the box.

 

Thanks

 

Dave

Share this post


Link to post
Share on other sites

Just looking back at your post i see that you posted it as

https://www.mysite.com/checkout_payment.php?payment_error=protx_direct&error=Unfortunately+there+has+been+a+technical+problem

 

If when this is displayed you change it by hand from & to & does it work? If so I suspect your tep_href_link in includes/functions/html_output.php is mangling the link (do you have ultimate SEO urls? - if so change

return $seo_urls->href_link($page, $parameters, $connection, $add_session_id);

to

return preg_replace('/&/','&',$seo_urls->href_link($page, $parameters, $connection, $add_session_id));

)

Share this post


Link to post
Share on other sites

Hi Tom,

 

Sorry to hassle you again after having fixed my first query. but I now have another issue in so far as when I click confirm order I get this error

HTTP Status 500 - 

_____ 


type Exception report

message 

description The server encountered an internal error () that prevented it
from fulfilling this request.

exception 

javax.servlet.ServletException

com.protx.mpi.simulator.AccessControlServlet.processPayerAuthentication(Acce
ssControlServlet.java:229)

com.protx.mpi.simulator.AccessControlServlet.doPost(AccessControlServlet.jav
a:76)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

root cause 

java.lang.NullPointerException
java.lang.StringBuffer.<init>(Unknown Source)
com.protx.mpi.xml.MessageComposer.addDTD(MessageComposer.java:61)
com.protx.mpi.xml.XmlHelper.parse(XmlHelper.java:47)

com.protx.mpi.simulator.AccessControlServlet.processPayerAuthentication(Acce
ssControlServlet.java:151)

com.protx.mpi.simulator.AccessControlServlet.doPost(AccessControlServlet.jav
a:76)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

note The full stack trace of the root cause is available in the Apache
Tomcat/5.5.17 logs.

 

I sent an email off to protx and this is the reply they sent:-

 

Thank you for your email to Protx support.

 

We can confirm that a NullPointerException error is caused by either the ' PAReq' or 'PaRes' being incorrectly formatted. If these fields are passed any way except exactly as written here then this will cause this error to occur. Please ensure that you are correctly formatting these fields, and try processing the transaction again.

 

You will also need to ensure that you are not modifying the values for these fields, as any change may cause an error. You will however, have to ensure that the PaRes which is returned from your servers to the Protx systems is URL-encoded. If the PaRes is not URL-encoded then this can also cause a 'NullPointerException' error.

 

Unfortunatley this mmeans nothing to me just wondered if it did to you?

 

Regards Chris


Better to be looked over than overlooked!

Share this post


Link to post
Share on other sites
Just looking back at your post i see that you posted it as
https://www.mysite.com/checkout_payment.php?payment_error=protx_direct&error=Unfortunately+there+has+been+a+technical+problem

 

If when this is displayed you change it by hand from & to & does it work? If so I suspect your tep_href_link in includes/functions/html_output.php is mangling the link (do you have ultimate SEO urls? - if so change

return $seo_urls->href_link($page, $parameters, $connection, $add_session_id);

to

return preg_replace('/&/','&',$seo_urls->href_link($page, $parameters, $connection, $add_session_id));

)

 

TA DA!

 

That was the problem, all working now, well spotted!

 

Thanks for your patience Tom

 

Much appreciated

 

Dave

Share this post


Link to post
Share on other sites

Is this when testing 3D-secure with the protx test server - and happens when you submit the test 3D-Secure passowrd form? If so I'm aware of this and had a discussion with protx support - in this case what they say above if wrong. It is caused by the cookie from the test server being blocked by default by IE. If you go into IE settings and reduce the privacy slider to the lowest you'll probably find it works fine.

 

If that's not the problem let me know.

 

Tom

Share this post


Link to post
Share on other sites
Is this when testing 3D-secure with the protx test server - and happens when you submit the test 3D-Secure passowrd form? If so I'm aware of this and had a discussion with protx support - in this case what they say above if wrong. It is caused by the cookie from the test server being blocked by default by IE. If you go into IE settings and reduce the privacy slider to the lowest you'll probably find it works fine.

 

If that's not the problem let me know.

 

Tom

 

Hi Tom,

 

Yes if I drop the privacy to it's lowest that works however something else I noticed hopefully it's not just me! When it authorised the transaction and before it passes you back to your site it says"Transaction complete blah blah" with a button saying "Click here to continue". If I click on the button it then throws me back to the card input details and says that there has een a thecnical issue and to retry. However if I do nothing in about 3-5 seconds it then goes to the Transaction complete that I would expect to see and gives the customer the option to carry on.

 

So two things here, I take it on the issue of lowering the Privacy you are in discussion with Protx and should be fixed as soon as you are able?

But what about the issue of completing the sale any Ideas?

 

Also I must add that all this is on a test server but I believe it should be as a live server?

 

Thanks Chris


Better to be looked over than overlooked!

Share this post


Link to post
Share on other sites

I suspected this has been happening - I have removed the submit button (unless JS is disabled) to prevent this and it seems to run smoother and without probs - I'm going to upload this changes in the next few days.

 

The cookie issue is a problem with the way protx have coded the test server system and they aren't going to change it. It shouldn't affect the live server if the banks have coded their pages properly.

 

Tom

Share this post


Link to post
Share on other sites

Ok, so onto the next problem :)

 

Since getting the errors sorted and turning 3D on about 36 hours ago, I now have multiple authorised transactions for customers before their order is successfully created in OSC.

 

I've inluded a screenshot below, due to the times involved I don't think this has anything to do with the confirmation button being clicked multiple times in quick succession...

 

protx_problems.jpg

 

any ideas

 

Dave

 

(ps, I don't think the image shows anything confidential, but please let me know if you think it does)

Share this post


Link to post
Share on other sites

What I believe is happening is that after the 3D-Secure bit is done it goes to the "complete" screen - this self submits but people also are clicking the submit button - this double submission results in them being taken back to the payment page with "technical problem" error so they resubmit the whole transaction again - hence the few minutes between multiple transactions.

 

I am just testing to make sure that this is the case and that it is not happening if this is solved - hopefully have an updated contrib posted tomorrow.

 

In the meantime if you disable the iframe (see setting at top of protx_process.php) you shouldn't have this problem - the other alternative is using "DEFERRED" payments so duplicate payments aren't taken - you can just release the ones needed.

 

Tom

Share this post


Link to post
Share on other sites

Thanks Tom,

 

I'll disable the iframe for the time being

 

Cheers

 

Dave

Share this post


Link to post
Share on other sites

I've just posted v4.3.

 

I hope this will address all the recent issues and prove to be issue free, stable version.

 

The main features are:

- Altered 3D-Complete page to prevent "Technical error" messages and multiple transactions

- Change to fixed width 3D-Secure iframe (as per VbV rules)

- Logos for VbV / SecureCode included with info on checkout_confirmation

- Ability to control 3D-Secure on a per card type basis

- REPEAT function added to admin area

- REFUND/REPEAT etc correctly selecting transaction data

 

As usual any probs let me know,

Tom

Share this post


Link to post
Share on other sites
I've just posted v4.3.

 

I hope this will address all the recent issues and prove to be issue free, stable version.

 

The main features are:

- Altered 3D-Complete page to prevent "Technical error" messages and multiple transactions

- Change to fixed width 3D-Secure iframe (as per VbV rules)

- Logos for VbV / SecureCode included with info on checkout_confirmation

- Ability to control 3D-Secure on a per card type basis

- REPEAT function added to admin area

- REFUND/REPEAT etc correctly selecting transaction data

 

As usual any probs let me know,

Tom

 

Hi Tom,

 

The fixed width iframe rule, what is it? Does it have to be 400x400 or can it be any size as long as it is fixed-width? 400x400 is too small and gives scroll bars.

 

Thanks

John

Share this post


Link to post
Share on other sites

400x400 is the size recommended by Visa (actually they say 390x400) - the size they say so not to have scroll bars - it can be any size greater that this. You say you get scroll bars -is that on the live server or just the simulator/test as Protx's paes are non-standard.

 

The main issue with the iframe was people clicking the submit button whilst the form auto submitted resulting in a suvvessful payment but the customer being told a technical fault - the submit button now only shows if JS is disabled.

Share this post


Link to post
Share on other sites
400x400 is the size recommended by Visa (actually they say 390x400) - the size they say so not to have scroll bars - it can be any size greater that this. You say you get scroll bars -is that on the live server or just the simulator/test as Protx's paes are non-standard.

 

The main issue with the iframe was people clicking the submit button whilst the form auto submitted resulting in a suvvessful payment but the customer being told a technical fault - the submit button now only shows if JS is disabled.

 

Ah, just the test page Tom, sorry. Not gone live with 4.3 yet, should have it live later today.

 

Thanks for your work Tom.

Share this post


Link to post
Share on other sites

Tom, found a small bug. We allow users to collect, in which case no delivery address is passed. The code as it is automatically adds commas (,) between the delivery lines, ie.

 

$delivery_add .= ",\r\n" . $order->delivery['suburb'];

 

This was causing an INVALID error and "If you provide a DeliveryAddress you must provide and DeliveryPostCode and vice versa."

 

so I've changed the code to

 

if($order->delivery['suburb'])

$delivery_add .= ",\r\n" . $order->delivery['suburb'];

 

for all those lines and it now works fine.

 

Thanks

John

Share this post


Link to post
Share on other sites

Hi Tom,

 

just thought I'd let you that I installed this Saturday morning and so far so good :) all working fine with no problems.

 

I like the ability to only able the 3D on a per card basis, I've only enabled this on the switch cards for the moment

 

Good work

 

Dave

Edited by stubbsy

Share this post


Link to post
Share on other sites

Good to hear things are going well.

 

@johnr3 - I hadn't considered the situation with no delivery address - I will included next time an update is needed, thanks.

 

Tom

Share this post


Link to post
Share on other sites

Tom

 

Thanks for 4.3 - been running it live for 24 hrs and 'so far so good' with no repeat debits and all the data in protx_direct table is coherent ... so I reckon you have done it!

Great and thanks a bunch for all the work.

Share this post


Link to post
Share on other sites

Hi everyone, i have installed version 4.3 yesterday and all was fine and working well.

I am currently on the Protx TEST server

 

3D Secure was working fine, Switch/Meastro were being verified, other cards were going through without the need for 3dSecure. All was great

 

Then today things gradually stopped working, Switch/Maestro stopped being verified and started getting this error message

"Credit Card Error! Unfortunately there has been a technical problem. Please try again and if the problem persists please contact us"

Other cards are going through fine, but when i checked VSP admin, i noticed that cards that were being cleared weren't having CV2 verified.

 

I logged in to VSPadmin and it looks like Protx are changing stuff, the page layouts are different to when i logged in yesterday.

I wonder if this is the route of the problems i am having.

 

Has anyone else noticed this and having the same problems.

Share this post


Link to post
Share on other sites

I think i have found out what why maestro cards have stopped authorise in the test environment(for me anyway)

 

I think the protx test CC numbers have just become a lot stricter in what you can enter

http://techsupport.protx.com/cardtypes.asp#howcardtest

 

You now have to make sure that you enter CV2, postcode and address as they require eg.

Maestro: 5641820000000005

CV2: 123

Billing Address: 88

Billing PostCode: 412

3Dsecure password: password

 

But as you cant enter an address of just "88" and a postcode as short as "412" into oscommerce the card fails to authorise.

 

I have tested this using Protx Form and the card will only authorise when you enter the above details exactly.

You will also notice that the ProtxForm pages have changed in appearance, which makes me think that protx are messing around with stuff

Share this post


Link to post
Share on other sites

I think when Protx say you need those number they mean as part of the address/postcode rather than exclusively e.g: 88 Test road, Testtown, Z41 2ZZ as an address.

 

Protx have added this feature due to some complaints on their forums about not being able to test for CV2 / AVS failures.

 

Tom

Share this post


Link to post
Share on other sites

Hi Tom, thats what i thought.

 

But it dosnt work for me, i need to remove the form validation to test whether it will authorise the Maestro card just using "88" as the address etc. I suspect this will work as i can only get Maestro to authorise using ProtxForm using exclusively 88 and 412 etc.

 

has anyone else tried to authorise a Maestro using 3dsecure on the test server recently?

 

Would like to know whether its just me?

 

Cheers James

Share this post


Link to post
Share on other sites

Well, here's one I haven't come across before (error message that is). Normally version 3.0c works 'out of the box', but this is the error I am getting in Test Mode:

 

3021 : The Basket format is invalid. The value was 2:Mazda 6 Workshop Manual:1:9.99:0.00:9.99:9.99:Shipping:1::----::. - Your credit card could not be authorized for this reason. Please correct any information and try again or contact us for further assistance.

 

Tom - do you have any idea about this one - come across it before?

 

Vger

Share this post


Link to post
Share on other sites

@jameseltherington - I've just had chance to check it out - they've updated the test server and you are right it would pass AVS checks unless the address / postcode if as you say - how irritating - I'll feed that back via their support forum.

 

@Vger - Just testing that out it seems that the basket is invalid because the shipping is zero so the Protx interpretes that as a missing field. If you are using v3.0c change the following in protx_process.php

$Shipping=$HTTP_POST_VARS['shipping_total'];

with

 		 // $Shipping = $HTTP_POST_VARS['shipping_total'];
	 if (tep_not_null($HTTP_POST_VARS['shipping_total'])) { 
	   $Shipping=$HTTP_POST_VARS['shipping_total']; 
	 } else { 
	   $Shipping='---'; 
	 }

 

and that should solve it. I'll include that as a permanent change in any subsequent update to prevent it occurring to anyone else.

 

Tom

 

 

(note to those using later version needing that fix - it's exactly the same but $HTTP_POST_VARS is replaced by $_POST)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×