.\" Automatically generated by Pod::Man 4.09 (Pod::Simple 3.35)
.\"
.\" 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 >0, 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
..
.if !\nF .nr F 0
.if \nF>0 \{\
.    de IX
.    tm Index:\\$1\t\\n%\t"\\$2"
..
.    if !\nF==2 \{\
.        nr % 0
.        nr F 2
.    \}
.\}
.\" ========================================================================
.\"
.IX Title "OnlinePayment 3pm"
.TH OnlinePayment 3pm "2018-02-26" "perl v5.26.1" "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 "NAME"
Business::OnlinePayment \- Perl extension for online payment processing
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\&  use Business::OnlinePayment;
\&  
\&  my $transaction = new Business::OnlinePayment($processor, %processor_info);
\&  $transaction\->content(
\&                        type        => \*(AqVisa\*(Aq,
\&                        amount      => \*(Aq49.95\*(Aq,
\&                        card_number => \*(Aq1234123412341238\*(Aq,
\&                        expiration  => \*(Aq06/15\*(Aq,
\&                        name        => \*(AqJohn Q Doe\*(Aq,
\&                       );
\&
\&  eval { $transaction\->submit(); };
\&
\&  if ( $@ ) {
\&
\&    print "$processor error: $@\en";
\&
\&  } else {
\&  
\&    if ( $transaction\->is_success() ) {
\&      print "Card processed successfully: ". $transaction\->authorization()."\en";
\&    } else {
\&      print "Card was rejected: ". $transaction\->error_message(). "\en";
\&    }
\&
\&  }
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
Business::OnlinePayment is a generic module for processing payments
through online credit card processors, electronic cash systems, etc.
.SH "CONSTRUCTOR"
.IX Header "CONSTRUCTOR"
.ie n .SS "new($processor, %processor_options)"
.el .SS "new($processor, \f(CW%processor_options\fP)"
.IX Subsection "new($processor, %processor_options)"
Create a new Business::OnlinePayment object, \f(CW$processor\fR is required,
and defines the online processor to use.  If necessary, processor
options can be specified, currently supported options are 'Server',
\&'Port', and 'Path', which specify how to find the online processor
(https://server:port/path), but individual processor modules should
supply reasonable defaults for this information, override the defaults
only if absolutely necessary (especially path), as the processor
module was probably written with a specific target script in mind.
.SH "TRANSACTION SETUP METHODS"
.IX Header "TRANSACTION SETUP METHODS"
.SS "content(%content)"
.IX Subsection "content(%content)"
The information necessary for the transaction, this tends to vary a
little depending on the processor, so we have chosen to use a system
which defines specific fields in the frontend which get mapped to the
correct fields in the backend.  The currently defined fields are:
.PP
\fI\s-1PROCESSOR FIELDS\s0\fR
.IX Subsection "PROCESSOR FIELDS"
.IP "login" 4
.IX Item "login"
Your login name to use for authentication to the online processor.
.IP "password" 4
.IX Item "password"
Your password to use for authentication to the online processor.
.PP
\fI\s-1REQUIRED TRANSACTION FIELDS\s0\fR
.IX Subsection "REQUIRED TRANSACTION FIELDS"
.IP "type" 4
.IX Item "type"
Transaction type, supported types are: \s-1CC\s0 (credit card), \s-1ECHECK\s0
(electronic check) and \s-1LEC\s0 (phone bill billing).  Deprecated types
are: Visa, MasterCard, American Express, Discover, Check.  Not all
processors support all transaction types.
.IP "action" 4
.IX Item "action"
What action being taken by this transaction. Currently available are:
.RS 4
.IP "Normal Authorization" 8
.IX Item "Normal Authorization"
.PD 0
.IP "Authorization Only" 8
.IX Item "Authorization Only"
.IP "Post Authorization" 8
.IX Item "Post Authorization"
.IP "Reverse Authorization" 8
.IX Item "Reverse Authorization"
.IP "Void" 8
.IX Item "Void"
.IP "Credit" 8
.IX Item "Credit"
.IP "Tokenize" 8
.IX Item "Tokenize"
.IP "Recurring Authorization" 8
.IX Item "Recurring Authorization"
.IP "Modify Recurring Authorization" 8
.IX Item "Modify Recurring Authorization"
.IP "Cancel Recurring Authorization" 8
.IX Item "Cancel Recurring Authorization"
.RE
.RS 4
.RE
.IP "amount" 4
.IX Item "amount"
.PD
The amount of the transaction.  No dollar signs or currency identifiers,
just a whole or floating point number (i.e. 26, 26.1 or 26.13).
.PP
\fI\s-1OPTIONAL TRANSACTION FIELDS\s0\fR
.IX Subsection "OPTIONAL TRANSACTION FIELDS"
.IP "partial_auth" 4
.IX Item "partial_auth"
If you are prepared to handle partial authorizations
(see \fIpartial_auth_amount()\fR
 in \s-1TRANSACTION RESULT FIELDS\s0),
pass a true value in this field to enable them.
.Sp
If this flag is not set, a partial authorization will be immediately reversed
or voided.
.IP "description" 4
.IX Item "description"
A description of the transaction (used by some processors to send
information to the client, normally not a required field).
.IP "invoice_number" 4
.IX Item "invoice_number"
An invoice number, for your use and not normally required, many
processors require this field to be a numeric only field.
.IP "po_number" 4
.IX Item "po_number"
Purchase order number (normally not required).
.IP "tax" 4
.IX Item "tax"
Tax amount (portion of amount field, not added to it).
.IP "freight" 4
.IX Item "freight"
Freight amount (portion of amount field, not added to it).
.IP "duty" 4
.IX Item "duty"
Duty amount (portion of amount field, not added to it).
.IP "tax_exempt" 4
.IX Item "tax_exempt"
Tax exempt flag (i.e. \s-1TRUE, FALSE, T, F, YES, NO, Y, N, 1, 0\s0).
.IP "currency" 4
.IX Item "currency"
Currency, specified as an \s-1ISO 4217\s0 three-letter code, such as \s-1USD, CAD, EUR,
AUD, DKK, GBP, JPY, NZD,\s0 etc.
.PP
\fI\s-1CUSTOMER INFO FIELDS\s0\fR
.IX Subsection "CUSTOMER INFO FIELDS"
.IP "customer_id" 4
.IX Item "customer_id"
A customer identifier, again not normally required.
.IP "name" 4
.IX Item "name"
The customer's name, your processor may not require this.
.IP "first_name" 4
.IX Item "first_name"
.PD 0
.IP "last_name" 4
.IX Item "last_name"
.PD
The customer's first and last name as separate fields.
.IP "company" 4
.IX Item "company"
The customer's company name, not normally required.
.IP "address" 4
.IX Item "address"
The customer's address (your processor may not require this unless you
are requiring \s-1AVS\s0 Verification).
.IP "city" 4
.IX Item "city"
The customer's city (your processor may not require this unless you
are requiring \s-1AVS\s0 Verification).
.IP "state" 4
.IX Item "state"
The customer's state (your processor may not require this unless you
are requiring \s-1AVS\s0 Verification).
.IP "zip" 4
.IX Item "zip"
The customer's zip code (your processor may not require this unless
you are requiring \s-1AVS\s0 Verification).
.IP "country" 4
.IX Item "country"
Customer's country.
.IP "ship_first_name" 4
.IX Item "ship_first_name"
.PD 0
.IP "ship_last_name" 4
.IX Item "ship_last_name"
.IP "ship_company" 4
.IX Item "ship_company"
.IP "ship_address" 4
.IX Item "ship_address"
.IP "ship_city" 4
.IX Item "ship_city"
.IP "ship_state" 4
.IX Item "ship_state"
.IP "ship_zip" 4
.IX Item "ship_zip"
.IP "ship_country" 4
.IX Item "ship_country"
.PD
These shipping address fields may be accepted by your processor.
Refer to the description for the corresponding non-ship field for
general information on each field.
.IP "phone" 4
.IX Item "phone"
Customer's phone number.
.IP "fax" 4
.IX Item "fax"
Customer's fax number.
.IP "email" 4
.IX Item "email"
Customer's email address.
.IP "customer_ip" 4
.IX Item "customer_ip"
\&\s-1IP\s0 Address from which the transaction originated.
.PP
\fI\s-1CREDIT CARD FIELDS\s0\fR
.IX Subsection "CREDIT CARD FIELDS"
.IP "card_number" 4
.IX Item "card_number"
Credit card number.
.IP "expiration" 4
.IX Item "expiration"
Credit card expiration, \s-1MM/YY.\s0
.IP "cvv2" 4
.IX Item "cvv2"
\&\s-1CVV2\s0 number (also called \s-1CVC2\s0 or \s-1CID\s0) is a three\- or four-digit
security code used to reduce credit card fraud.
.IP "card_token" 4
.IX Item "card_token"
If supported by your gateway, you can pass a card_token instead of a
card_number and expiration.
.IP "track1" 4
.IX Item "track1"
Track 1 on the magnetic stripe (Card present only)
.IP "track2" 4
.IX Item "track2"
Track 2 on the magnetic stripe (Card present only)
.IP "recurring_billing" 4
.IX Item "recurring_billing"
Recurring billing flag
.PP
\fI\s-1ELECTRONIC CHECK FIELDS\s0\fR
.IX Subsection "ELECTRONIC CHECK FIELDS"
.IP "account_number" 4
.IX Item "account_number"
Bank account number
.IP "routing_code" 4
.IX Item "routing_code"
Bank's routing code
.IP "account_type" 4
.IX Item "account_type"
Account type.  Can be (case-insensitive): \fBPersonal Checking\fR,
\&\fBPersonal Savings\fR, \fBBusiness Checking\fR or \fBBusiness Savings\fR.
.IP "nacha_sec_code" 4
.IX Item "nacha_sec_code"
\&\s-1NACHA SEC\s0 Code for \s-1US ACH\s0 transactions.  '\s-1PPD\s0' indicates customer signed a form
giving authorization for the charge, '\s-1CCD\s0' same for a business checking/savings
account, '\s-1WEB\s0' for online transactions where a box was checked authorizing the
charge, and '\s-1TEL\s0' for authorization via recorded phone call (\s-1NACHA\s0 script
required).
.IP "account_name" 4
.IX Item "account_name"
Account holder's name.
.IP "bank_name" 4
.IX Item "bank_name"
Bank name.
.IP "bank_city" 4
.IX Item "bank_city"
Bank city.
.IP "bank_state" 4
.IX Item "bank_state"
Bank state.
.IP "check_type" 4
.IX Item "check_type"
Check type.
.IP "customer_org" 4
.IX Item "customer_org"
Customer organization type.
.IP "customer_ssn" 4
.IX Item "customer_ssn"
Customer's social security number.
.IP "license_num" 4
.IX Item "license_num"
Customer's driver's license number.
.IP "license_dob" 4
.IX Item "license_dob"
Customer's date of birth.
.PP
\fIFOLLOW-UP \s-1TRANSACTION FIELDS\s0\fR
.IX Subsection "FOLLOW-UP TRANSACTION FIELDS"
.PP
These fields are used in follow-up transactions related to an original
transaction (Post Authorization, Reverse Authorization, Void, Credit).
.IP "authorization" 4
.IX Item "authorization"
.PD 0
.IP "order_number" 4
.IX Item "order_number"
.IP "txn_date" 4
.IX Item "txn_date"
.PD
.PP
\fI\s-1RECURRING BILLING FIELDS\s0\fR
.IX Subsection "RECURRING BILLING FIELDS"
.IP "interval" 4
.IX Item "interval"
Interval expresses the amount of time between billings: digits, whitespace
and units (currently \*(L"days\*(R" or \*(L"months\*(R" in either singular or plural form).
.IP "start" 4
.IX Item "start"
The date of the first transaction (used for processors which allow delayed
start) expressed as YYYY-MM-DD.
.IP "periods" 4
.IX Item "periods"
The number of cycles of interval length for which billing should occur 
(inclusive of 'trial periods' if the processor supports recurring billing
at more than one rate)
.SS "\fItest_transaction()\fP"
.IX Subsection "test_transaction()"
Most processors provide a test mode, where submitted transactions will
not actually be charged or added to your batch, calling this function
with a true argument will turn that mode on if the processor supports
it, or generate a fatal error if the processor does not support a test
mode (which is probably better than accidentally making real charges).
.SS "\fIrequire_avs()\fP"
.IX Subsection "require_avs()"
Providing a true argument to this module will turn on address
verification (if the processor supports it).
.SH "TRANSACTION SUBMISSION METHOD"
.IX Header "TRANSACTION SUBMISSION METHOD"
.SS "\fIsubmit()\fP"
.IX Subsection "submit()"
Submit the transaction to the processor for completion.
.PP
If there is a gateway communication error or other \*(L"meta\*(R" , the submit method
will throw a fatal exception.  You can catch this with eval {} if you would
like to treat gateway co
.SH "TRANSACTION RESULT METHODS"
.IX Header "TRANSACTION RESULT METHODS"
.SS "\fIis_success()\fP"
.IX Subsection "is_success()"
Returns true if the transaction was approved by the gateway, false if 
it was submitted but not approved, or undef if it has not been 
submitted yet.
.SS "\fIpartial_auth_amount()\fP"
.IX Subsection "partial_auth_amount()"
If this transaction was a partial authorization (i.e. successful, but less than
the requested amount was processed), then the amount processed is returned in
this field.
.PP
(When is_success is true but this field is empty or 0, that indicates a normal
full authorization for the entire requested amount.)
.SS "\fIerror_message()\fP"
.IX Subsection "error_message()"
If the transaction has been submitted but was not accepted, this
function will return the provided error message (if any) that the
processor returned.
.SS "\fIfailure_status()\fP"
.IX Subsection "failure_status()"
If the transaction failed, it can optionally return a specific failure
status (normalized, not gateway-specific).  Currently defined statuses
are: \*(L"expired\*(R", \*(L"nsf\*(R" (non-sufficient funds), \*(L"stolen\*(R", \*(L"pickup\*(R",
\&\*(L"blacklisted\*(R" and \*(L"declined\*(R" (card/transaction declines only, not
other errors).
.PP
Note that not all processor modules support this, and that if supported,
it may not be set for all declines.
.SS "\fIauthorization()\fP"
.IX Subsection "authorization()"
If the transaction has been submitted and accepted, this function will
provide you with the authorization code that the processor returned.
Store this if you would like to run inquiries or refunds on the transaction
later.
.SS "\fIorder_number()\fP"
.IX Subsection "order_number()"
The unique order number for the transaction generated by the gateway.  Store
this if you would like to run inquiries or refunds on the transaction later.
.SS "\fIcard_token()\fP"
.IX Subsection "card_token()"
If supported by your gateway, a card_token can be used in a subsequent
transaction to refer to a card number.
.SS "\fItxn_date()\fP"
.IX Subsection "txn_date()"
Transaction date, as returned by the gateway.  Required by some gateways
for follow-up transactions.  Store this if you would like to run inquiries or
refunds on the transaction later.
.SS "\fIfraud_score()\fP"
.IX Subsection "fraud_score()"
Retrieve or change the fraud score from any Business::FraudDetect plugin
.SS "\fIfraud_transaction_id()\fP"
.IX Subsection "fraud_transaction_id()"
Retrieve or change the transaction id from any Business::FraudDetect plugin
.SS "\fIresponse_code()\fP"
.IX Subsection "response_code()"
.SS "\fIresponse_headers()\fP"
.IX Subsection "response_headers()"
.SS "\fIresponse_page()\fP"
.IX Subsection "response_page()"
These three fields are set by some processors (especially those which use
\&\s-1HTTPS\s0) when the transaction fails at the communication level rather than
as a transaction.
.PP
response_code is the \s-1HTTP\s0 response code and message, i.e.
\&'500 Internal Server Error'.
.PP
response_headers is a hash reference of the response headers
.PP
response_page is the raw content.
.SS "\fIresult_code()\fP"
.IX Subsection "result_code()"
Returns the precise result code that the processor returned, these are
normally one letter codes that don't mean much unless you understand
the protocol they speak, you probably don't need this, but it's there
just in case.
.SS "\fIavs_code()\fP"
.IX Subsection "avs_code()"
.SS "\fIcvv2_response()\fP"
.IX Subsection "cvv2_response()"
.SH "MISCELLANEOUS INTERNAL METHODS"
.IX Header "MISCELLANEOUS INTERNAL METHODS"
.SS "\fItransaction_type()\fP"
.IX Subsection "transaction_type()"
Retrieve the transaction type (the 'type' argument to \fIcontents()\fR).
Generally only used internally, but provided in case it is useful.
.SS "\fIserver()\fP"
.IX Subsection "server()"
Retrieve or change the processor submission server address (\s-1CHANGE AT
YOUR OWN RISK\s0).
.SS "\fIport()\fP"
.IX Subsection "port()"
Retrieve or change the processor submission port (\s-1CHANGE AT YOUR OWN
RISK\s0).
.SS "\fIpath()\fP"
.IX Subsection "path()"
Retrieve or change the processor submission path (\s-1CHANGE AT YOUR OWN
RISK\s0).
.SH "HELPER METHODS FOR GATEWAY MODULE AUTHORS"
.IX Header "HELPER METHODS FOR GATEWAY MODULE AUTHORS"
.ie n .SS "build_subs( @sub_names )"
.el .SS "build_subs( \f(CW@sub_names\fP )"
.IX Subsection "build_subs( @sub_names )"
Build setter/getter subroutines for new return values.
.ie n .SS "get_fields( @fields )"
.el .SS "get_fields( \f(CW@fields\fP )"
.IX Subsection "get_fields( @fields )"
Get the named fields if they are defined.
.ie n .SS "remap_fields( %map )"
.el .SS "remap_fields( \f(CW%map\fP )"
.IX Subsection "remap_fields( %map )"
Remap field content (and stuff it back into content).
.ie n .SS "required_fields( @fields )"
.el .SS "required_fields( \f(CW@fields\fP )"
.IX Subsection "required_fields( @fields )"
Croaks if any of the required fields are not present.
.SS "dump_contents"
.IX Subsection "dump_contents"
.ie n .SS "silly_bool( $value )"
.el .SS "silly_bool( \f(CW$value\fP )"
.IX Subsection "silly_bool( $value )"
Returns 1 if the value starts with y, Y, t or T.
Returns 0 if the value starts with n, N, f or F.
Otherwise returns the value itself.
.PP
Use this for handling boolean content like tax_exempt.
.SH "AUTHORS"
.IX Header "AUTHORS"
(v2 series)
.PP
Jason Kohles, email@jasonkohles.com
.PP
(v3 rewrite)
.PP
Ivan Kohler <ivan\-business\-onlinepayment@420.am>
.PP
Phil Lobbes <phil at perkpartners dot com>
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (c) 1999\-2004 Jason Kohles
Copyright (c) 2004 Ivan Kohler
Copyright (c) 2007\-2018 Freeside Internet Services, Inc.
.PP
All rights reserved.
.PP
This program is free software; you can redistribute it and/or modify it under
the same terms as Perl itself.
.SH "HOMEPAGE"
.IX Header "HOMEPAGE"
Homepage:  http://perl.business/onlinepayment
.PP
Development:  http://perl.business/onlinepayment/ng.html
.SH "MAILING LIST"
.IX Header "MAILING LIST"
Please direct current development questions, patches, etc. to the mailing list:
http://mail.freeside.biz/cgi\-bin/mailman/listinfo/bop\-devel/
.SH "REPOSITORY"
.IX Header "REPOSITORY"
The code is available from our public git repository:
.PP
.Vb 1
\&  git clone git://git.freeside.biz/Business\-OnlinePayment.git
.Ve
.PP
Or on the web:
.PP
.Vb 3
\&  http://git.freeside.biz/gitweb/?p=Business\-OnlinePayment.git
\&  Or:
\&  http://git.freeside.biz/cgit/Business\-OnlinePayment.git
.Ve
.PP
Many (but by no means all!) processor plugins are also available in the same
repository, see:
.PP
.Vb 3
\&  http://git.freeside.biz/gitweb/
\&  Or:
\&  http://git.freeside.biz/cgit/
.Ve
.SH "DISCLAIMER"
.IX Header "DISCLAIMER"
\&\s-1THIS SOFTWARE IS PROVIDED \*(L"AS IS\*(R" AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.\s0
.SH "SEE ALSO"
.IX Header "SEE ALSO"
http://perl.business/onlinepayment
.PP
For verification of credit card checksums, see Business::CreditCard.