.\" Automatically generated by Pod::Man 2.28 (Pod::Simple 3.29) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is turned on, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{ . if \nF \{ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "Vend::Payment::CyberSource 3pm" .TH Vend::Payment::CyberSource 3pm "2016-08-31" "perl v5.22.2" "User Contributed Perl Documentation" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "Interchange CyberSource Support" .IX Header "Interchange CyberSource Support" Vend::Payment::CyberSource Revision: 1.0 .SH "SYNOPSIS" .IX Header "SYNOPSIS" .Vb 1 \& &charge=cybersource \& \& or \& \& [charge gateway=cybersource param1=value1 param2=value2] \& \& or, with a route named foo with gateway => cybersource \& \& [charge route=foo] .Ve .PP While you have free will, \fBplease\fR use a route. See below. .SH "PREREQUISITES" .IX Header "PREREQUISITES" .Vb 4 \& SOAP::Lite \& XML::Pastor::Schema::Parser \& LWP::Simple \& OpenSSL .Ve .SH "DESCRIPTION" .IX Header "DESCRIPTION" The Vend::Payment::CyberSource module implements the \fIcybersource()\fR routine for use with Interchange. It is compatible on a call level with the other Interchange payment modules. .PP To enable this module, place this directive in \f(CW\*(C`interchange.cfg\*(C'\fR: .PP .Vb 1 \& Require module Vend::Payment::CyberSource .Ve .PP This \fImust\fR be in interchange.cfg or a file included from it. .PP Make sure CreditCardAuto is off (default in Interchange demos). .PP This module supersedes Vend::Payment::ICS. With only minor adjustments to the payment route and some changes to the keys in \f(CW$Session\fR\->{payment_result}, Vend::Payment::CyberSource should function as a drop-in replacement for Vend::Payment::ICS. If you have legacy support for the \s-1SCMP API\s0 and don't need any of the new features supported in this module, you do not need to change. However, all new CyberSource clients will have to use this module as they do not allow new clients to use \s-1SCMP.\s0 .PP If you do choose to replace the current use of Vend::Payment::ICS, you will have to abandon the merchant keys generated by \fIecert()\fR (I know, it's a devastating blow) and instead generate a transaction key from within the online merchant account. That new transaction key will be added to your payment route. .PP Whenever possible, please set your payment parameters using a payment route or passed as arguments to [charge] directly. No special effort has been made to consistently fall back on the \fIcharge_param()\fR function, which plucks values out of the MV_PAYMENT_* variable space. It is not possible to isolate variables to a specific charge routine using \fIcharge_param()\fR and, as such, it should be viewed with suspicion, rather than being used as a crutch. In particular, this module makes the assumption that certain critical route parameters will be present in \f(CW$opt\fR, and the best way to ensure they are in there is to use a payment route. .SS "Simple made Simple" .IX Subsection "Simple made Simple" You may treat this gateway module as though it were the Simple \s-1API.\s0 The construction of the requests and responses within the Vend::Payment namespace will correspond either virtually (in the case of \s-1SOAP\s0 errors, it's probably different) or exactly (in the case of successful requests, even if the transaction itself is not successful) to the request/response name/value pairs documented for the Simple \s-1API.\s0 .PP Unlike its name may imply, the Simple \s-1API\s0 is in fact not simple to install. Difficult becomes Impossible if you have a 64\-bit \s-1OS.\s0 CyberSource as of this module's writing has not seen fit to port either of their client APIs (\s-1SCMP\s0 or Simple) to a 64\-bit version. However, because this is actually the \s-1SOAP\s0 clientless toolkit wrapped to impersonate Simple, you get to by-pass the pain you'd otherwise have to feel to install Simple into your environment. .PP \&\fBWhat this means:\fR do \fI\s-1NOT\s0\fR install the Simple \s-1API\s0! It will likely be a big pain and \fIit is useless\fR for the purposes of this module. You only need to ensure the modules/software indicated in \s-1PREREQUISITES\s0 are installed. .PP You can find the documentation for the Simple \s-1API\s0 at the following \s-1URL:\s0 .PP http://apps.cybersource.com/library/documentation/sbc/api_guide/html/ .PP Again, do \fI\s-1NOT\s0\fR install the Simple \s-1API\s0; just use the docs as though it is already installed. .SS "Options" .IX Subsection "Options" .IP "\fBmerchant_id\fR" 4 .IX Item "merchant_id" \&\s-1ID\s0 obtained from CyberSource. Likely the same value you use to log in to the online merchant interface for your account. .IP "\fBtransaction_key\fR" 4 .IX Item "transaction_key" Key generated from the CyberSource online merchant interface. .IP "\fBapi_version\fR" 4 .IX Item "api_version" Which version of Simple to use. When setting up, just pick the current one, and updates are likely unneeded unless new features come out that you need. .Sp You can see the full list of versions, and what features they each support (if you like reading \s-1XSD\s0) here: .Sp https://ics2ws.ic3.com/commerce/1.x/transactionProcessor/ .Sp The opt should be just the number, something like 1.44 .IP "\fBlive\fR" 4 .IX Item "live" Calls go to production environment when value is 'true' (as in, the string true, and not just perly true, to give those already familiar with the actual Simple \s-1API\s0 warm fuzzy feelings). Any other value (or no value) is assumed to go to the test environment. .IP "\fBxsd_cache_dir\fR" 4 .IX Item "xsd_cache_dir" Directory relative to catroot for caching the \s-1XSD\s0 files for each \s-1API\s0 version and from each environment (live or test). If not set, no caching will occur, but this is \fInot\fR recommended. .Sp The module makes an initial request to CyberSource to get the \s-1XSD\s0 for whatever version of the \s-1API\s0 you're using, so that it knows what request values to look for and are valid. Ideally, you don't want every single request repeating this process. .Sp If this option is set, the module will first look for the appropriate \s-1XSD\s0 associated with the correct version and environment in the cache dir. If it's not found, only then will it request the \s-1XSD\s0 from CyberSource. Once it's obtained from from CyberSource, it will cache it in the same location it initially looked, so all subsequent requests using the same \s-1API\s0 version in the same environment can use the cached \s-1XSD\s0 instead. .Sp There should be no reason to expire the cache, but if you wish to you'll have to do so manually. There's no built-in expiration mechanism. Because a published \s-1API\s0 will be static, the only reason you would need to expire the cached version is if it somehow became corrupted. .Sp Also, don't manually replace files in the cache. The \s-1XSD\s0 retrieved from CyberSource must be slightly tweaked to work with the \s-1XSD\s0 parsing module. That tweak is frozen into the cache. If you wish to refresh the cache, just remove the cache files and let the module itself pull down the correct version and cache it for you. .IP "\fBacct_type\fR" 4 .IX Item "acct_type" The type of the account for the customer's payment instrument. Currently supported: .Sp .Vb 4 \& * cc (standard credit card, the default) \& * bml (Bill Me Later) \& * pp (Paypal Express Checkout) \& * ec (Electronic Check) .Ve .IP "\fBtransaction\fR" 4 .IX Item "transaction" Type of transaction to run. .Sp acct_type cc or bml: .Sp .Vb 6 \& * auth (or authorize, A) \& * settle (or capture, D) \& * sale (or S) \- auth and settle in same request \& * credit (or C) \& * auth_reversal (or R) (not widely supported; use with caution) \& * void (or V) .Ve .Sp For additional information on acct_type 'bml' transactions, see full \fBBill Me Later\fR section below. .Sp acct_type pp: .Sp .Vb 9 \& * pp_set (Exp. checkout set service) \& * pp_get (Exp. checkout get service) \& * pp_dopmt (Exp. Checkout do payment) \& * pp_ord_setup (Exp. Checkout order setup) \& * pp_auth (auth service) \& * pp_bill (capture service) \& * pp_sale (auth and capture together) \& * pp_authrev (reverse auth) \& * pp_refund (refund service) .Ve .Sp See \fBPaypal\fR section below for full details .Sp acct_type ec: .Sp .Vb 2 \& * ec_debit \& * ec_credit .Ve .Sp See \fBElectronic Check\fR section below for full details .IP "\fBorigid\fR" 4 .IX Item "origid" Original transaction \s-1ID\s0 referenced for follow-on transactions. E.g., the requestID of an auth that is to be captured. .IP "\fBorder_id or order_number\fR" 4 .IX Item "order_id or order_number" Passed over as merchantReferenceCode with request. Also very likely needed for any use of \fBitems_sub\fR (see below). .IP "\fBapps\fR" 4 .IX Item "apps" The list of allowable applications, space\- or comma-separated, for this request. Added as a security measure to restrict use on any applications that aren't needed and might be a risk (such as credits if they'll never be issued through Interchange). All ics_* apps apply to cc and bml account types. pp_* and ec_* apply to account types pp and ec, respectively: .Sp .Vb 10 \& * ics_auth (needed for auth, sale) \& * ics_auth_reversal (needed for auth_reversal) \& * ics_bill (needed for settle, sale) \& * ics_credit (needed for credit) \& * ics_void (needed for void) \& * pp_ec_set (needed for pp_set) \& * pp_ec_get (needed for pp_get) \& * pp_ec_dopmt (needed for pp_dopmt, pp_sale) \& * pp_ec_ord_setup (needed for pp_ord_setup) \& * pp_auth (needed for pp_auth) \& * pp_capture (needed for pp_bill, pp_sale) \& * pp_authrev (needed for pp_authrev) \& * pp_refund (needed for pp_refund) \& * ec_debit (needed for ec_debit) \& * ec_credit (needed for ec_credit) .Ve .Sp It is recommended to exclude any apps you will not use from the list. .IP "\fBship_map\fR" 4 .IX Item "ship_map" List of mv_shipmode values to map to the various allowable values in shipTo_shippingMethod. List is optional and defaults to 'lowcost'. .Sp The list should be in a form that is appropriate for perl's \fIqw()\fR to put the list into a hash. E.g.,: .Sp .Vb 3 \& GNDRES lowcost \& 2DAY twoday \& ... .Ve .Sp List of possible CyberSource values: .Sp .Vb 8 \& * sameday \& * oneday \& * twoday \& * threeday \& * lowcost \& * pickup \& * other \& * none .Ve .IP "\fBmv_credit_card_number\fR" 4 .IX Item "mv_credit_card_number" Unlike many (if not the rest) of the gateway modules, you can pass in the card number as an option. However, the code prefers the value from the traditional source from \f(CW$CGI\fR via the actual opt. This option will mostly be unneeded. .IP "\fBany Simple request keys\fR" 4 .IX Item "any Simple request keys" The code will take any of the Simple key names directly through \f(CW$opt\fR. However, it will prefer any defined values associated with \fIactual()\fR over \f(CW$opt\fR, which may not be what you expect. .IP "\fBitems_sub\fR" 4 .IX Item "items_sub" Custom subroutine that can be used to construct the order sent over to CyberSource. By default, module uses \f(CW$Vend::Items\fR. Routine will be essential for any processing of payments that are not directly associated with the immediate session. E.g., any payment interface developed for the admin to process transactions after the order already exists. .Sp Routine should return an array that matches the basics of an Interchange cart. Most likely use would be to construct a cart out of an order already in the database, but as long as the routine returns a cart-style array, it doesn't matter how it's constructed. .Sp Each line item needs the following attributes: .Sp .Vb 2 \& * code \& * quantity .Ve .Sp To determine cost, each line-item hash is passed to \fIVend::Data::item_price()\fR. So, if your pricing demands more line-item attributes to calculate correctly, you'll need to ensure they are present. .Sp Routine can be either a catalog or global sub, with the code preferring the catalog sub. Args: .Sp .Vb 2 \& * Reference to copy of request hash \& * $opt .Ve .IP "\fBcheck_sub\fR" 4 .IX Item "check_sub" Post-reply routine that can be used to alter the status and/or response hash returned from \fIcybersource()\fR. Examples of usage: .RS 4 .IP "\(bu" 4 Auth succeeds, but we want it treat as a failure because of \s-1AVS\s0 response. .IP "\(bu" 4 Auth fails, but error is a communication failure, so we want to treat it as success and follow up manually with customer to resolve. .IP "\(bu" 4 Decision Manager result raises concerns, so we add a response parameter that indicates the order should not be fulfilled automatically, but rather funnel to a queue for manual review. .RE .RS 4 .Sp Routine should return 'success' or 'failed' if it is to be authoritative as to that determination. Otherwise, it should return undef and let the code calculate 'success' or 'failed' based on the value of the 'decision' key in the response hash. .Sp It can be either a catalog or global sub, with the code preferring the catalog sub. Args: .Sp .Vb 3 \& * Reference to response hash (so it can be modified directly) \& * Reference to a copy of the request hash \& * $opt .Ve .RE .IP "\fBip_address\fR" 4 .IX Item "ip_address" \&\s-1IP\s0 to supply to CyberSource for the transaction. Optional and defaults to \&\f(CW$Session\fR\->{shost} if defined, or \f(CW$Session\fR\->{ohost} otherwise. .IP "\fBshipping\fR" 4 .IX Item "shipping" Amount to supply CyberSource for shipping costs. Defaults to [shipping]. .IP "\fBamount\fR" 4 .IX Item "amount" Amount to supply to CyberSource to apply to the transaction. .Sp Note that this value supersedes all the costs provided along with the order and shipping amounts. They do not have to agree. Supplying \fIamount\fR means CyberSource will use that specific amount. If \fIamount\fR is not supplied, I believe that CyberSource will construct a transaction amount from the sum of the order and shipping, but I do not recommend this. .Sp By default, \fIamount\fR will be derived from [total\-cost]. .IP "\fBtimeout\fR" 4 .IX Item "timeout" Number of seconds for a request without a response before the process is killed. .IP "\fBmerrmsg, merrmsg_bml\fR" 4 .IX Item "merrmsg, merrmsg_bml" Override the default error messages presented to users in the event of a failed transaction attempt, for \fBacct_type\fR cc and bml, respectively. \fBmerrmsg\fR will run through \fIsprintf()\fR and can have the reason code and reason message, in that order, embedded in message with the use of \f(CW%s\fR as a placeholder. \fBmerrmsg_bml\fR has no such provision because the errors that come back from Paymentech for \s-1BML\s0 failures range between cryptic and useless. .PP The following options are valid for Paypal usage only: .IP "\fBreturnurl\fR" 4 .IX Item "returnurl" \&\s-1URL\s0 to which the customer's browser is returned after choosing to pay with PayPal. .IP "\fBcancelurl\fR" 4 .IX Item "cancelurl" \&\s-1URL\s0 to which customers are returned if they do not approve the use of PayPal for payment. .IP "\fBmaxamount\fR" 4 .IX Item "maxamount" Expected maximum total amount of the entire order, including shipping costs and tax charges. .IP "\fBbillinginfo\fR" 4 .IX Item "billinginfo" Optional boolean indicator to request that PayPal return the user's billing information on GetRequest. .Sp 0 (default): Do not return the customer's billing address. .Sp 1: Return the customer's billing address. .IP "\fBuseraction\fR" 4 .IX Item "useraction" Which PayPal useraction is desired. This essentially indicates the label of the button for the user when coming back from PayPal to the merchant's site. Options are: .RS 4 .IP "continue" 4 .IX Item "continue" Default. Standard usage when merchants expect the user to come back to their site and provide more data, or explicit actions, to complete checkout. Button user clicks is labeled \*(L"Continue\*(R". .IP "commit" 4 .IX Item "commit" Usage option when merchant does not require to collect more data or have the user perform any actions on the merchant site before completing the order. The \&\s-1API\s0 behavior is the same as that for usertype continue; the only difference is the button the user is to click will say \*(L"Buy Now\*(R". .RE .RS 4 .Sp Regardless of which \fBuseraction\fR is specified, the merchant's site must process a getrequest and dopayment in response in order to complete the sale. Clicking \*(L"Buy Now\*(R" doesn't actually do any such thing on PayPal's side. It just authorizes the merchant to immediately process payment once the user has returned. .RE .IP "\fBorder_desc\fR" 4 .IX Item "order_desc" Description of items the customer is purchasing. .IP "\fBconfirmshipping\fR" 4 .IX Item "confirmshipping" Flag that indicates if you require the customer's shipping address on file with PayPal to be a confirmed address. 0 (default) not confirmed, 1 confirmed. .IP "\fBnoshipping\fR" 4 .IX Item "noshipping" Flag that indicates if the shipping address should be displayed on the PayPal Web pages. 0 (default) show shipping, 1 suppress shipping display. .IP "\fBaddressoverride\fR" 4 .IX Item "addressoverride" Customer-supplied address sent in the SetExpressCheckout request rather than the address on file with PayPal for this customer. .Sp You can use this field only with the payment method, not with the shortcut method. See Overview of PayPal Express Checkout for a description of the PayPal methods. .Sp Possible values: .Sp 0 (default): Display the address on file with PayPal. The customer cannot edit this address. .Sp 1: Display the customer-supplied address. The customer can edit this in PayPal Express Checkout. .IP "\fBlocale\fR" 4 .IX Item "locale" Locale of pages displayed by PayPal during Express Checkout. .IP "\fBheaderbackcolor\fR" 4 .IX Item "headerbackcolor" Background color for the header of the payment page. Format: \s-1HTML\s0 Hexadecimal color. .IP "\fBheaderbordercolor\fR" 4 .IX Item "headerbordercolor" Border color around the header of the payment page. Format: \s-1HTML\s0 Hexadecimal color. .IP "\fBheaderimg\fR" 4 .IX Item "headerimg" \&\s-1URL\s0 for the image that will be displayed in the upper left area of the payment page. .IP "\fBpayflowcolor\fR" 4 .IX Item "payflowcolor" Background color for the payment page. Format: \s-1HTML\s0 Hexadecimal color. .IP "\fBpp_token\fR" 4 .IX Item "pp_token" Timestamped token by which you identify to PayPal that you are processing this payment with Express Checkout. Corresponds with paypalToken description in CyberSource docs. Normally not needed as module will handle internally for most typical scenarios. .IP "\fBpp_payer_id\fR" 4 .IX Item "pp_payer_id" Unique PayPal customer account identification number that was returned in the payPalEcGetDetailsService reply message. Corresponds with paypalPayerId description in CyberSource docs. Normally not needed as module will handle internally for most typical scenarios. .IP "\fBreturn_ec_set\fR" 4 .IX Item "return_ec_set" Boolean to indicate that an \s-1EC\s0 set call is to be issued as a return call; that is, a call to amend the user's Paypal data returned in a subsequent \s-1EC\s0 get call on the same session established by an initial \s-1EC\s0 set call. .Sp The same can be accomplished by calling \s-1EC\s0 set while explicitly supplying the paypal token and CyberSource request \s-1ID\s0 and token of the original call to \s-1EC\s0 set establishing that session. .IP "\fBtransaction_id\fR" 4 .IX Item "transaction_id" For use in captures, refunds, and auth reversals. Maps to the \&\fIpaypal-specific\fR transaction \s-1ID\s0 of the original request, and not the RequestID, which is the CyberSource transaction \s-1ID.\s0 .Sp Specifically, it should relate in the following manner: \fIMaps to Service Param\fR \fIObtained From\fR payPalDoCaptureService_paypalAuthorizationId payPalEcDoPaymentReply_transactionId payPalAuthReversalService_paypalAuthorizationId payPalAuthorizationReply_transactionId payPalRefundService_paypalCaptureId payPalDoCaptureReply_transactionId .SS "Bill Me Later" .IX Subsection "Bill Me Later" This module provides full support for Bill Me Later (\s-1BML\s0) transactions. Some important notes on using \s-1BML\s0 with this module: .PP See CyberSource's full \s-1BML\s0 documentation for details: .PP http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_IG_BML_Supplement/html/ .IP "\(bu" 4 You'll want to add in the extra fields collected for \s-1BML.\s0 Suggested process is to use the remap feature in \fIVend::Payment::charge()\fR. Thus, add to your route: .Sp .Vb 10 \& Route foo remap <{payment_result}{ccAuthReply_bmlAccountNumber}. Using this account number for repeat customers will speed up the authorization process, but it is not required. Without it, your \s-1BML\s0 customers will have to re-enter their last-four \s-1SSN\s0 and \s-1DOB\s0 each time. .Sp Note that \s-1BML\s0 does not consider this account number sensitive. It can be freely stored unencrypted in the customer's user record. .SS "Paypal" .IX Subsection "Paypal" This module also fully implements CyberSource's integration for Express Checkout services. Note that CyberSource doesn't appear to support all Paypal services, so depending on your needs (e.g., Mass Pay), you may need another option. However, for typical Express Checkout usage, it is fully supported. .PP See CyberSource's full Paypal documentation for details: .PP http://apps.cybersource.com/library/documentation/dev_guides/PayPal_Express_IG/html/ .IP "\(bu" 4 Set acct_type option to 'pp' .IP "\(bu" 4 Module is set up to handle most standard cases with minimal demand on the developer. Paypal requires toting around the paypal session \s-1ID\s0 and, in the case of dopayment, the payer \s-1ID.\s0 Further, CyberSource requires that the request \s-1ID\s0 and token from the \s-1EC\s0 set be passed back on each subsequent request associated with the same paypal session. Finally, using address override needs to be tracked between a set call and subsequent get call. The module will track these values in the user's \s-1IC\s0 session and most likely \*(L"do the right thing\*(R". You can, however, override any of these explicitly if you have the need or wish to control it explicitly. .IP "\(bu" 4 The reply fields are stripped down to their canonical values for convenience. Many times, the same param merely differs in its reply field based on the application under which it was processed. E.g., the \*(L"amount\*(R" returned will come back in one of the following forms: .Sp .Vb 5 \& payPalEcSetReply_amount \& payPalEcDoPaymentReply_amount \& payPalEcOrderSetupReply_amount \& payPalAuthorizationReply_amount \& payPalDoCaptureReply_amount .Ve .Sp Any of these will be stripped down to just \*(L"amount\*(R" in the payment_result hash, but the fully qualified parameter is left in place, too, if needed. .IP "\(bu" 4 It is recommended that you utilize \fBcheck_sub\fR in conjunction with an \s-1EC\s0 get request for migrating response values from Paypal into the Interchange session. The following is a sample sub that works in conjunction with a typical configuration based off the standard demo: .Sp .Vb 3 \& Sub load_values <{decision} eq \*(AqACCEPT\*(Aq; \& \& my $b_pre = $Values\->{pp_use_billing_address} \& ? \*(Aqb_\*(Aq \& : \*(Aq\*(Aq \& ; \& \& $Values\->{$b_pre . \*(Aqphone_day\*(Aq} = $resp\->{payerPhone}; \& \& $Values\->{email} = $resp\->{payer}; \& $Values\->{payerid} = $resp\->{PayerId}; \& $Values\->{payerstatus} = $resp\->{payerStatus}; \& $Values\->{payerbusiness} = $resp\->{payerBusiness}; \& $Values\->{salutation} = $resp\->{payerSalutation}; \& $Values\->{mname} = $resp\->{payerMiddlename}; \& $Values\->{suffix} = $resp\->{payerSuffix}; \& $Values\->{address_status} = $resp\->{addressStatus}; \& $Values\->{countryname} = $resp\->{countryName}; \& \& unless ($Session\->{paypal_override}) { \& $Values\->{$b_pre . \*(Aqfname\*(Aq} = $resp\->{payerFirstname}; \& $Values\->{$b_pre . \*(Aqlname\*(Aq} = $resp\->{payerLastname}; \& $Values\->{$b_pre . \*(Aqaddress1\*(Aq} = $resp\->{shipToAddress1}; \& $Values\->{$b_pre . \*(Aqaddress2\*(Aq} = $resp\->{shipToAddress2}; \& $Values\->{$b_pre . \*(Aqcity\*(Aq} = $resp\->{shipToCity}; \& $Values\->{$b_pre . \*(Aqstate\*(Aq} = $resp\->{shipToState}; \& $Values\->{$b_pre . \*(Aqzip\*(Aq} = $resp\->{shipToZip}; \& $Values\->{$b_pre . \*(Aqcountry\*(Aq} = $resp\->{shipToCountry}; \& } \& \& return; \& } \& EOS .Ve .IP "\(bu" 4 When making an \s-1EC\s0 set call through [charge], the module will return the appropriate \s-1URL\s0 to which to redirect the user's browser rather than the typical value of the transaction \s-1ID.\s0 Thus, when running an \s-1EC\s0 set, it is appropriate to capture and test the return value from [charge] to determine both if the request was successful and, if so, where to direct the user. .Sp Example mv_click code: .Sp .Vb 9 \& [button \& text="Checkout with Paypal" \& form=basket \& ] \& [tmp redirect][charge route=paypal_set][/tmp] \& [if scratch redirect] \& [bounce href="[scratch redirect]"] \& [/if] \& [/button] .Ve .SS "Electronic Checks" .IX Subsection "Electronic Checks" This module fully implements CyberSource's electronic check support. See documentation for full details: .PP http://apps.cybersource.com/library/documentation/dev_guides/Electronic_Checks_IG/html/ .IP "\(bu" 4 Set acct_type option to 'ec' .IP "\(bu" 4 Includes mappings to use the standard demo's default check payment option. .SS "Troubleshooting" .IX Subsection "Troubleshooting" Try the instructions above in test mode (live set to anything but string \&'true'). A test order should complete. .PP Switch to production mode, then try an auth or sale with the card number \f(CW\*(C`4111 1111 1111 1111\*(C'\fR and a valid expiration date. The transaction should be denied, and the reason should be in [data session payment_error]. .PP If nothing works: .IP "\(bu" 4 Make sure you \*(L"Require\*(R"d the module in interchange.cfg: .Sp .Vb 1 \& Require module Vend::Payment::CyberSource .Ve .IP "\(bu" 4 Make sure all the modules/applications listed in \s-1PREREQUISITES\s0 are installed and working. You can test to see whether your Perl thinks they are: .Sp .Vb 4 \& perl \-MSOAP::Lite \e \& \-MXML::Pastor::Schema::Parser \e \& \-MLWP::Simple \e \& \-e \*(Aqprint "It works\en"\*(Aq .Ve .Sp If it prints \*(L"It works.\*(R" and returns to the prompt you should be \s-1OK \s0(presuming they are in working order otherwise). .IP "\(bu" 4 Check the error logs, both catalog and global. Also set debugging on in \&\f(CW\*(C`interchange.cfg\*(C'\fR and check the debug log! .IP "\(bu" 4 Make sure you set your payment parameters properly, and of course you used a payment route, right? .IP "\(bu" 4 Try an order, then put this code in a page: .Sp .Vb 8 \& \& [calc] \& my $string = $Tag\->uneval( { ref => $Session\->{payment_result} }); \& $string =~ s/{/{\en/; \& $string =~ s/,/,\en/g; \& return $string; \& [/calc] \& .Ve .Sp That should show what happened. .IP "\(bu" 4 If all else fails, consultants are available to help with integration for a fee. See http://www.icdevgroup.org/ for mailing lists and other information. .SH "BUGS" .IX Header "BUGS" Naturally none. \s-1OK,\s0 at least none known. Be sure to post any found to the \s-1IC\s0 user list or you can send them to the author directly. .SH "AUTHOR" .IX Header "AUTHOR" Mark Johnson (Based primarily off of Vend::Payment::ICS by Sonny Cook )