---
name: "Business::OnlinePayment"
section: "3pm"
platform: "linux"
package: "libbusiness-onlinepayment-perl"
version: "3.05-2"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/Business::OnlinePayment"
---

# Business::OnlinePayment(3pm)

Perl extension for online payment processing

## 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  => '06/15',
                        name        => 'John Q Doe',
                       );
  eval { $transaction->submit(); };
  if ( $@ ) {
    print "$processor error: $@\n";
  } else {

    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.

## CONSTRUCTOR

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

## TRANSACTION SETUP METHODS

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

*REQUIRED 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 transaction types.

- action

  What action being taken by this transaction. Currently available are:

  - Normal Authorization

    - Authorization Only

    - Post Authorization

    - Reverse Authorization

    - Void

    - Credit

    - Tokenize

    - Recurring Authorization

    - Modify Recurring Authorization

    - Cancel Recurring Authorization

    - amount

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

*OPTIONAL TRANSACTION FIELDS*

- partial\_auth

  If you are prepared to handle partial authorizations (see **partial\_auth\_amount()**\
    in TRANSACTION RESULT FIELDS), pass a true value in this field to enable them.

  If this flag is not set, a partial authorization will be immediately reversed or voided.

- description

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

- invoice\_number

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

- po\_number

  Purchase order number (normally not required).

- tax

  Tax amount (portion of amount field, not added to it).

- freight

  Freight amount (portion of amount field, not added to it).

- duty

  Duty amount (portion of amount field, not added to it).

- tax\_exempt

  Tax exempt flag (i.e. TRUE, FALSE, T, F, YES, NO, Y, N, 1, 0).

- currency

  Currency, specified as an ISO 4217 three-letter code, such as USD, CAD, EUR, AUD, DKK, GBP, JPY, NZD, etc.

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

- expiration

  Credit card expiration, MM/YY.

- cvv2

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

- card\_token

  If supported by your gateway, you can pass a card\_token instead of a card\_number and 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

- routing\_code

  Bank's routing code

- account\_type

  Account type.  Can be (case-insensitive): **Personal Checking**, **Personal Savings**, **Business Checking** or **Business Savings**.

- nacha\_sec\_code

  NACHA SEC Code for US ACH transactions.  'PPD' indicates customer signed a form giving authorization for the charge, 'CCD' same for a business checking/savings account, 'WEB' for online transactions where a box was checked authorizing the charge, and 'TEL' for authorization via recorded phone call (NACHA script required).

- account\_name

  Account holder's name.

- bank\_name

  Bank name.

- bank\_city

  Bank city.

- bank\_state

  Bank state.

- check\_type

  Check type.

- customer\_org

  Customer organization type.

- customer\_ssn

  Customer's social security number.

- license\_num

  Customer's driver's license number.

- license\_dob

  Customer's date of birth.

*FOLLOW-UP TRANSACTION FIELDS*

These fields are used in follow-up transactions related to an original transaction (Post Authorization, Reverse Authorization, Void, Credit).

- authorization

  - order\_number

  - txn\_date

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

### 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 SUBMISSION METHOD

### submit()

Submit the transaction to the processor for completion.

If there is a gateway communication error or other "meta" , the submit method will throw a fatal exception.  You can catch this with eval {} if you would like to treat gateway co

## TRANSACTION RESULT METHODS

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

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

(When is\_success is true but this field is empty or 0, that indicates a normal full authorization for the entire requested amount.)

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

### 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 not all processor modules support this, and that if supported, it may not be set for all declines.

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

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

### card\_token()

If supported by your gateway, a card\_token can be used in a subsequent transaction to refer to a card number.

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

### 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

### response\_code()

### response\_headers()

### response\_page()

These three fields are set by some processors (especially those which use HTTPS) when the transaction fails at the communication level rather than as a transaction.

response\_code is the HTTP response code and message, i.e. '500 Internal Server Error'.

response\_headers is a hash reference of the response headers

response\_page is the raw content.

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

### avs\_code()

### cvv2\_response()

## MISCELLANEOUS INTERNAL METHODS

### transaction\_type()

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

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

## HELPER METHODS FOR GATEWAY MODULE AUTHORS

### build\_subs( @sub\_names )

Build setter/getter subroutines for new return values.

### get\_fields( @fields )

Get the named fields if they are defined.

### remap\_fields( %map )

Remap field content (and stuff it back into content).

### required\_fields( @fields )

Croaks if any of the required fields are not present.

### dump\_contents

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

Use this for handling boolean content like tax\_exempt.

## AUTHORS

(v2 series)

Jason Kohles, email@jasonkohles.com

(v3 rewrite)

Ivan Kohler \<ivan-business-onlinepayment@420.am\>

Phil Lobbes \<phil at perkpartners dot com\>

## COPYRIGHT

Copyright (c) 1999-2004 Jason Kohles Copyright (c) 2004 Ivan Kohler Copyright (c) 2007-2018 Freeside Internet Services, Inc.

All rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

## HOMEPAGE

Homepage:  http://perl.business/onlinepayment

Development:  http://perl.business/onlinepayment/ng.html

## MAILING LIST

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

## REPOSITORY

The code is available from our public git repository:

```
  git clone git://git.freeside.biz/Business-OnlinePayment.git
```

Or on the web:

```
  http://git.freeside.biz/gitweb/?p=Business-OnlinePayment.git
  Or:
  http://git.freeside.biz/cgit/Business-OnlinePayment.git
```

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

```
  http://git.freeside.biz/gitweb/
  Or:
  http://git.freeside.biz/cgit/
```

## 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://perl.business/onlinepayment

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