Vend::Payment::PaypalExpress(3pm)
NAME
Vend::Payment::PaypalExpress - Interchange Paypal Express Payments
Module
PREREQUISITES
- SOAP::Lite
XML::Parser
MIME::Base64
URI
libwww-perl
Crypt::SSLeay
IO::Socket::SSL (version 0.97 until 0.99x is fixed for the "illegal seek" error, or a later one that works) - Test for current installations with: perl -MSOAP::Lite -e 'print "It
works\n"'
DESCRIPTION
The Vend::Payment::PaypalExpress module implements the paypalexpress()
routine for use with Interchange.
#=========================
SYNOPSIS
Quick start:
Place this module in <ic_root>/lib/Vend/Payment, and call it in
<ic_root>/interchange.cfg with Require module
Vend::Payment::PaypalExpress. Ensure that your perl installation
contains the modules listed above and their pre-requisites.
Logon to your Paypal Business (not Personal) account and go to
'Profile' -> 'API access' -> 'Request API Credentials' -> 'Signature'.
This will generate a user id, password and signature.
Add to catalog.cfg all marked 'required', optionally the others: Route
paypalexpress id xxx (required_ Route paypalexpress password xxx
(required) Route paypalexpress signature xxx (required: use the
3-token system, not the certificate system at Paypal) Route
paypalexpress returnurl your_full_URL/paypalgetrequest (required) Route
paypalexpress cancelurl your_full_URL/your_cancellation_page (required)
Route paypalexpress host api-3t.sandbox.paypal.com (for testing)
Route paypalexpress host api-3t.paypal.com (required: live host, one
of this or the above but not both) Route paypalexpress currency
EUR|GBP|USD|CAD|AUD (optional, defaults to USD) Route paypalexpress
pagestyle (optional, set up at Paypal) Route paypalexpress
paymentaction Sale (optional, defaults to 'Sale') Route paypalexpress
headerimg 'secure URL' (optional, though must be served from a secure
URL if used)
Optionally, you may set the return URL in the page as <input
type=hidden name=returnurl value=your_url>, and similarly the cancelurl
may be set in the page.
To have Paypal co-operate with your normal payment service provider, eg
Authorizenet, do the following:
Leave the MV_PAYMENT_MODE variable in catalog.cfg and
products/variable.txt set to your normal payment processor.
Add to etc/profiles.order: __NAME__ paypalexpress
__COMMON_ORDER_PROFILE__ &fatal = yes email=required email=email
&set=mv_payment PaypalExpress &set=psp Paypal &set=mv_payment_route
paypalexpress &final = yes &setcheck = payment_method paypalexpress
__END__ or, if you want to use Paypal as a 'Buy now' button without
taking any customer details, then omit the __COMMON_ORDER_PROFILE__ and
the two 'email=...' lines above.
Within the 'credit_card' section of etc/profiles.order leave
"MV_PAYMENT_MODE" as set, and add &set=psp __MV_PAYMENT_PSP__
&set=mv_payment_route authorizenet (or your preferred gateway instead
of authorizenet) as the last entries in the section.
and then add Variable MV_PAYMENT_PSP "foo" to catalog.cfg, where "foo"
is the name of your gateway or acquirer, formatted as you want it to
appear on the receipt. Eg, "Bank of America" (rather than boa),
"AuthorizeNet" (rather than authorizenet).
In etc/log_transction, immediately after the [elsif variable
MV_PAYMENT_MODE] [calc] insert this line: undef
$Session->{payment_result}{MStatus};
and leave [elsif variable MV_PAYMENT_MODE] as set (contrary to previous
revisions of this document) but within the same section change the
following two instances of [var MV_PAYMENT_MODE] to [value
mv_payment_route]. In particular, the setting inside the [charge
route="..] line will specify which payment processor is used for each
particular case, and you need to further modify this line so that it
ends up like this: [tmp name="charge_succeed"][charge
route="[value mv_payment_route]" pprequest="dorequest" amount="[scratch
tmp_remaining]" order_id="[value mv_transaction_id]"][/tmp] If the
value of 'mv_payment_route' is set to 'paypalexpress', then this is the
one that is run. It is only called via log_transaction after the
customer has returned from Paypal and clicks the 'final' pay button,
hence this is where the final 'pprequest=dorequest' value is sent.
Add into the end of the "[import table=transactions type=LINE
continue=NOTES no-commit=1]" section of etc/log_transaction:
psp: [value psp] pptransactionid:
[calc]$Session->{payment_result}{TransactionID}[/calc]
pprefundtransactionid:
[calc]$Session->{payment_result}{RefundTransactionID}[/calc]
ppcorrelationid:
[calc]$Session->{payment_result}{CorrelationID};[/calc] pppayerstatus:
[value payerstatus] ppaddressstatus: [value address_status]
and add these 6 new columns into your transactions table as type
varchar(256). You will have records of which transactions went through
which payment service providers, as well as Paypal's returned IDs. The
CorrelationID is the one you need in any dispute with them. The
payerstatus and addressstatus results may be useful in the order
fulfillment process.
Add these lines into the body of the 'submit' button that sends the
customer to Paypal.
[run-profile name=paypalexpress]
[if type=explicit compare="[error all=1 show_var=1 keep=1]"]
mv_nextpage=ord/checkout
[/if]
[charge route="paypalexpress" pprequest="setrequest"]
mv_todo=return
Create a page 'ord/paypalgetrequest.html', and make it the target of
the returnURL from Paypal: [charge route="paypalexpress"
pprequest="getrequest"] [bounce href="[area ord/paypalcheckout]"]
Create a page 'paypalcheckout.html' in the pages/ord folder. This
should display just the basket and address or whatever you choose for
the final pages, plus an IC button with:
mv_order_profile=paypalexpress mv_todo=submit in the
body part as the submit button to finalise the order. 'dorequest' is
set in log_transaction.
You may then use PaypalExpress for any transaction where the
'mv_order_profile' is set to paypalexpress but still use the
"credit_card" 'mv_order_profile' for other transactions, eg for
Authorizenet. Of course, if PaypalExpress is to be your only payment
method, then simply add: Variable MV_PAYMENT_MODE paypalexpress to
catalog.cfg just before the paypalexpress Route entries, and this route
will be the default.
Note that because Paypal do not recognise UK as a country, only GB, you
need to set up shipping in your country.txt for GB as well as UK. Note
also that Paypal do not return the customer's telephone number by
default, so you may need to adjust your order profiles to compensate.
Also note that Paypal requires the user to have cookies enabled, and if
they're not will return an error page with no indication of the real
problem. You may want to warn users of this.
The flow is: the first button for Paypal sends a request to Paypal to
initialise the transaction and gets a token back in return. If Paypal
fails to send back a token, then the module refreshes that page with an
error message suggesting that the customer should use your normal
payment service provider and shows the cards that you accept. Once the
token is read, then your customer is taken to Paypal to login and
choose his payment method. Once that is done, he returns to us and hits
the 'paypalgetrequest' page. This gets his full address as held by
Paypal, bounces to the final 'paypalcheckout' page and populates the
form with his address details. If you have both shipping and billing
forms on that page, the shipping address will be populated by default
but you may force the billing form to be populated instead by sending
<input type=hidden name=pp_use_billing_address value=1> at the initial
stage. Then the customer clicks the final 'pay now' button and the
transaction is done.
Options that may be set either in the route or in the page:
* reqconfirmshipping - this specifies that a Paypal customer must have
his address 'confirmed'
* addressoverride - this specifies that you will ship only to the
address IC has on file (including
the name and email); your customer needs to login to IC first before
going to Paypal
* use_billing_override - sends billing address instead of shipping to
PayPal (use with addressoverride)
* other options are also settable.
Testing: while the obvious test choice is to use their sandbox, I've
always found it a bit of a dog's breakfast
and never trusted it. Much better to test on the live site, and just
recyle money between your personal and
business accounts at minimal cost to yourself, but with the
confidence of knowing that test results are correct.
Changelog
- version 1.0.7 December 2009 - another variation in Canadian
Province names has just come to light, whereby they sometimes send - the 2 letter code with periods, eg B.C. as well as BC. Thanks to
- Steve Graham for finding this - patch to allow use of the [assign]
tag in shipping - patch to allow 'use_billing_override' to send
billing addresses - patch to display Long rather than Short PP
error message to customers Thanks to Josh Lavin for these last
three - version 1.0.6 September 2009 - added 'use strict' and fixed odd
errors (and removed giropay vestiges that belong in next version) - - made itemdetails loop through basket properly - added Fraud
- Management Filters return messages to optional charge parameters
version 1.0.5, June 2009 - fixed bug with Canadian provinces: PP
were sending shortened versions of 2 province names, and also
sometimes sending the 2 letter code (possibly from older a/cs) rather
than the full name. Thanks to Steve Graham for finding this.
version 1.0.4, May 2009 - re-wrote documentation, including
revised and simplified method of co-operating with other payment
systems in log_transaction. - version 1.0.3, 1.02.2009 - fixed bug in handling of thousands
separator - version 1.0.2, 22.01.2009 - conversion of Canadian province names
to 2 letter variant is now the default - fixed bug with conversion
of Canadian province names to 2 letter variant - changed method of
reading value of pprequest - added failsafe logging to
orders/paypal/ in case of order route failure - fixed bug whereby PP returns billing name in a shipping address - added note to docs re PP requiring cookie - altered internal redirection code to
better handle absence of cookies (thanks to Peter Ajamian for heads-up) - - altered docs to reflect the new sandbox (thanks to Josh Lavin
- for the heads-up on that) - TODO: as the new API now includes a
SOAP integration of recurring/subscription billing, need
to convert existing name=value pair IPN module and integrate into this module. Will add masspay, refund and other functions at
the same time. - version 1.0.1, 24.05.2008 - added error message to IC session for
when Paypal returns error message instead of token. - added
option to convert Canadian state/province names to an uppercased 2
letter variant, so - as to agree with Interchange's de facto requirement for
- this. =back
AUTHORS
- Lyn St George <info@zolotek.net> Based on original code by Mike Heins
<mheins@perusion.com>