[bop-devel] inconsistencies / a need for a more formal B::OP specification?

Phil Lobbes phil at perkpartners.com
Wed Dec 6 21:12:59 PST 2006


I'm slowly starting to use more B::OP backends and the more I use
different modules the more there are differences that make B::OP less
than ideal in my mind.  I know this isn't a trival problem, but perhaps
we should be trying to evolve some standard specification for
functionality that's "common" among drivers?

Some examples (I haven't surveyed too many modules -- but I'm sure the
problem is bigger than just these few observations):

1. CVV2 information

  * PayflowPro and Paypal backends have a cvv2_code() method
  * Authorize.Net has a cvv2_response() method

It sure would be nice to have a standard for this.

2. PayflowPro will "filter" the zip field in content:

      ( $zip = $content{'zip'} ) =~ s/\D//g;

Other drivers leave this as a responsibility of the caller to "do the
right thing" (my preference).  Perhaps we make a standard for this?

3. Handling authentication data

Some drivers use %processor_info to pass along user/pass/etc. but others
do not.

  my $tx = Business::OnlinePayment->new($processor, %processor_info);

This one is definitely trickier as the way you authenticate to various
backends certainly varies but if we can find a standard-ish way to deal
with most cases that would be nice.  For example:

* PayflowPro requires auth info as part of %content
* Paypal does not allow this
* Authorize.Net needs login and transaction_key (at least for what I've
  done it does -- password seems not used or perhaps completely optional
  but it isn't the same as transaction_key)

These comments are along the same lines as some from Jo Rhett recently.
I certainly see a need for more standardization if at all possible to
ease transition between different backends (or to support the use of
multiple backends at one time).

I'm willing to help out where I can one these, anyone else care much
about this topic?

Phil


More information about the bop-devel mailing list