OnlinePayment(3pm)

📦
version 3.05 · 2 versions
  • 3.05 · debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking (latest)
  • 3.05 · ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

💖 Business::OnlinePayment 💖

okay so bestie, you've landed on OnlinePayment(3pm) and honestly? you're in the right place. this is the manual page for the Perl module Business::OnlinePayment, and by the end of it you're gonna be processing payments like it's nothing. let's GO 🫶

✨ NAME ✨

Business::OnlinePayment — Perl extension for online payment processing 💳

🌸 SYNOPSIS 🌸

here's the vibe, copy-paste ready:

  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";
    }

  }

look at that. clean. iconic. slay 💅

🦋 DESCRIPTION 🦋

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

that's it, that's the whole concept. one module, many processors, zero chaos (well… minimal chaos). periodt.

🎀 CONSTRUCTOR 🎀

💜 new($processor, %processor_options)

make yourself a brand new Business::OnlinePayment object ✨

  • $processor is required — this is the whole point, it defines the online processor you're gonna use.
  • if necessary, you can also pass processor options. the currently supported options are:
    • 'Server'
    • 'Port'
    • 'Path'

those three tell the module how to find the online processor: https://server:port/path

but bestie, listen — the individual processor modules should supply reasonable defaults for this info. only override the defaults if it's absolutely necessary (especially Path 😭), because the processor module was probably written with one specific target script in mind. don't go rogue.

💅 TRANSACTION SETUP METHODS 💅

🌈 content(%content)

this is where you hand over the info the transaction needs. it varies a lil bit depending on the processor, so the design here is: you define specific fields in the frontend, and they get mapped to the correct fields in the backend. cute, right?

the currently defined fields are:

🔥 PROCESSOR FIELDS

  • login — your login name, used for authentication to the online processor.
  • password — your password, used 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. heads up: not all processors support all transaction types.
  • action — what action is 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, no currency identifiers, just a whole or floating point number (i.e. 26, 26.1 or 26.13).

🌸 OPTIONAL TRANSACTION FIELDS

  • partial_auth — if you're 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. no take-backs.
  • description — a description of the transaction (used by some processors to send info 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, so keep it digits.
  • 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're requiring AVS Verification).
  • city — the customer's city (your processor may not require this unless you're requiring AVS Verification).
  • state — the customer's state (your processor may not require this unless you're requiring AVS Verification).
  • zip — the customer's zip code (your processor may not require this unless you're 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 info on each field. (so ship_city = same energy as city, you get it 💖)
  • 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. if the processor does not support a test mode, it'll generate a fatal error.

honestly? that's probably better than accidentally making real charges 💀 test mode or bust.

🫶 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. this is the moment. main character energy.

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

💖 TRANSACTION RESULT METHODS 💖

Okay bestie, this is the part where you find out what actually happened with your transaction. The receipts section. Let's go 🧾✨

  • is_success() — Returns true if the gateway approved the transaction, false if it got submitted but wasn't approved, or undef if it hasn't been submitted yet at all. So like… undef is the "we haven't even tried yet" vibe, not a fail. 🫶
  • partial_auth_amount() — If this transaction was a partial authorization (meaning: successful, but less than the amount you asked for actually got processed), then the amount that did get processed comes back in this field.
And listen — when is_success is true but this field is empty or 0, that means it's a totally normal full authorization for the whole requested amount. No crumbs left behind, we ate the entire plate. 💅
  • error_message() — If the transaction got submitted but wasn't accepted, this function hands you the error message (if there even was one) that the processor sent back. The "what went wrong" text, straight from the source. 😭
  • failure_status() — If the transaction failed, this can optionally return a specific failure status — and it's normalized, not gateway-specific, so it's the same language no matter who you're talking to. Currently defined statuses are: "expired", "nsf" (non-sufficient funds), "stolen", "pickup", "blacklisted" and "declined" (card/transaction declines only, not other errors).
Heads up fr fr: not all processor modules support this, and even when they do, it might not be set for all declines. So don't hard-depend on it, bestie. 🙈
  • authorization() — If the transaction was submitted and accepted, this gives you the authorization code the processor returned. 📌 Store this if you wanna run inquiries or refunds on the transaction later. Future you will thank present you.
  • order_number() — The unique order number for the transaction, generated by the gateway. Also 📌 store this if you want to run inquiries or refunds on it later.
  • card_token() — If your gateway supports it, a card_token can be used in a subsequent transaction to refer to a card number. Iconic, honestly. 👑
  • txn_date() — Transaction date, as returned by the gateway. Some gateways require this for follow-up transactions. 📌 Store this if you'd 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 get set by some processors (especially the HTTPS ones 🌈) when the transaction fails at the communication level rather than as a transaction. Like, the wires themselves got tangled.
    • 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 🌀

These are the backstage-pass functions. Mostly plumbing, but they're documented anyway because why gatekeep. ✨

  • transaction_type() — Retrieve the transaction type (that's the 'type' argument to contents()). Generally only used internally, but provided in case it's 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 🛠️

So you're writing a gateway module?? Main character energy, honestly. Here's your toolbox. 🧰💖

  • 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. 🐸 (yes, literally croaks)
  • 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 (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.

No cap, no warranty, no take-backs. Read it and weep (respectfully). 😭

👀 SEE ALSO 👀

http://perl.business/onlinepayment

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

And that's the whole page, bestie!! 🎀 This was Perl v5.36.0, dated 2023-01-22, and it's the OnlinePayment(3pm) manual page — you read the entire thing, which is honestly iconic behavior. Go process some transactions, you absolute legend. 💖✨🦋

📦 where this page comes from