Provided by: interchange_5.7.7-2_amd64 
NAME
Vend::Payment::PayflowPro - Interchange support for PayPal Payflow Pro HTTPS POST
SYNOPSIS
&charge=payflowpro
or
[charge mode=payflowpro param1=value1 param2=value2]
PREREQUISITES
The following Perl modules:
LWP
Crypt::SSLeay
HTTP::Request
HTTP::Headers
OpenSSL
PayPal's Payflow Pro HTTPS POST does NOT require the proprietary binary-only shared
library that was used for the Verisign Payflow Pro service.
DESCRIPTION
The Vend::Payment::PayflowPro module implements the payflowpro() payment routine for use
with Interchange. It is compatible on a call level with the other Interchange payment
modules -- in theory (and even usually in practice) you could switch from a different
payment module to PayflowPro with a few configuration file changes.
To enable this module, place this directive in interchange.cfg:
Require module Vend::Payment::PayflowPro
This must be in interchange.cfg or a file included from it.
NOTE: Make sure CreditCardAuto is off (default in Interchange demos).
The mode can be named anything, but the "gateway" parameter must be set to "payflowpro".
To make it the default payment gateway for all credit card transactions in a specific
catalog, you can set in catalog.cfg:
Variable MV_PAYMENT_MODE payflowpro
It uses several of the standard settings from Interchange payment. Any time we speak of a
setting, it is obtained either first from the tag/call options, then from an Interchange
order Route named for the mode, then finally a default global payment variable. For
example, the "id" parameter would be specified by:
[charge mode=payflowpro id=YourPayflowProID]
or
Route payflowpro id YourPayflowProID
or with only Payflow Pro as a payment provider
Variable MV_PAYMENT_ID YourPayflowProID
The active settings are:
id Your account ID, supplied by PayPal when you sign up. Global parameter is
MV_PAYMENT_ID.
secret
Your account password, selected by you or provided by PayPal when you sign up. Global
parameter is MV_PAYMENT_SECRET.
partner
Your account partner, selected by you or provided by PayPal when you sign up. Global
parameter is MV_PAYMENT_PARTNER.
vendor
Your account vendor, selected by you or provided by PayPal when you sign up. Global
parameter is MV_PAYMENT_VENDOR.
transaction
The type of transaction to be run. Valid values are:
Interchange Payflow Pro
---------------- -----------------
sale S
auth A
credit C
void V
settle D (from previous A trans)
Default is "auth".
The following should rarely be used, as the supplied defaults are usually correct.
remap
This remaps the form variable names to the ones needed by PayPal. See the "Payment
Settings" heading in the Interchange documentation for use.
host
The payment gateway host to use, to override the default.
check_sub
Name of a Sub or GlobalSub to be called after the result hash has been received from
PayPal. A reference to the modifiable result hash is passed into the subroutine, and
it should return true (in the Perl truth sense) if its checks were successful, or
false if not. The transaction type is passed in as a second arg, if needed.
This can come in handy since, strangely, PayPal has no option to decline a charge when
AVS or CSC data come back negative.
If you want to fail based on a bad AVS check, make sure you're only doing an auth --
not a sale, or your customers would get charged on orders that fail the AVS check and
never get logged in your system!
Add the parameters like this:
Route payflowpro check_sub avs_check
This is a matching sample subroutine you could put in interchange.cfg:
GlobalSub <<EOR
sub avs_check {
my ($result) = @_;
my ($addr, $zip) = @{$result}{qw( AVSADDR AVSZIP )};
return 1 if $addr eq 'Y' or $zip eq 'Y';
return 1 if $addr eq 'X' and $zip eq 'X';
return 1 if $addr !~ /\S/ and $zip !~ /\S/;
$result->{RESULT} = 112;
$result->{RESPMSG} = "The billing address you entered does not match the cardholder's billing address";
return 0;
}
EOR
That would work equally well as a Sub in catalog.cfg. It will succeed if either the
address or zip is 'Y', or if both are unknown. If it fails, it sets the result code
and error message in the result hash using PayPal's own (otherwise unused) 112 result
code, meaning "Failed AVS check".
Of course you can use this sub to do any other post-processing you want as well.
Troubleshooting
Try the instructions above, then enable test mode. A test order should complete.
Then move to live mode and try a sale with the card number "4111 1111 1111 1111" and a
valid future expiration date. The sale should be denied, and the reason should be in [data
session payment_error].
If it doesn't work:
• Make sure you "Require"d the module in interchange.cfg:
Require module Vend::Payment::PayflowPro
• Check the error logs, both catalog and global.
• Make sure you set your account ID and secret properly.
• Try an order, then put this code in a page:
<pre>
[calcn]
my $string = $Tag->uneval( { ref => $Session->{payment_result} });
$string =~ s/{/{\n/;
$string =~ s/,/,\n/g;
return $string;
[/calcn]
</pre>
That should show what happened.
• If all else fails, consultants are available to help with integration for a fee. You
can find consultants by asking on the "interchange-biz@icdevgroup.org" mailing list.
NOTE
There is actually nothing in the package Vend::Payment::PayflowPro. It changes packages
to Vend::Payment and places things there.
AUTHORS
Tom Tucker <tom@ttucker.com>
Mark Johnson <mark@endpoint.com>
Jordan Adler
David Christensen <david@endpoint.com>
Cameron Prince <cameronbprince@yahoo.com>
Mike Heins <mike@perusion.com>
Jon Jensen <jon@endpoint.com>