OSCOMMERCE SUPPORT CALL 702-453-3332

 

Help - Search - Members - Calendar
Full Version: Verisign Issues
osCommerce Community Support Forums > osCommerce Online Merchant v2.x > Contributions / Add-Ons > Payment Modules > Other
Fanny
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?
itf
QUOTE (Fanny @ Mar 16 2005, 11:22 AM)
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.
DrumrLC
QUOTE (itf @ Mar 16 2005, 05:00 PM)
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.
itf
QUOTE (DrumrLC @ Mar 16 2005, 01:45 PM)
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 -
tsieber
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
brinaf123
QUOTE (tsieber @ Mar 16 2005, 11:08 PM)
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
tsieber
QUOTE (brinaf123 @ Mar 16 2005, 04:22 PM)
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.
Fanny
QUOTE (itf @ Mar 16 2005, 10:25 PM)
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.
westkoast
We are having the same problem too. Any idea on when some kind of fix will come out?
prluv516
QUOTE (westkoast @ Mar 17 2005, 11:11 AM)
We are having the same problem too. Any idea on when some kind of fix will come out?
*


the URL has changed.
goto catalog/includes/payment/verisign.php

you will see the payflow url.......
change the url to...
https://payments.verisign.com/payflowlink

hope this helps smile.gif
prluv516
QUOTE (westkoast @ Mar 17 2005, 11:11 AM)
We are having the same problem too. Any idea on when some kind of fix will come out?
*


the URL has changed.
goto catalog/includes/payment/verisign.php (or where ever your payflow link php mod is)

you will see the payflow url.......
change the url to...
https://payments.verisign.com/payflowlink

hope this helps smile.gif
DrumrLC
QUOTE (prluv516 @ Mar 17 2005, 03:01 PM)
the URL has changed.
goto catalog/includes/payment/verisign.php (or where ever your payflow link php mod is)

you will see the payflow url.......
change the url to...
https://payments.verisign.com/payflowlink

hope this helps smile.gif
*



That URL isn't working for some of us. Which contribution are you using?
goshad
QUOTE (DrumrLC @ Mar 17 2005, 02:50 PM)
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..

QUOTE
$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
eeprete
We are having a similar issue. Hopefully hitting the CF server will be a good temp fix. Reading through some of the Verisign documentation shows an additional change for merchants using the Signio URL.

Not sure if anyone posted the PDF document, but here is the link:
http://www.verisign.com/support/payflow/li...vice_Announceme
nt.pdf
cngo
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.
DrumrLC
Has anyone else found a contribution that works with the suggested new link (not the temporary one)?
goshad
QUOTE (tsieber @ Mar 16 2005, 04:08 PM)
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..
tsieber
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
itf
QUOTE (goshad @ Mar 21 2005, 09:25 AM)
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.

QUOTE
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.

cool.gif 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.
javashakes
Eureka!

QUOTE
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:

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:

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:

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
DrumrLC
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.

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

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

    }
cngo
QUOTE (DrumrLC @ Mar 22 2005, 07:35 AM)
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.

CODE
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?
javashakes
QUOTE (cngo @ Mar 22 2005, 10:24 PM)
------------------------------------------------------------------
Where do you change the super globals?
*


Change this code (from my previous post):

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);

}


To this code (from DrumrLC's post):

CODE
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
cngo
QUOTE (javashakes @ Mar 22 2005, 08:16 PM)
Change this code (from my previous post):

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);

}


To this code (from DrumrLC's post):

CODE
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.
cngo
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.
javashakes
QUOTE (cngo @ Mar 24 2005, 03:22 PM)
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.
*



Please read my earlier post containing the solution -- it's the last post on page one of this thread -- it explains in detail what to do.
Met00
after making the changes about 50% of my transactions are now coming through. Should I turn off the silent post to verisignreturn.php? or should I change the silent post to the checkout_process.php?
redguy
I tried that but I am still loosing orders. Any other suggestions. Or products to consider rather than Payflow Link. I am thinking about Authorize.net. Any complaints?

QUOTE (Met00 @ Mar 26 2005, 04:11 AM)
after making the changes about 50% of my transactions are now coming through. Should I turn off the silent post to verisignreturn.php? or should I change the silent post to the checkout_process.php?
*
redguy
Am I really the only one having this problem?
muuyai
This fix works well. Nice job! It totally bypasses the redirect which a verisign rep informed me would no longer work.

QUOTE (javashakes @ Mar 21 2005, 06:26 PM)
Eureka!
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:

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:

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:

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
*
prluv516
great thread...im trying the fixes....
though i had a question....when running the transaction through verisign....is there away to get these fields filled for transaction info in verisign manager????

Item Description:
Tax Amount:
Ship Amount:

i looked into the Verisign.php...and there are no statements addressing those fields to get the info posted in verisign....but i dont know how to code sad.gif.
tsieber
This is a reminder that anyone who modifed the URL to https://cf.payflowlink.verisign.com/payflowlink.cfm that this URL is being removed from service on July 1, 2005.

The current URL is https://payments.verisign.com/payflowlink

For those that experienced any issues during the migration to the new URL, all known issues have been resolved. Please modify you code to point to the new URL.

Todd
Payment Services
VeriSign, Inc.

QUOTE (itf @ Mar 16 2005, 03:25 PM)
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 -
*
port7237
QUOTE (redguy @ Mar 29 2005, 04:47 PM)
Am I really the only one having this problem?
*



I'm trying to capture the PNREF into a mysql database. I'm using verisign's payflow pro in the code it sates " $GLOBALS['payflow_trans_id'] = $response['PNREF']; //you should pick this up in checkout_process and save it in the order" in payflowpro.php How do I do this?

I need some help please
RuKuS
QUOTE (javashakes @ Mar 21 2005, 06:26 PM) *
Eureka!
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:

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:

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:

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


This fixed worked perfectly for me, Thanks!!! biggrin.gif
webman48
Todd,

Is this the correct URL to use now ?


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 [url=https://payments.verisign.com/payflowlink]https://payments.verisign.com/payflowlink.

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

Todd
Tamara Lester
QUOTE (javashakes @ Mar 21 2005, 10:26 PM) *
Eureka!
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:

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:

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:

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



Hi,

I've poured through hundreds (probably) of solutions regarding this problem...yours being the latest. After implementing these changes, I still cannot get my cart to clear after an order is processed.

Do you have any current info?

Your help is most appreciated.

Tamara
krachico
Hi,

Please someone has any suggestion about this issue ?

Since now the new URL for sending a new PAYFLOW LINK Authorization is https://payflowlink.paypal.com I have done the change mentioned earlier in this post:

1) I have updated this line in my_catalog_root/includes/languages/english/modules/payment/cc_via_verisign.php :

from

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

to

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

2) I have also added these lines to my_catalog_root/checkout_process.php :

global $HTTP_POST_VARS,$HTTP_GET_VARS;

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

include('includes/application_top.php');

3) then because I want to record the verisign reference number in my database I have added this line :

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

after

include('includes/application_top.php');

4) I have logged to my https://manager.paypal.com account and made this change:

- selected 'Return URL Method' to 'POST'
- checked 'Silent POST URL' and set the URL to 'my_catalog_root/checkout_process.php'
- checked 'Force Silent Post Confirmation' and set 'Failed Silent Post Return URL' to 'my_catalog_root/checkout_process.php'

now when I placed a new order I got this message:

"Transaction declined!
Your transaction was approved! However, a communication error with the merchant's site occured.

The transaction has been voided, please contact the merchant."

It seems like osCommerce wasn't able to handle the silent post from the new PAYFLOW LINK server.

but of course step (3) which is another issue works fine.

Please if anyone has already fixed this issue would send the fix here.

Khaled Rachico
krachico
Hi Again,

In my previous post I said that the change suggested didn't work for me. Sorry it was a my mistake.

Now I tested it many times and believe me it works comme une merveille.

I want to add something :

If someone wants to have both normal post and silent post he can do that.

How ?

just go to the PAYFLOW Link configuration in https://manager.paypal.com and

1. do what I have done in step (4) from the previous post
2. set 'Return URL' to 'your_root_catalog/checkout_success.php' (it is checkout_success.php (or any other page) but avoid checkout_process.php because you don't want to submit the same order twice especially when it is a virtual product like a PIN number which of course would make your customer very happy but not you)

Here I would like to thank all osCommerce contributors, especially osCommerce Team and many others like Rahman and Silencer for their wonderful 'Virtual Unique Products' contribution.

Good luck
Khaled Rachico
krachico
Hi,

I have forgot to mention something in my previous post :

- For now when you go to your https://manager.paypal.com account to set your PAYFLOW LINK configuration don't check 'Force Silent Post Confirmation' because if you check it your customer will get this message :

"Transaction declined!
Your transaction was approved! However, a communication error with the merchant's site occurred.

The transaction has been voided, please contact the merchant."

I noticed that even though the error message 'Transaction declined' was generated the order will still be sent to your customer of course only when the CC is valid.

I think this option in conjunction with Silent POST would be a very interesting option since it will adds more robustness to your payment process by charging your customer only when your web store has confirmed to PAYFLOW LINK that it has received the Silent Post data.

I wish someone could work on this issue so osCommerce will be able to send back a confirmation to PAYFLOW LINK server once it receives a silent post data.

Khaled Rachico
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.