The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
 / 
Business-OnlinePayment-3.00
River stage two • 40 direct dependents • 41 total dependents
++
/ Business::OnlinePayment

NAME

Business::OnlinePayment - Perl extension for online payment processing

SYNOPSIS

  use Business::OnlinePayment;
  
  my $transaction = new Business::OnlinePayment($processor, %processor_info);
  $transaction->content(
                        type        => 'Visa',
                        amount      => '49.95',
                        card_number => '1234123412341238',
                        expiration  => '0100',
                        name        => 'John Q Doe',
                       );
  $transaction->submit();
  
  if($transaction->is_success()) {
    print "Card processed successfully: ", $transaction->authorization(), "\n";
  } else {
    print "Card was rejected: ", $transaction->error_message(), "\n";
  }

DESCRIPTION

Business::OnlinePayment is a generic module for processing payments through online credit card processors, electronic cash systems, etc.

METHODS AND FUNCTIONS

new($processor, %processor_options);

Create a new Business::OnlinePayment object, $processor 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.

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:

PROCESSOR FIELDS

  • login

    Your login name to use for authentication to the online processor.

  • password

    Your password to use for authentication to the online processor.

GENERAL TRANSACTION FIELDS

  • type

    Transaction type, supported types are: CC (credit card), ECHECK (electronic check) and LEC (phone bill billing). Deprecated types are: Visa, MasterCard, American Express, Discover, Check (not all processors support all these transaction types).

  • action

    What to do with the transaction (currently available are: Normal Authorization, Authorization Only, Credit, Post Authorization, Recurring Authorization, Modify Recurring Authorization, Cancel Recurring Authorization)

  • description

    A description of the transaction (used by some processors to send information to the client, normally not a required field).

  • amount

    The amount of the transaction, most processors don't want dollar signs and the like, just a floating point number.

  • invoice_number

    An invoice number, for your use and not normally required, many processors require this field to be a numeric only field.

CUSTOMER INFO FIELDS

  • customer_id

    A customer identifier, again not normally required.

  • name

    The customer's name, your processor may not require this.

  • first_name

  • last_name

    The customer's first and last name as separate fields.

  • company

    The customer's company name, not normally required.

  • address

    The customer's address (your processor may not require this unless you are requiring AVS Verification).

  • city

    The customer's city (your processor may not require this unless you are requiring AVS Verification).

  • state

    The customer's state (your processor may not require this unless you are requiring AVS Verification).

  • zip

    The customer's zip code (your processor may not require this unless you are requiring AVS Verification).

  • country

    Customer's country.

  • ship_first_name

  • ship_last_name

  • ship_company

  • ship_address

  • ship_city

  • ship_state

  • ship_zip

  • ship_country

    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.

  • phone

    Customer's phone number.

  • fax

    Customer's fax number.

  • email

    Customer's email address.

  • customer_ip

    IP Address from which the transaction originated.

CREDIT CARD FIELDS

  • card_number

    Credit card number.

  • cvv2

    CVV2 number (also called CVC2 or CID) is a three- or four-digit security code used to reduce credit card fraud.

  • expiration

    Credit card expiration.

  • track1

    Track 1 on the magnetic stripe (Card present only)

  • track2

    Track 2 on the magnetic stripe (Card present only)

  • recurring billing

    Recurring billing flag

ELECTRONIC CHECK FIELDS

  • account_number

    Bank account number for electronic checks or electronic funds transfer.

  • routing_code

    Bank's routing code for electronic checks or electronic funds transfer.

  • account_type

    Account type for electronic checks or electronic funds transfer. Can be (case-insensitive): Personal Checking, Personal Savings, Business Checking or Business Savings.

  • account_name

    Account holder's name for electronic checks or electronic funds transfer.

  • bank_name

    Bank's name for electronic checks or electronic funds transfer.

  • check_type

    Check type for electronic checks or electronic funds transfer.

  • customer_org

    Customer organization type.

  • customer_ssn

    Customer's social security number. Typically only required for electronic checks or electronic funds transfer.

  • license_num

    Customer's driver's license number. Typically only required for electronic checks or electronic funds transfer.

  • license_dob

    Customer's date of birth. Typically only required for electronic checks or electronic funds transfer.

RECURRING BILLING FIELDS

  • interval

    Interval expresses the amount of time between billings: digits, whitespace and units (currently "days" or "months" in either singular or plural form).

  • start

    The date of the first transaction (used for processors which allow delayed start) expressed as YYYY-MM-DD.

  • 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)

submit();

Submit the transaction to the processor for completion

is_success();

Returns true if the transaction was submitted successfully, false if it failed (or undef if it has not been submitted yet).

failure_status();

If the transaction failed, it can optionally return a specific failure status (normalized, not gateway-specific). Currently defined statuses are: "expired", "nsf" (non-sufficient funds), "stolen", "pickup", "blacklisted" and "declined" (card/transaction declines only, not other errors).

Note that (as of Aug 2006) this is only supported by some of the newest processor modules, and that, even if supported, a failure status is an entirely optional field that is only set for specific kinds of failures.

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.

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).

require_avs();

Providing a true argument to this module will turn on address verification (if the processor supports it).

transaction_type();

Retrieve the transaction type (the 'type' argument to contents()). Generally only used internally, but provided in case it is useful.

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.

authorization();

If the transaction has been submitted and accepted, this function will provide you with the authorization code that the processor returned.

server();

Retrieve or change the processor submission server address (CHANGE AT YOUR OWN RISK).

port();

Retrieve or change the processor submission port (CHANGE AT YOUR OWN RISK).

path();

Retrieve or change the processor submission path (CHANGE AT YOUR OWN RISK).

fraud_score();

Retrieve or change the fraud score from any Business::FraudDetect plugin

fraud_transaction_id();

Retrieve or change the transaction id from any Business::FraudDetect plugin

AUTHORS

Jason Kohles, email@jasonkohles.com

(v3 rewrite) Ivan Kohler <ivan-business-onlinepayment@420.am>

Phil Lobbes <phil at perkpartners dot com>

HOMEPAGE

Homepage: http://420.am/business-onlinepayment/

Development: http://420.am/business-onlinepayment/ng.html

MAILING LIST

Please direct current development questions, patches, etc. to the mailing list: http://420.am/cgi-bin/mailman/listinfo/bop-devel/

REPOSITORY

The code is available from our public CVS repository:

  export CVSROOT=":pserver:anonymous@cvs.freeside.biz:/home/cvs/cvsroot"
  cvs login
  # The password for the user `anonymous' is `anonymous'.
  cvs checkout Business-OnlinePayment

Or on the web:

  http://freeside.biz/cgi-bin/viewvc.cgi/Business-OnlinePayment/

Many (but by no means all!) processor plugins are also available in the same repository, see:

  http://freeside.biz/cgi-bin/viewvc.cgi/

DISCLAIMER

THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

SEE ALSO

http://420.am/business-onlinepayment/

For verification of credit card checksums, see Business::CreditCard.