Jump to content
Sign in to follow this  
Fanny

Verisign Issues

Recommended Posts

Is anyone having trouble with Verisign PayflowLink. Here's what's going on. oscommerce submits to verisigns Payflowlink page and then it comes back to oscommerce but none of the data is getting stored in oscommerce. They are being charged (for which product i do not know) because my report from versign is correct, but as far as the information getting stored into oscommerce, it's just not happening.

 

It JUST started happening like, 3 hours ago. I have no idea what's going on. Can anyone shed some light on this?

Share this post


Link to post
Share on other sites
Is anyone having trouble with Verisign PayflowLink. Here's what's going on. oscommerce submits to verisigns Payflowlink page and then it comes back to oscommerce but none of the data is getting stored in oscommerce. They are being charged (for which product i do not know) because my report from versign is correct, but as far as the information getting stored into oscommerce, it's just not happening.

 

It JUST started happening like, 3 hours ago. I have no idea what's going on. Can anyone shed some light on this?

 

I'm having the exact same issue, on two different sites that I built and maintain. I'm currently sitting on hold with VeriSign technical support and will post the results of my discussion with them once I talk to them - but it's definitely not just you.

 

They apparently began a migration process to new servers this morning, and although nothing is supposed to be deprecated until July 1st, I'm betting it's related.

Share this post


Link to post
Share on other sites
I'm having the exact same issue, on two different sites that I built and maintain.  I'm currently sitting on hold with VeriSign technical support and will post the results of my discussion with them once I talk to them - but it's definitely not just you.

 

They apparently began a migration process to new servers this morning, and although nothing is supposed to be deprecated until July 1st, I'm betting it's related.

 

We just got off of the phone with verisign and apparently they are limiting the number of characters posted back to our site to 255. But I don't even know what that means or how to fix it.

Share this post


Link to post
Share on other sites
We just got off of the phone with verisign and apparently they are limiting the number of characters posted back to our site to 255.  But I don't even know what that means or how to fix it.

 

After spending over an hour on the phone with the support representative, we have temporarily fixed the problem by changing a line in the class constructor in /includes/modules/payment/payflowlink.php.

 

This line (line 21 in my file):

$this->form_action_url = 'https://payflowlink.verisign.com/payflowlink.cfm';

becomes this:

$this->form_action_url = 'https://cf.payflowlink.verisign.com/payflowlink.cfm';

 

This apparently hits their old server instead of the one they just switched to, meaning everything works as it did yesterday. It seems to have resolved the problem for us. I don't know if this will work for anyone or if VeriSign has to authorize accounts to hit the old server. In any event, the rep told me that the problem should be tracked down by the engineers and resolved in the next 24-48 hours - but those of you with stores that are losing order information might want a speedier resolution.

 

Good luck -

Share this post


Link to post
Share on other sites

I work with VeriSign and the fix stated above is only a temporary fix. VeriSign is in the process of removing our cold fusion servers and the URL listed above will only be available for a short timeframe.

 

At this time, we are unaware of the actual reason why the shopping cart is not working as we know of other OS Commerce sites using the new URL.

 

The current URL for Payflow Link should be https://payments.verisign.com/payflowlink.

 

If anyone else is having issues, I'll be happy to work with you directly to resolve them.

 

Todd

Edited by tsieber

Share this post


Link to post
Share on other sites
I work with VeriSign and the fix stated above is only a temporary fix.  VeriSign is in the process of removing our cold fusion servers and the URL listed above will only be available for a short timeframe.

 

At this time, we are unaware of the actual reason why the shopping cart is not working as we know of other OS Commerce sites using the new URL.

 

The current URL for Payflow Link should be https://payments.verisign.com/payflowlink.

 

If anyone else is having issues, I'll be happy to work with you directly to resolve them.

 

Todd

 

Hi Todd,

 

Thank you. Adding the cf before the old URL has solved the problem for me. When I switch to the new URL the problem occurs. Should we leave the old cold fusion URL up until July 1st? At that point what should we do?

 

Thanks, Brina

Share this post


Link to post
Share on other sites
Hi Todd,

 

Thank you.  Adding the cf before the old URL has solved the problem for me.  When I switch to the new URL the problem occurs.  Should we leave the old cold fusion URL up until July 1st?  At that point what should we do?

 

Thanks, Brina

 

 

For now you can. However, I would like to work with someone who might have a development system available that is experiencing the problem.

 

Known issues revolve around silent post, return and post URL (which will no longer be suppported effective July 1, due to security concerns) and merchant identification error.

Share this post


Link to post
Share on other sites
After spending over an hour on the phone with the support representative, we have temporarily fixed the problem by changing a line in the class constructor in /includes/modules/payment/payflowlink.php.

 

This line (line 21 in my file):

      $this->form_action_url = 'https://payflowlink.verisign.com/payflowlink.cfm';

becomes this:

      $this->form_action_url = 'https://cf.payflowlink.verisign.com/payflowlink.cfm';

 

In my version, which i don't know which "version" i have of this verisign payflowlink contribution but the URL lies in the english file, for those of you with the same version: /includes/languages/english/modules/payment/cc_via_verisign.php

 

On Line 13:

Change:

define('MODULE_PAYMENT_VERISIGN_URL','https://payflowlink.verisign.com/payflowlink.cfm');

To:

define('MODULE_PAYMENT_VERISIGN_URL','https://cf.payflowlink.verisign.com/payflowlink.cfm');

 

Again this is only a TEMPORARY fix for those of you that missed that.

Share this post


Link to post
Share on other sites

We are having the same problem too. Any idea on when some kind of fix will come out?


I need to read the rules more often...

Share this post


Link to post
Share on other sites
That URL isn't working for some of us.  Which contribution are you using?

 

 

Try this from a post higher up on the list.. its only TEMPORARY, but is working for me..

 

$this->form_action_url = 'https://cf.payflowlink.verisign.com/payflowlink.cfm';

 

Apparently as stated above, Verisign is aware of the glitch and is working on a permanent fix..

 

hope this helps

Share this post


Link to post
Share on other sites

I have different results for 2 different versions of OSC:

1. I know it's pretty old version, but have no idea where to check for its version

2. OSC 2.2, may be MS1

 

These 2 versions of OSC have different payflow link contributions, again, I have no knowledge of where they were originated from. Since I inherited the sites just 2 months ago.

 

for site#1: I've applied the change per Verisign recommended (I found it needs to be changed in checkout_verisign.php : perhaps somebody would know which contribution by the php file name) and it has been working O.K. so far.

 

for site#2: I applied the changed in \language\english\cc_via_verisign.php and I exactly the same problem as described on this thread -- no order info posted in mysql.

 

I'm a newbie, no experience, just want to share what I've seen as a result after making the changes on the 2 versions of OSC, perhaps someone could figure out what's gone wrong and come up with a fix for the problem sooner.

Share this post


Link to post
Share on other sites

Has anyone else found a contribution that works with the suggested new link (not the temporary one)?

Share this post


Link to post
Share on other sites
I work with VeriSign and the fix stated above is only a temporary fix.  VeriSign is in the process of removing our cold fusion servers and the URL listed above will only be available for a short timeframe.

 

At this time, we are unaware of the actual reason why the shopping cart is not working as we know of other OS Commerce sites using the new URL.

 

The current URL for Payflow Link should be https://payments.verisign.com/payflowlink.

 

If anyone else is having issues, I'll be happy to work with you directly to resolve them.

 

Todd

 

 

Does anyone know of a timeline on a permanent fix yet?

 

tia..

Share this post


Link to post
Share on other sites

Can anyone verify if older versions of OS Commerce use the CUSTID field for the SessionID? If so, this could be the problem with Silent Post. The CUSTID field is only 11 characters, but it seems older versions used it to pass a 40 char Session ID.

 

Current version passes the Session ID in the USER1 field, which is where it should be.

 

Todd

Share this post


Link to post
Share on other sites
Does anyone know of a timeline on a permanent fix yet? 

 

 

It doesn't look like there's going to be a permanent fix, at least not from VeriSign's end. Below is the text of an e-mail I received this morning from the VeriSign rep who's been addressing my trouble ticket. The big problem appears to be that the Payflow Link server will no longer follow redirects. My stores, and I presume all of those using the same Payflow Link module for osCommerce, have Payflow Link silent POSTing to "verisignreturn.php", which then redirects to checkout_process.php. Someone in the community is apparently going to have to rewrite the Payflow Link module so that it doesn't incorporate a redirect. I'll probably take a shot at it some time in the next few days if no one else beats me to it.

 

There may be other minor issues also playing into this problem, and so here's the text of the e-mail I got from my VeriSign rep, which (hopefully) contains a complete list of differences between new server and old.

 

I understand you've tried using our new Payflow Link service @

https://payments.verisign.com/payflowlink w/ osCommerce, and were having

difficulties with the Silent POST under the new service.

 

I also understand you were given a different URL that uses the old service

-- while that will work for the time being, please be aware that it is in

temporary operation only, and it *will* go away within the next two months.

We need to get you up and running on the new URL/service.

 

That said, here's a couple of significant differences to the new service:

 

1) HTTPS Silent POSTs *will* work, but you need to get rid of the port

specification in your URL. I.e. say 'https://me.com/silent.php' instead of

'https://me.com:443/silent.php'.

 

2) Silent POST scripts that issue redirects of any kind will *NOT* work any

longer -- no <META> tags, no 30x Status: headers, none of that. Proxied URLs

should work, but not redirects. Take a close look at your specific script to

see if it does anything in this regard.

 

3) The format of the new Silent POST is ever so slightly different in the

following ways:

 

a) it's still URL encoded, but spaces are now encoded as '+' rather

than '%20' -- no PHP script should have any problem with this.

 

B) there is one extra name-value pair coming back now, 'PONUM',

which unfortunately slipped through our documentation.

 

3b) *might* be a problem -- I have already seen at least one very fragile

Silent POST script that died when presented with a new name-value pair.

 

You might for now wish to create a new, testing-only Payflow Link account --

that way you can set up a second set or URLs to test on, leaving your public

site untouched until you're ready to switch.

Share this post


Link to post
Share on other sites

Eureka!

 

2) Silent POST scripts that issue redirects of any kind will *NOT* work any

longer -- no <META> tags, no 30x Status: headers, none of that. Proxied URLs

should work, but not redirects. Take a close look at your specific script to

see if it does anything in this regard.

 

For all you OSC 2.2 MS2 users using the 'Verisign PayFlow Link w/CSC new checkout process' contribution -- #2 from this email is the problem!

 

The file 'verisignreturn.php' collects the $_POST array and redirects the data to the 'checkout_process.php' page! Since redirects aren't allowed, this is a problem!

 

Here is the solution!

 

Open the file 'checkout_process.php'

At the top of the page paste the following code:

 

if($HTTP_POST_VARS['RESPMSG'] == 'Approved') {

    $HTTP_POST_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];
    $HTTP_GET_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];
    reset ($HTTP_POST_VARS);
    reset ($HTTP_GET_VARS);

}

 

BEFORE this line of code:

 

'include('includes/application_top.php');'

 

This will only record the order if Verisign approves the transaction.

 

For those of you who are collecting the Verisign ID to store and display with your OSC orders/invoices, you may paste the following code:

 

$_SESSION['verisign_ref'] = $HTTP_POST_VARS['PNREF'];

 

. . . after the include statement mentioned above.

 

Sessions are not started until that include is executed. If you don't know about this mod, please search the forums (rather than ask me about it) as there are a number of modifications to be made across the system.

 

FINALLY -- and this is important:

Change your 'Silent Post' URI from 'verisignreturn.php' to 'checkout_process.php'

 

DEVELOPERS PLEASE NOTE:

1) The above solution is a mod of a 'contribution,' (which are 'Use At Your Own Risk' anyway) and the OSC system. Make sure you make note of this in case you update OSC!

2) Swap the PHP syntax where neccessary -- specifically, some PHP servers may require using the $_POST / $_GET super globals instead of $HTTP_POST_VARS / $HTTP_GET_VARS arrays

 

 

I sure hope this solves problems for folks!

 

lata,

shakes


<>< be a fisher of men.

Share this post


Link to post
Share on other sites

Thanks, the fix worked great for me once I changed the super globals. Here's the code for those that have to use it. It might save you 30 seconds.

 

if($_POST['RESPMSG'] == 'Approved') {

   $_POST[$_POST['USER1']] = $_POST['USER2'];
   $_GET[$_POST['USER1']] = $_POST['USER2'];
   reset ($_POST);
   reset ($_GET);

}

Share this post


Link to post
Share on other sites
Thanks, the fix worked great for me once I changed the super globals.  Here's the code for those that have to use it.  It might save you 30 seconds.

 

if($_POST['RESPMSG'] == 'Approved') {

? ?$_POST[$_POST['USER1']] = $_POST['USER2'];
? ?$_GET[$_POST['USER1']] = $_POST['USER2'];
? ?reset ($_POST);
? ?reset ($_GET);

}

------------------------------------------------------------------

Where do you change the super globals?

Share this post


Link to post
Share on other sites
------------------------------------------------------------------

Where do you change the super globals?

 

Change this code (from my previous post):

 

if($HTTP_POST_VARS['RESPMSG'] == 'Approved') {

? ? $HTTP_POST_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];
? ? $HTTP_GET_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];
? ? reset ($HTTP_POST_VARS);
? ? reset ($HTTP_GET_VARS);

}

 

To this code (from DrumrLC's post):

 

if($_POST['RESPMSG'] == 'Approved') {

? ?$_POST[$_POST['USER1']] = $_POST['USER2'];
? ?$_GET[$_POST['USER1']] = $_POST['USER2'];
? ?reset ($_POST);
? ?reset ($_GET);

}

 

You should read a PHP manual. Check this link out: PHP: Predefined variables - Manual


<>< be a fisher of men.

Share this post


Link to post
Share on other sites
Change this code (from my previous post):

 

if($HTTP_POST_VARS['RESPMSG'] == 'Approved') {

? ? $HTTP_POST_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];
? ? $HTTP_GET_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];
? ? reset ($HTTP_POST_VARS);
? ? reset ($HTTP_GET_VARS);

}

 

To this code (from DrumrLC's post):

 

if($_POST['RESPMSG'] == 'Approved') {

? ?$_POST[$_POST['USER1']] = $_POST['USER2'];
? ?$_GET[$_POST['USER1']] = $_POST['USER2'];
? ?reset ($_POST);
? ?reset ($_GET);

}

 

You should read a PHP manual. Check this link out: PHP: Predefined variables - Manual

-------------------------------------------------------------

 

The reason I asked was that, the code below:

 

$HTTP_POST_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];

$HTTP_GET_VARS[$HTTP_POST_VARS['USER1']] = $HTTP_POST_VARS['USER2'];

reset ($HTTP_POST_VARS);

reset ($HTTP_GET_VARS);

 

was not in my checkout_process.php but in verisignreturn.php without the IF statement.

Share this post


Link to post
Share on other sites

I made the change in verisignreturn.php but it doesn't work for me. I added the if($HTTP_POST_VARS['RESPMSG'] == 'Approved') statement with no avail. Any ideas? Thanks in advance.

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  

×