Delicious Bookmark this on Delicious Share on Facebook SlashdotSlashdot It! Digg! Digg

PHP : Function Reference : Verisign Payflow Pro Functions

Verisign Payflow Pro Functions


This extension allows you to process credit cards and other financial transactions using Verisign Payment Services, formerly known as Signio (»

when using these functions, you may omit calls to pfpro_init() and pfpro_cleanup() as this extension will do so automatically if required. However the functions are still available in case you are processing a number of transactions and require fine control over the library. You may perform any number of transactions using pfpro_process() between the two.

These functions were added in PHP 4.0.2.


These functions only provide a link to Verisign Payment Services. Be sure to read the Payflow Pro Developers Guide for full details of the required parameters.


This extension has been moved to the » PECL repository and is no longer bundled with PHP as of PHP 5.1.0.


This extension is not available on Windows platforms.


You will require the appropriate SDK for your platform, which may be downloaded » from within the manager interface once you have registered.

Once you have downloaded the SDK you should copy the files from the lib directory of the distribution. Copy the header file pfpro.h to /usr/local/include and the library file to /usr/local/lib.

Alternatively, you can extract the tarball from Verisign in one location, and reference it during build configuration with the --with-pfpro[=DIR] option:

Example 2608. Explicit Configuration

tar -zxf pfpro_sunsparc.tar.gz -C /usr/local/

./configure --with-pfpro=/usr/local/verisign/payflowpro/sunsparc


The last portion of the path specified in the example above, in this case sunsparc, will vary based on which architecture your Verisign SDK was built for.


These functions are only available if PHP has been compiled with the --with-pfpro[=DIR] option.


If you are planing to use this extension along with the OpenSSL extension or with ModSSL, you should compile this extension as shared: --with-pfpro=shared,/usr/local.

Runtime Configuration

The behaviour of these functions is affected by settings in php.ini.

Table 329. Verisign Payflow Pro configuration options

Name Default Changeable Changelog
pfpro.defaulthost/PFPRO_VERSION < 3 "" PHP_INI_ALL  
pfpro.defaulthost "" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.
pfpro.defaultport "443" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.
pfpro.defaulttimeout "30" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.
pfpro.proxyaddress "" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.
pfpro.proxyport "" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.
pfpro.proxylogon "" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.
pfpro.proxypassword "" PHP_INI_ALL Available since PHP 4.0.2. Removed in PHP 5.1.0.

For further details and definitions of the PHP_INI_* constants, see the Appendix I, php.ini directives.

Resource Types

This extension has no resource types defined.

Predefined Constants

This extension has no constants defined.

Table of Contents

pfpro_cleanup — Shuts down the Payflow Pro library
pfpro_init — Initialises the Payflow Pro library
pfpro_process_raw — Process a raw transaction with Payflow Pro
pfpro_process — Process a transaction with Payflow Pro
pfpro_version — Returns the version of the Payflow Pro software

Code Examples / Notes » ref.pfpro


[Editors Note:
This is a workaround for Windows users ]
You can download the complete and files from my FTP site.  They are WinZip'd.


Zend has a nice tutorial titled "Accepting payments using Verisign's Payflow Pro" at
R. Rajesh Jeba Anbiah


You might want to check the CC number for LUHN checksum before submitting the actual transaction.
function luhncheck($number) {
   $l = strlen($number);
   for ($i=0; $i<$l; $i++) {
       $q = substr($number,$l-$i-1,1)*($i%2+1);
       $r += ($q%10)+(int)($q/10);
   return !($r%10);
returns true if card number is valid, $number is a string with digits only (no dashes or spaces).
Before LUHN check, you can verify the card no. prefix and the number length, here's what they should be:
Visa: 4..., 16 digits
MC: 51-55..., 16 digits
Amex: 34... or 37..., 15 digits
Discover: 6011..., 16 digits.
Diners/CBlanche: 300-305..., 36..., 38..., 14 digits
JCB: 3..., 16 digits
JCB: 2131 or 1800, 15 digits
enRoute does not do LUHN verification.
See details at
Dimitri Tarassenko


To expand on Michael's instructions on getting Payflow Pro working as a loadable module under FreeBSD, you can do the same thing under RedHat Enterprise and Fedora:
1) Drop pfpro.h and into their respective directories per Requirements above.
2) Install the RedHat Enterprise or Fedora PHP SRPM.
3) Add "--with-pfpro=shared,/usr/local \" to the "%configure \" line in php.spec.
4) Run rpmbuild -bc php.spec
5) Copy /usr/src/redhat/BUILD/php-X.X.X/build-apache/modules/ to /usr/lib/php4.
6) Add "" to /etc/php.d/pfpro.ini using the other .ini files as templates.


This link discusses the Payflow Pro message protocol, which is embedded in the (now unsupported) Linux SDK.  It provides a PHP example for doing without the SDK:

todd s @ paypal

The package that this article refers to is no longer available as it has been deprecated due to upcoming expiration of the certificate that the package relies on.
PayPal now allows you the ability to post directly to our servers without the need of an SDK using standard HTTPS services.  
For more information see the posting at regarding the HTTPS Interface.

20-nov-2003 01:00

Redhat 9 compile problems.
Redhat 9's version of glibc will cause compile to fail. It seems that for localization reasons RH started using __ctype_b_loc instead of __ctype_b, which is what payflow is expecting. Not that I know what this means, but it's attested to at, if you search for "redhat 9", and there is a bug at about it. Redhat is not going to fix it, so you have to get the beta sdk from verisign. Or use something besides Redhat 9.


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.


jho8344, two things:
1) No such dll exists, nor to my knowledge ever has, because
2) PHP has built-in support for COM, thus you don't need it.
If you're using PHP on Windows, install VeriSign's Payflow Pro COM object per their normal directions, and then use that COM object directly via PHP. You can do so (roughly) like this:
/* Create pfCOM Object */
$pfpro_client = new COM('PFProCOMControl.PFProCOMControl.1');

/* Process Transaction */
$pfpro_context = $pfpro_client->CreateContext($url, $port, $timeout, $proxy_url, $proxy_port, $proxy_logon, $proxy_password);
@$result = $pfpro_client->SubmitTransaction($pfpro_context, $parmsString, strlen($parmsString));
/* Destroy Context */
Note that's strictly off the top of my head; not actually guaranteed to work out of the box. I don't run PHP on Windows, so I can't really test it for you. But give it a go, and report back here if it works for you.


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.


If you are on a shared host, and you want to use Payflow Pro in PHP, odds are you're not going to be able to use this extension.
Instead, you can use the exec() (see function to call the Payflow Pro binary. In order to do this, safe_mode must be *off*. Secondly, there are two potential security risks in doing this:
   1) You must make sure you escape/cleanup any user submitted data *before* you send it to the exec() function, or eventually some jerk will insert "; rm -rf *" in one of your parameters, and kill your server.
   2) The shell processes spawned by exec() will be visible via a ps listing, along with their parameters (which is to say, CC numbers. If nobody on the shared host has commandline access, or the host prevents users from seeing other users' processes, then this may not be a big deal.
OK, if you're willing and able to deal with the above, then what you do next is:
1) Get a copy of the appropriate SDK from VeriSign Manager (
2) Transfer the following 3 files from the SDK to your host:
a) verisign/payflowpro/<platform>/bin/pfpro
b) verisign/payflowpro/<platform>/lib/
c) verisign/payflowpro/<platform>/certs/f73e89fd.0
It doesn't matter where you put them under your directory, just make sure you know the *full* absolute path to them. Make sure that the files are fully *readable* and *executable* on the system. If you use FTP to transfer the files, please make sure to transfer in BIN mode, and not ASCII.
3) Edit the code below to fill in the appropriate values for $user, $vendor, $partner, $pwd, $binary, $library, and the path specified for PFPRO_CERT_PATH, and...
4) adapt as necessary.
// This script shows:
//    a) how to use the Payflow Pro commandline binary to process
//       a transaction via PHP's system call, and
//    b) the setup necessary to make sure that it will work
 // Adjust these for your actual login parameters
 $user           = "myuser";
 $vendor         = "myvendor";
 $partner        = "VeriSign";
 $pwd            = "mysecret";
 $host = "";
 $port = "443";
 // Adjust these next two paths appropriately; i.e. where did
 // you actually put these two files?
       $binary         = '/usr/local/bin/pfpro';
       $library        = '/usr/local/lib/';
       $newld          = dirname($library);
       // this is necessary to prevent RESULT=-31 errors; make sure
 // it's a *directory* that contains the cert file that came
 // with the SDK, and *don't* put a trailing slash on it

       // This next chunk of stuff assumes you're having linker issues, and
       // attempts to fix or work around them.
       // Now, let's fix the linker path:
       $original_ld_path = getenv("LD_LIBRARY_PATH");
       $newld .= ":$original_path";
       // having set the linker to find the library, now call the binary:
       $cmd = "\"TRXTYPE=S&TENDER=C&PWD=$pwd&USER=$user&VENDOR=$vendor";
       $cmd .= "&PARTNER=$partner&ACCT=4222222222222&EXPDATE=1209&AMT=14.42";
       $cmd .= "&INVNUM=1234567890&STREET=5199 JOHNSON&ZIP=94588\" 30";
       $result = exec("$binary $host $port $cmd", $result_array, $exit_value);
       $valArray = explode('&', $result);
       foreach($valArray as $val) {
               $valArray2 = explode('=', $val);
               $pfpro[$valArray2[0]] = $valArray2[1];
       // To look at the array structure
       // This should be equal to the RESULT that came back. If you
 // get no result string back, but the exit_value here is 126 or 127,
 // you've got linker or permission problems.
       echo "the exit value of the system call to pfpro was $exit_value";


if you are having problems compiling pfpro in freebsd 4.X, it is probably because of its braindead thread library.
Just install linuxthreads from the ports, set  LDFLAGS="-I/usr/local/include/pthread/linuxthreads -L/usr/local/lib -llthread -llgcc_r"
and then do as instructed in the other posts here.


I've just spent a morning looking for the beta SDK (as per the
above requirements) to no avail.  Then I found the following
on Verisign's website --
Q:   Where can I find the Beta for apache/mod_ssl/ php beta
download for Payflow Pro?
A:   Our current UNIX - SDKs have this functionality built-in.
In any case, there _is_ a known "incompatibility between the
SSL toolkit used for mod_ssl and that used by Payflow Pro."
Here's a link to the resolution from the Verisign
knowledgebase --


I have been trying to compile PHP with PayFlow Pro support on FreeBSD 4.8-STABLE and I kept receiving this error:
The pfpro extension requires version 2 or 3 of the SDK
Looking at the config.log I found that the config test code was failing to compile with these errors:
/usr/local/lib/ undefined reference to `pthread_mutex_unlock'
/usr/local/lib/ undefined reference to `pthread_self'
/usr/local/lib/ undefined reference to `pthread_mutex_destroy'
/usr/local/lib/ undefined reference to `pthread_mutex_lock'
/usr/local/lib/ undefined reference to `pthread_mutex_init'
With a little further digging, I determined the problem to be with the configure script.  The configure script is smart enough to test for POSIX threads, and to add the appropriate compile flag when building the PHP distribution, but it isn't smart enough to use that flag when compiling the config test code.  The pfp library requires the threads flag to be set.
This will kludge your configure script into working, so that you can get past the bogus error encountered by the pre-compile tests:
perl -pi.bak -e  \
's/LIBS="-lpfpro/LIBS="-pthread -lpfpro/g' \
I broke it into three lines so that it doesn't wrap unhappily in this form.
NOTE:  This is the appropriate flag for FreeBSD 4.8.  Your system may require a different flag.
It is a kludge fix, and I'm not proud of it, but I have to have this damn thing working by morning.  :)
-Chris Knight


I finally got pfpro to work as an apache module. After following the advice above it still did not work. (Apache would not start with both the libssl and libphp4 added).
The solution is in the order in which apache web server loads modules. Review your httpd.conf file  typically located in /etc/httpd/conf. The loading of and is important. The must be loaded before libphp4.


I can confirm that the undefined references (__ctype_b) bug referred to in the previous note is indeed fixed by using the Versign SDK for Redhat 9.
It all works fine on Redhat 9 + glibc 2.3.2 + Apache 2.0.48 + PHP 4.3.4.
Just FYI, this is all because __ctype_b has been replaced by __ctype_b_loc in glibc 2.3. Here's the quote from Bug #91290 on "For __ctype_b*, the decision to replace it by __ctype_b_loc etc. and disallow any new links against the old type were made because __ctype_b* does not work together with uselocale(3).These days, uselocale(3) is used quite often e.g. in libstdc++, so it is very bad idea to keep using __ctype_b etc." In a nutshell this means that old libraries linked against glibc < 2.3 should be rebuilt with glibc >= 2.3 if they use any of these symbols. This Verisign has done with the RH9 version of the SDK.


Here's a way to do recurring billing without needing to store credit card data, and without needing the recurring billing add-on service:
1. Enable reference transactions in VeriSign Manager
2. Generate the first "sale" transaction, or if the first payment will be in the future, generate a $1 "authorization" transaction to validate the card and generate a pnref.
3. Create a billing schedule in a database table, and store the pnref.
4. Create and run a daily CRON job which submits reference transactions for any transaction matching that day's billing date.  The pnref in the reference transaction will allow the old card info to be used, even though you didn't store any card info.
Optionally also store the card's expiration date, and make the CRON job smart enough not to submit transactions with expiration dates in the past.
I suggest storing the user's pnref in a separate table (e.g., user_preferred_payment_method), and let the user easily update his/her preferred payment method at any time (new $1 auth to validate the new card and generate a new pnref).
Reference transactions are a wonderful thing and let CRON take care of your recurring billing, without needing to store the card data or subscribe to additional features.
Hope this is helpful to someone...


Here's a more complete example using COM
$objCOM = new COM("PFProCOMControl.PFProCOMControl.1");
$parmList = "TRXTYPE=S&TENDER=C&ZIP=12345&COMMENT2=PHP/COM Test Transaction";
$parmList .= "&ACCT=" . $cardNum;
$parmList .= "&PWD=" . $userPW;
$parmList .= "&USER=" . $userId;
$parmList .= "&VENDOR=" . $vendorId;
$parmList .= "&PARTNER=" . $partnerId;
$parmList .= "&EXPDATE=" . $cardExp;
$parmList .= "&AMT=" . $amount;
$ctx1 = $objCOM->CreateContext("", 443, 30, "", 0, "", "");
$result = $objCOM->SubmitTransaction($ctx1, $parmList, strlen($parmList));
$valArray = explode('&', $result);
foreach($valArray as $val)
   $valArray2 = explode('=', $val);
   $response[$valArray2[0]] = $valArray2[1];
if ($response['RESULT'] == 0)
   echo "<b>Success!</b>
   echo "<b>Failure!</b>
foreach($response as $name => $value)
   echo "<b>$name</b> = $value


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


For those of you looking to install pfpro functionality without having to rebuild PHP, bear in mind that you can create a dso, which is especially useful for Red Hat Enterprise or other situations where you want to be able to automagically receive binary updates (such as Debian's apt-get).
The procedure for creating a dso on Red Hat is:
install php-devel from RPM, and get php source:
up2date --get-source php
rpm -i /var/spool/up2date/php-X.X.X.src.rpm
cd /usr/src/redhat/SOURCES
gunzip php-X.X.X.tar.gz
tar xvf php-X.X.X.tar
cd php-X.X.X/ext/pfpro
make install
Add the line:;
to /etc/php.d/pfpro.ini
and issue apachectl restart. Voila!


For everyone who needs this to work on FreeBSD 4.8 with php 4.3.3 (and for me next time i have to do it), please perform the following:
unpack the tar.gz file for php.
cd php-4.3.3/
and run the following  (as mentioned below):
perl -pi.bak -e  \
's/LIBS="-lpfpro/LIBS="-pthread -lpfpro/g' \
Then run your configure script to include --with-pfpro.
Edit your Makefile and find the "COMMON_FLAGS" line and add -pthread to the end of it.
then run make and make install.
Also be sure to recompile your apache to include -pthread:
unpack apache
run your configure script
edit the src/Makefile and find the "LIBS1" line and add -pthread to the end of it.
then run make and make install.
for php to load on freebsd 4.8 as an apache module with pfpro, you *MUST* compile apache with -pthread.


For 5.1.x it's a bit trickier.  The easiest thing to do is this:
cvs co pecl/pfpro                    
run phpize in the pecl/pfpro directory
then run './configure' --with-pfpro=/usr/local/verisign/payflowpro/linux
(or wherever your payflow SDK is)
then move modules/ to your extensions directory listed in your php.ini (I just made one called /usr/local/phpextensions).


Be careful about running the COM object under apache2 on windows.  VeriSign support told me there were race conditions in 3.08 and suggested I use 3.06.  That was fine with some older versions of apache/php (I got it working with 2.0.49 and 4.3.6) but new versions have problems even with that.


As you may have noticed - this extension is getting little to no attention.
In late 2005, PayPal bought PayFlow Pro from Verisign.  The official word is basically that if it still works for you, continue to use it, but there is no more support for the Linux binary nor the PHP extension that is built for it.
There are alternatives which you can find at
(link wrapped)
You can use SOAP, XML, or NVP (name/value pairs) with cURL to submit the credit card capture to a SSL url and receive authorization.
The XML is easy to build with PHP's DOM functions.
It's very likely that the pfpro extension will not build with PHP6 - so for migration planning you should probably have one of the methods above in place.


After weeks of searching and trying to install Payflow Pro on Red Hat Enterprise Linux 3, I finally was able to make it work. Naturally I was very hesitant to recompile my php configuration, but with a little help from redhat, and about 3 hours, it was installed. I'll try to outline the steps as best I can.
I'm running RedHat EL 3.0, php-4.3.2, apache 2.0.46.
Anyone running EL 3 is a member of the redhat network, so use up2date to download the latest php source rpm.
up2date --get-source php (this will download the source rpm into /var/spool/up2date)
rpm -i /var/spool/up2date/php-4.3.2 (or whatever version of php it gives you, installing this source rpm will not affect your current php configuration)
cd /usr/src/redhat/SPECS
rpmbuild -bp php.spec (unpack the sources and apply patches)
I had a couple of dependency requirements (imap-devel, unixODBC-devel; yours may vary; up2date 'whatever you need'; if you had to install dependant rpms, run rpmbuild -bp php.spec again)
vi php.spec (edit the spec file and include the --with-pfpro)
on line 285 or 286, you'll see where the ./configure command is generated. Adjust any defaults as necessary, I didn't need to, and add --with-pfpro=[DIR]. Make sure to place this outside the if's, I placed mine before ifarch(%ix86).
If you followed the instructions above, and unpacked pfpro into /usr/local, you would add --with-pfpro=--with-pfpro=/usr/local/verisign/payflowpro/sunsparc, where my version was linuxrh9. I'm running modssl, my config was --with-pfpro=shared,/usr/local.
Make sure that you have followed's instructions and copied pfpro.h and to the appropriate directories.
Now that we've added our config line, build the rpm. You will get a compile error if you have the incorrect version of the SDK. RedHat EL users should have downloaded the SDK for RedHat 9.x.
rpmbuild -bb php.spec (this will take awhile)
**According to documentation on redhat, new versions of rpm added a feature which causes a build termination if it finds files not "intended" to be included in the package. Obviously, since we added pfpro, it wasn't intended to be there. To get around this do the follow:
Edit your php.spec file (same one from earlier), and include
%define _unpackaged_files_terminate_build       0
I added this as the second line under the comments, mine looks like this:
%{!?oracle:%define oracle 0}
%define _unpackaged_files_terminate_build       0
This will allow the build to continue with these unpackaged files.
5 minutes later, if no errors were returned, it should that it build a whole bunch of rpms, all related to php. Now lets install them.
Redhat recommeded uninstalling existing rpms and installing these new ones, as opposed to using rpm -Uvh. So, uninstall the cooresponding php rpms. If it complains about dependancies, use --nodeps. Now, install rpm -i your new ones. You can install them all on the same line if you'd like.
rpm -i php-4.x.x. php-imap-4.x. php-mysql-4.x.x
Done! Now to quote Sean from below:
5) Copy /usr/src/redhat/BUILD/php-X.X.X/build-apache/modules/ to /usr/lib/php4.
6) Add "" to /etc/php.d/pfpro.ini using the other .ini files as templates.
Restart apache, and you should now be able to invoke the Payflow Pro functions!


After upgrading my slackware system's glibc to 2.3.3 (which is the first version of glibc on slackware that does not include a __ctype compatibility patch) and spending far too much time trying to figure out why the configure script could not figure out I had version 3 of the payflow pro library, the simple solution was to download the "Linux (Redhat 9.x)" version of the payflow SDK because Verisign has linked this version of the library to the glibc 2.3.x version of the __ctype functions (which are of the form __ctype_xxx_loc instead of __ctype_xxx).  
You should avoid the "Linux - (libc6 / glibc2 / ELF kernels 2.0.36 and above)" version of the SDK unless you have a glibc version < 2.3.x.  
If you're having this problem, check your config.log for the following lines:
/usr/local/lib/ undefined reference to `__ctype_b'
/usr/local/lib/ undefined reference to `__ctype_tolower'
You can also run the following command to find out which version of the __ctype functions the library was linked to:
readelf -s /usr/local/lib/ | grep ctype


After searching high and low for a way to get payflow pro to work with my existing servers (other than calling the pfpro binary), I found there was a way I could get it installed on my freebsd apache-mod_ssl servers. I did it via cgi version of php.
1. put freebsd version of, and pfpro.h in one place.
   I chose /usr/local/lib/.
2. download the last version of php.
./configure                              \
--prefix=/usr/local/php                  \
--with-config-file-path=/usr/local/php   \
--with-pfpro=shared,/usr/local/lib/      \
--enable-discard-path                    \
--with-mcrypt=/usr/local                 \
--with-mhash=/usr/local                  \
--with-mysql=/usr/local                  \
--with-expat-dir=/usr/local              \
--enable-wddx                            \
make && make install ..
copy php.ini-dist to your prefix'd location.
edit the safe modes and base directories and any other
security precautions you need.
I also put a link in /usr/bin/ to php so the paths would work.
In your php file you will have to edit the loadable modules directory.
mine ended up being :
browse down to the loadable extentions and add:
Open up your httpd.conf add:
AddHandler cgi-script xphp
to a virtual host Directory or your cgi-bin:
I used xphp but you can use what you like for a file extention.
You can create a directory like /auth/ but then you will have to put a Options ExecCGI on that folder in order to execute the script.
create a test.xphp file and put a #!/pathto/php before the <?
phpinfo(); ?>
9. Restart apache to load the Directory directives, and open a browser and browse to the file.  If you see any headers on the top of the page, check your error log. if all goes smoothly you should'nt see any errors in the httpd-error_log. I like to tail -f http-error_log in one console and browse it in real time.
10. create a payflowpro.php in the same manner.
make sure you put a: putenv("PFPRO_CERT_PATH=/pathto/certs");  
and try the pfpro_init(); function. if the function does'nt exist it will fail, which means you have to go back and check stuff for errors.
Warning: This is the way I found to get the job integrated. It may or may not work on all freebsd systems. Also keep in mind that the cgi version of the php scripts need to be chmod'd to the right permissions, safe_mode and disable functions that are not being used.  
It may not be the best way, but at least you still have access to the tools that php has build in.
If I missed something big here let me know.


A comment on the below notes regarding compilation on FreeBSD... to bring this up-to-date:
It seems Verisign is up to version 3.06 as of 3 Nov 2003, and at least on FreeBSD 5.1-RELEASE no special actions are necessary to get these functions to compile properly on PHP 4.3.3 or later (also tried on 4.3.4).  I used the listed notes above (download and copy the two files in place, add --with-pfpro=/usr/local to the ./configure options, and off you go) and the module compiled, installed, and ran just fine on a standard port-built apache server.  So if you are running FreeBSD 5.1 or later and have the updated Verisign and PHP code, you should have no problems.

Change Language

Follow Navioo On Twitter
.NET Functions
Apache-specific Functions
Alternative PHP Cache
Advanced PHP debugger
Array Functions
Aspell functions [deprecated]
BBCode Functions
BCMath Arbitrary Precision Mathematics Functions
PHP bytecode Compiler
Bzip2 Compression Functions
Calendar Functions
CCVS API Functions [deprecated]
Class/Object Functions
Classkit Functions
ClibPDF Functions [deprecated]
COM and .Net (Windows)
Crack Functions
Character Type Functions
Cybercash Payment Functions
Credit Mutuel CyberMUT functions
Cyrus IMAP administration Functions
Date and Time Functions
DB++ Functions
Database (dbm-style) Abstraction Layer Functions
dBase Functions
DBM Functions [deprecated]
dbx Functions
Direct IO Functions
Directory Functions
DOM Functions
DOM XML Functions
enchant Functions
Error Handling and Logging Functions
Exif Functions
Expect Functions
File Alteration Monitor Functions
Forms Data Format Functions
Fileinfo Functions
filePro Functions
Filesystem Functions
Filter Functions
Firebird/InterBase Functions
Firebird/Interbase Functions (PDO_FIREBIRD)
FriBiDi Functions
FrontBase Functions
FTP Functions
Function Handling Functions
GeoIP Functions
Gettext Functions
GMP Functions
gnupg Functions
Haru PDF Functions
hash Functions
Hyperwave Functions
Hyperwave API Functions
i18n Functions
IBM Functions (PDO_IBM)
iconv Functions
ID3 Functions
IIS Administration Functions
Image Functions
Imagick Image Library
Informix Functions
Informix Functions (PDO_INFORMIX)
Ingres II Functions
IRC Gateway Functions
PHP / Java Integration
JSON Functions
LDAP Functions
libxml Functions
Lotus Notes Functions
LZF Functions
Mail Functions
Mailparse Functions
Mathematical Functions
MaxDB PHP Extension
MCAL Functions
Mcrypt Encryption Functions
MCVE (Monetra) Payment Functions
Memcache Functions
Mhash Functions
Mimetype Functions
Ming functions for Flash
Miscellaneous Functions
mnoGoSearch Functions
Microsoft SQL Server Functions
Microsoft SQL Server and Sybase Functions (PDO_DBLIB)
Mohawk Software Session Handler Functions
mSQL Functions
Multibyte String Functions
muscat Functions
MySQL Functions
MySQL Functions (PDO_MYSQL)
MySQL Improved Extension
Ncurses Terminal Screen Control Functions
Network Functions
Newt Functions
NSAPI-specific Functions
Object Aggregation/Composition Functions
Object property and method call overloading
Oracle Functions
ODBC Functions (Unified)
ODBC and DB2 Functions (PDO_ODBC)
OpenAL Audio Bindings
OpenSSL Functions
Oracle Functions [deprecated]
Oracle Functions (PDO_OCI)
Output Control Functions
Ovrimos SQL Functions
Paradox File Access
Parsekit Functions
Process Control Functions
Regular Expression Functions (Perl-Compatible)
PDF Functions
PDO Functions
Phar archive stream and classes
PHP Options&Information
POSIX Functions
Regular Expression Functions (POSIX Extended)
PostgreSQL Functions
PostgreSQL Functions (PDO_PGSQL)
Printer Functions
Program Execution Functions
PostScript document creation
Pspell Functions
qtdom Functions
Rar Functions
GNU Readline
GNU Recode Functions
RPM Header Reading Functions
runkit Functions
SAM - Simple Asynchronous Messaging
Satellite CORBA client extension [deprecated]
SCA Functions
SDO Functions
SDO XML Data Access Service Functions
SDO Relational Data Access Service Functions
SESAM Database Functions
PostgreSQL Session Save Handler
Session Handling Functions
Shared Memory Functions
SimpleXML functions
SNMP Functions
SOAP Functions
Socket Functions
Standard PHP Library (SPL) Functions
SQLite Functions
SQLite Functions (PDO_SQLITE)
Secure Shell2 Functions
Statistics Functions
Stream Functions
String Functions
Subversion Functions
Shockwave Flash Functions
Swish Functions
Sybase Functions
TCP Wrappers Functions
Tidy Functions
Tokenizer Functions
Unicode Functions
URL Functions
Variable Handling Functions
Verisign Payflow Pro Functions
vpopmail Functions
W32api Functions
WDDX Functions
win32ps Functions
win32service Functions
xattr Functions
xdiff Functions
XML Parser Functions
XML-RPC Functions
XMLReader functions
XMLWriter Functions
XSL functions
XSLT Functions
YAZ Functions
YP/NIS Functions
Zip File Functions
Zlib Compression Functions
eXTReMe Tracker