LXXVII. Verisign Payflow Pro functions

You can always vfork (backticks, exec, whatever) to call the pfpro
executable.

The basic idea is that that is a dangerous and stupid way to use a product
for which an SDK is freely available. The problem is that Verisign's
(closed source) SDK uses its own SSL implementation that conflicts with
OpenSSL (and probably others) when it is linked into Apache. This is
crippling both to the usefulness of the SDK and hence that of this
module.

You are encouraged to contact Verisign and urge them to provide a better
SDK, an open-source SDK, or the implementation details so we can write our
own.

If you decide not to use the pfpro functions for any one of several reasons
and instead call the pfpro binary with the exec command please note that
you must use the putenv function to set the environment variable
PFPRO_CERT_PATH that is referred to in the PayFlowPro Developers Guide
(see page 12).  Otherwise verisign with always return a -31 error -
certificate not found.

Please also be aware that forking will allow any person with the access to
the ps command to potentially see ALL account information: user, password,
partner, credit card number, etc.

The preferred way to use the module is through the now-fixed extension.

[Ed Note:
If server is unavailable, file can be downloaded from

[email protected]]

You can download the complete php_pfpro.inc and php_pfpro_com.inc files
from my FTP site.  They are WinZip'd.

I was having problems with the PHP configuration recognizing that I had a
recent version of the PFPRO SDK.

I found a bug in the config.m4 file for the pfpro extension as follows -

***********

  PFPRO_VERSION3=`nm $PFPRO_LIB_DIR/$PFPRO_LIB | awk '{print $3}' | grep
^pfpro > /dev/null && echo 1 || echo 0`
  PFPRO_VERSION2=`nm $PFPRO_LIB_DIR/$PFPRO_LIB | awk '{print $3}' | grep
^PN > /dev/null && echo 1 || echo 0`

************

When I issued the above 'nm' statement from the UNIX command line, two
bugs were apparent: 1) the awk was looking at column 3, but should have
been looking at column 8 instead and 2) the caret in the grep statement
was causing the command to return a failure.

Here is the corrected syntax for the config.m4 file:
# Changed col to 8 from 3, removed caret from grep stmts
  PFPRO_VERSION3=`nm $PFPRO_LIB_DIR/$PFPRO_LIB | awk '{print $8}' | grep
pfpro > /dev/null && echo 1 || echo 0`
  PFPRO_VERSION2=`nm $PFPRO_LIB_DIR/$PFPRO_LIB | awk '{print $8}' | grep
PN > /dev/null && echo 1 || echo 0`

Once you've update the config.m4 file, you'll need to run ./buildconf
before running your configure statement.

Make it a point to run ./buildconf and make distclean before configuring
and building PHP.  It could save you a lot of heartache.

Hope this helps.

From Verisign's VPS support:

The Payflow Pro support in PHP must be configured/compiled as a shared
object. In order to enable Payflow Pro support in PHP as a shared object,
pass the following switch to the PHP ./configure script:

[root@localhost] # ./configure --with-pfpro=shared,/path/to/pfpro

The directory specified by /path/to/pfpro must contain *both* the
libpfpro.so and pfpro.h files included in the Payflow Pro SDK (usually in
the lib/ and/or bin/ subdirectories of the SDK), or the ./configure step
will fail. 
 
 
  Versions of PHP prior to 4.0.2 did not contain the pfpro support
functions. See 
for the latest stable version of PHP.

It appears to be impossible to use older versions of Apache in this sort
of setup. Version 1.3.12 or greater are known to work, 1.3.9 may work,
older versions reportedly do not work. See 
for the latest stable version of Apache.

The version of mod_ssl is closely tied to the version of Apache being
used; there are sometimes multiple versions of mod_ssl available for a
single version of Apache. See  for
the latest version of mod_ssl.