This is the status page for Business::OnlinePayment development. It is rather disorganized at the moment, but hopefully that will change as our plans for world domination solidify.

You can join the Business::OnlinePayment development mailing list by emaling a blank message to bop-devel-subscribe@420.am. You can browse the list archive.

News:

• Feb 2 2018: 3.05 released.
• Dec 3 2015: 3.04 released, new homepage location.
• Apr 29 2014: 3.03 released.
• Aug 19 2011: 3.02 released.
• Jul 14 2010: 3.01 released.
• Aug 17 2009: 3.00 released. It finally happened!
• Jul 21 2008: 3.00_09 developer release, documentation updates, normalize https_get and https_post response_code
• Jun 14 2007: 3.00_08 developer release, HTTPS response_{page,code,headers}, retreival of add'l fraud detection data
• Mar 23 2007: 3.00_07 developer release, bugfix in header setting w/Crypt::SSLeay
• Mar 13 2007: 3.00_06 developer release, HTTPS base class allows setting headers, more updated documentation
• Nov 29 2006: 3.00_05 developer release from Phil Lobbes, reworked _pre_submit functionality, updated tests and documentation
• Oct 10 2006: 3.00_04 developer release with initial Business::FraudDetect and normalized failure_status support
• Apr 10 2005: 3.00_03 developer release, Moneris eSelectPlus module.
• Jan 10 2005: 3.00_02 developer release, SecureHostingUPG module.
• Sep 3 2004: 3.00_01 developer release with HTTPS base class, OpenECHO module.
• Apr 18 2004: Preliminary Vend::Payment::BusinessOnlinePayment module available for the open-source Interchange shopping cart, sponsored in part by Simply Marketing, Inc.
• Sep 9 2002: Preliminary web pages and mailing list up, current module authors contacted

Useful documentation: Vital Processing Services documents EIS 1080 and EIS 1081 define the underlying protocol that POS devices and gateways themsevles use. Although the v3 API update will not initially support the large range of options that the underlying processing network does (card swipe, ATM, gasoline, restaurant and other industry-specific settings, and so on), some familiarity with the protocol and options is useful in order to plan for future expansion.

• EIS 1080 - Authorization Record Formats
• EIS 1081 - Data Capture Record Formats

TODO:

• Define release goals for 4.00
  • Stability/Production
    • Most of the 3.00 developer releases have been suitable for production use; the release delay more reflected that we haven't finalized usage differences or processor module changes.
    • Plan on usage/module changes in v4 instead.
  • Usage changes
    • Standardize all not-quite-official field names and formatting. Mostly done. Perhaps some data massaging on things like expiration dates still necessary.
    • type as CC / ECHECK / LEC instead of specific card types (B:OP base class should probably throw a warning and auto-translate into a supported type)
    • Different sort of exception handling that doesn't require you to eval the ->submit call (B:OP should catch it from the processor modules) For starters, as an explicit option you have to turn on, a "meta" is_success return such as processing_success or something. default in future releases?
    • Introspection available to ask processor modules what they can and can't do. Define.
    • More?
  • Processor module changes
    • HTTPS-based gateways must convert to B:OP:HTTPS.
    • Failure handling: die vs. is_success 0
    • Failure handling: set failure_status
    • Provide introspection data. Define.
• Project jumpstart:
  • Mailing list search/browse
  • Selected other projects contacted (Interchange, others?)
  • Public annoucement (comp.lang.perl, comp.lang.perl.modules, perl.com, use.perl.org, perlmonks.com, others?)
• Take a look at InterChange Vend::Payment modules - they support AuthorizeNet, BofA, CCVS, CyberCash, Signio, Skipjack and iTransact. As the other large project writing gateway interfaces it would be ideal to get InterChange on board. Hopefully reuse some/most of their code.
• Interchange requirements from Mike Heins:
  • "... a result hash that is available so that we can carry past payment status runs in our session for diagnosis. I would want that added where it is available."
  • Crypt::SSL or Net::SSLeay is not _required_ but it would be nice.
• LedgerSMB requirements from metatrontech:
  • track data support (see Net::TCLink)
• Contact non-Business::OnlinePayment CPAN authors about switching to the framework:
  • Business::PayBox - tostmann@tosti.com
  • Business::BancaSella - stoffer@netcetra.dk
  • Business::CashCow - info@ebruni.com
  • Business::CSI - jettero@voltar.org
  • Business::Paypal - mock@obscurity.org (will PayPal "flow" work with Business::OnlinePayment?)
  • Business::OCV (already listed in the README as FUTURE WORK, probably iinactive)
  • Business::OnlinePayment::WorldPay::Junior - in our namespace but doesn't use the API! (has been renamed to Business::WorldPay::Junior; old module removed from CPAN)
• Order numbers / transaction IDs, shipping addresses, first vs. last name, CVV/CVM (the additional numbers on the back of the card), retail/MOTO/ECI, terminal type, recurring transaction flags, etc., all need standard field names and reasonable defaults in the base API.
• The base API should provide "Normal Authorization" for gateways which do not support it by doing a "Authorization Only" and "Post Authorization".
• Automatic passing of custom authorization return data to capture requests - without this you wind up having to write new capture code at the application level for some new processors - see B::OP::VirtualNet for an example.
• General code cleanup: ->build_subs (no reason for overuse of ->methods, missing parameters cause a confusing missing parameter.al message from AutoLoader), %content (incoming and outgoing %content shouldn't be in clashing namespace), and Exporter/AutoLoader (neither is probably necessary).
• There's lots of code duplication in backend modules themselves. Fix this false laziness: provide more and cleaner methods/subroutines to backend module authors with common operations, etc.
• For version 4, unless there is an overwhelmingly good reason not to, provide backwards-compatibility with the version 3 interface, for both users (application authors using Business::OnlinePayment) and gateway module authors.
• Advocacy: Get gateways to write or sponsor backends. Get gateways to offer/link to/support Business::OnlinePayment as their Perl language binding. Get folks simply using gateways to sponsor Business::OnlinePayment backends instead of one-off gateway development. Get Perl projects using online payments to use Business::OnlinePayment. Work with similar projects for other programming languages.
• I guess a logo would be neat, but I wouldn't lose sleep over it :)
• ???
• Profit!