Provided by: interchange_5.7.7-2_amd64 bug


       Vend::Payment::PaypalExpress - Interchange Paypal Express Payments Module


           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"'


       The Vend::Payment::PaypalExpress module implements the paypalexpress() routine for use
       with Interchange.



       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

       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  (for testing) Route  paypalexpress host (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]"]
                 [charge route="paypalexpress" pprequest="setrequest"]

       Create a page 'ord/paypalgetrequest.html', and make it the target of the returnURL from
       Paypal: [charge route="paypalexpress" pprequest="getrequest"] [bounce href="[area

       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

       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

       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

       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
        * addressoverride - this specifies that you will ship only to the address IC has on file
          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
        * 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.


       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

       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


       Lyn St George <> Based on original code by Mike Heins